[Mimedefang] Relayed emails can't be filter!

[Cương Bùi]

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 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)
(I think so).


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)
>
> iQEVAwUBU5q5b1GgR0+MU/4GAQJcEAgAsuU40j1kucRmR8+INBbfA5t6EcvE61pE
> bJ4xwjlXEF6b85kN9RQ/aJh4OphICPPTmrHAFatLLosxNnAU5WA+6GbVf7R19XzX
> O2EhyXhgO+oUtmWbZgesIOzmdBWDRclYJQ2b7kXMPh8fMLIi29ZdtanSgmBsMfIn
> r9M+iyEiPr5gzbdB1kpz9TWl2ap/NG44yplMPWC9USkxva03o9lL9JN4PkwnjRvP
> vqe8xBTLWJXXKaqDOO8VJf4j86g/UyQNLaxFQTyV/W4ITbUpSIiA0vE3V/jufMQt
> lxihVMSCy5pb94yGV7d+GQ176FCFRK1sPQ4zpDt+cN68P3mSy2S/lQ==
> =7DZT
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> NOTE: If there is a disclaimer or other legal boilerplate in the above
> message, it is NULL AND VOID.  You may ignore it.
>
> Visit http://www.mimedefang.org and http://www.roaringpenguin.com
> MIMEDefang mailing list MIMEDefang at lists.roaringpenguin.com
> http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

-- 
**********************
Regards,
Cuong Hoang Bui
ctek at cteklab.net
bhcuong2008 at gmail.com
**********************