[Mimedefang] Relayed emails can't be filter!
Steffen Kaiser
skmimedefang at smail.inf.fh-bonn-rhein-sieg.de
Fri Jun 13 05:33:56 EDT 2014
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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[17949]: s5D8kQAP017949: Milter add: header:
> X-Scanned-By: MIMEDefang 2.75 on x.x.x.x
> Jun 13 08:46:28 srv-01 *sm-mta*[17949]: STARTTLS=client,
> relay=smtp.outside.com, version=TLSv1/SSLv3, verify=OK, cipher=AES256-SHA,
> bits=256/256
> Jun 13 08:46:30 srv-01 *sm-mta*[17949]: 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 [184.73.178.44], dsn=2.0.0, stat=Sent (Ok
> 00000146946821e9-c9c81ea2-9fcf-4076-952f-1c8e3591464d-000000)
> Jun 13 08:46:30 srv-01 *sendmail*[17948]: 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
the process.
> 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%)
>>
>> Hmm,
>> http://www.openemm.org/faq/questions/22/Why+do+you+use+Sendmail+and+not+other+MTAs%3F
>>
>> "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.
- --
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBU5rFhFGgR0+MU/4GAQIV7Qf+K17r7kB6Jb/QZF+tpAiYaPfGmSWoF76f
iY9ogZxipKKl++vk52HLsg11M7fuuAzR44i1KQ03cQMkO4DnCOyY7DivyT5zSjOB
kaFq4ciYC6Q0mLoxqda1hVndlGYN4P/kahY4PP37HS6ySe+1omHaALUYxLwSYfED
fiVS70GArICcp7qHbVR6fHVjRcDztIkKR6NK0gIYEW0onfRnSIPYU3WMo0wlEAPI
ZSv0qMjUVVOyc9PRyR1upxBbUFc8VYzwJgubWC6qaYYTM4azmTufkNhSosdo3kC7
8hAifvbCSVXt9xXJnM0ADMZtifYQInqi9XV9eurYX/kHzhLbReiYZw==
=AyL9
-----END PGP SIGNATURE-----
More information about the MIMEDefang
mailing list