[Mimedefang] Relayed emails can't be filter!
skmimedefang at smail.inf.fh-bonn-rhein-sieg.de
Fri Jun 13 05:33:56 EDT 2014
-----BEGIN PGP SIGNED MESSAGE-----
On Fri, 13 Jun 2014, Cương Bùi wrote:
> Date: Fri, 13 Jun 2014 16:05:25 +0700
> From: Cương Bùi <bhcuong2008 at gmail.com>
> To: skmimedefang at smail.inf.fh-bonn-rhein-sieg.de
> Cc: mimedefang at lists.roaringpenguin.com
> Subject: Re: [Mimedefang] Relayed emails can't be filter!
> Hi Steffen,
> Thank you for your investigation :)
> 1. - spool files can easily be generated directly (the process is documented)
> - therefore, OpenEMM can assign spool file names so that OpenEMM has
> sufficient ID information encoded to use the names for bounce management
> during mail transmission
> => OpenEMM spawns 8 concurrent processes of sendmail for handling sending (1
> of 8 used for accepting incoming emails).
> The 7 others handle 4 queues (4 spool dirs) as below (from command ps -ef).
> root 17717 1 0 08:36 ? 00:00:00 sendmail: MTA: Queue
> runner at 00:01:00 for /home/openemm/var/spool/ADMIN
I guess your "normal" config of sendmail in /etc/mail does not use
/home/openemm/var/spool, so OpenEMM does indeed use its configuration and
my proposals seems to apply.
> => I think the issue may come from this. It handles directly...
> Back to my test previously, use sendmail from command line (sendmail -vt <
> [file of email content]). I see that there are differences
> between 2 cases (from OpenEMM vs command line)
> Jun 13 08:46:26 srv-01 sm-mta: s5D8kQAP017949: Milter add: header:
> X-Scanned-By: MIMEDefang 2.75 on x.x.x.x
> Jun 13 08:46:28 srv-01 *sm-mta*: STARTTLS=client,
> relay=smtp.outside.com, version=TLSv1/SSLv3, verify=OK, cipher=AES256-SHA,
> Jun 13 08:46:30 srv-01 *sm-mta*: s5D8kQAP017949:
> to=<user01 at example.com>, ctladdr=<sysuser at srv01.example.com> (0/0),
> delay=00:00:04, xdelay=00:00:04, mailer=relay, pri=30377,
> relay=smtp.outside.com [18.104.22.168], dsn=2.0.0, stat=Sent (Ok
> Jun 13 08:46:30 srv-01 *sendmail*: s5D8kPP1017948:
> to=user01 at example.com, ctladdr=sysuser (0/0), delay=00:00:05,
> xdelay=00:00:04, mailer=relay, pri=30138, relay=[127.0.0.1] [127.0.0.1],
> dsn=2.0.0, stat=Sent (s5D8kQAP017949 Message accepted for delivery)
> 2. - bounce management is based on a well documented plugin interface of
> Sendmail (milter) and permits combining the realibility of Sendmail with the
> flexibility of OpenEMM functions.
> => OpenEMM develops its own filter for handling bounces. It's just like
> other filter. It does not affect other milters (like AchiveSMTP, MIMEDefang)
It depends on how that milter detects bounces. If you re-route the message
through your sendmail instance configured by /etc/mail, you could break
> On 6/13/2014 3:42 PM, Steffen Kaiser wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> On Fri, 13 Jun 2014, Cương Bùi wrote:
>>> *1. What emails you are mean with "outgoing"? Are they submitted via the
>>> local system, e.g. by calling the sendmail exectuable, or via SMTP? *
>>> These emails originate from OpenEMM, on the same server. There are 8
>>> running processes of sendmail on different queues.
>>> => When there are some messages in these queues, it's automatically sent
>>> by these processes. (my understanding, not sure 100%)
>> "Sendmail is difficult to replace in OpenEMM by other MTAs because
>> - - spool files can easily be generated directly (the process is
>> documented) - - therefore, OpenEMM can assign spool file names so that
>> OpenEMM has sufficient ID information encoded to use the names for bounce
>> management during mail transmission"
>> I don't know if I understand the 1. statement correctly, but they seem to
>> say that they create the spool files for sendmail directly, bypassing the
>> "injection" via both sendmail executable and socket.
>> If that's correct, no milter can be activated obviously. OpenEMM is open
>> source, so IMHO patch the processing you want to make into its "injection".
>> If you don't want to patch OpenEMM, you need to get to know how the mail
>> flow of OpenEMM is, how many sendmail configurations there are (the 2nd
>> statement above let me assume that OpenEMM runs its own configuration), and
>> put some filter in between. That might brake the bounce detection.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the MIMEDefang