[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