-----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 <[email protected]>
To: [email protected]
Cc: [email protected]
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@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=<[email protected]>, ctladdr=<[email protected]> (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:
[email protected], 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-----
_______________________________________________
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 [email protected]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
