Stuart D. Gathman wrote:
On Wed, 27 Feb 2008, Alessandro Vesely wrote:
I'd still be interested in knowing what an API to modify MAIL FROM
might look like. I'm not quite familiar with neither postfix nor
sendmail (I use Courier).
https://www.milter.org/developers/api/smfi_chgfrom
I copy it below for those who are too lazy to click on the above link:
int smfi_chgfrom(SMFICTX *ctx, const char *mail, char *args);
where ctx is an opaque object, mail and args are the replacements for
the MAIL FROM argument and any additional parameters respectively.
Using milter apparently implies doing it earlier. Is that right after
the MAIL FROM(!?), after RCPT, or after DATA?
Right after MAIL FROM, while the SMTP session is in progress, before
the MTA has responded to MAIL FROM.
Apparently, libmilter docs differ: the message modification functions
may only be called in xxfi_eom, the end-of-message after xxfi_body.
(This may make sense, as there's no point in changing the recipient if
the message is going to be rejected.)
Sometimes, I forward based on specific message contents, using
maildrop, that's the reason why I find it more natural to do it after
the message has been accepted. What are the pros of doing it "online"?
The biggest pro of doing it "online" is to reject forged or blacklisted
MAIL FROM or HELO immediately, with no need to go to DATA. When using SRS, you
can also reject DSNs (empty MAIL FROM) with no SRS signature in the recipient
without going to data. (These are bounces from otherwise legit MTAs that didn't
check your SPF record before bouncing mail that forges your MAIL FROM.)
Thanks for the insight. However, I note that most of the advantages
are not directly related with forwarding.
While it is good to perform delivery steps before closing the
transaction with the remote MTA, it might not always be possible.
OTOH, if forwarding addresses are configured as aliases, they may go
directly to the queue and cannot be changed any more. According to the
RFCs, in order to modify the MAIL FROM one should configure a "list".
Can that be understood in an MTA-independent manner? You already
Yes, the milter API is MTA-independent, and postfix supports a version
of it. And when they support the latest version, they will support
changing MAIL FROM.
On the milter.org site they mention a number of MTAs:
* Open source Sendmail 8.12 and later
* Open source Postfix 2.4 and later
* Sentrion™ MP appliance from Sendmail Inc.
* Switch™ from Sendmail Inc.
* Mailstream Manager™ from Sendmail Inc.
There is no MTA fragmentation. A milter runs as a separate process
written in any language and communicates with the MTA via a socket.
Courier-MTA does not support libmilter. It would require major changes
to insert all milter callbacks in a sensible manner. Few posts in the
courier-users mailing list mention adding milter compatbility, e.g.
http://sourceforge.net/mailarchive/message.php?msg_name=455EDC9F.2090603%40tana.it
http://sourceforge.net/mailarchive/message.php?msg_name=45B4FC3B.1010409%40eburg.com
In addition, we should consider widely used commercial MTAs, such as
* Microsoft Exchange,
* Lotus Notes, and
* Novell GroupWise.
I never used any of those. Can anyone briefly mention the filtering
capabilities of any of them?
I report Courier's filtering callbacks here:
* rcpt API: for each RCPT that resolves to a local user,
* local filter: users that registered for it get a call after DATA,
* global filter: after DATA, before accepting it,
* anything can be done on delivery, including forwarding.
For languages, the first two items require maildrop or C; the 3rd is
also done via socket, and generic frameworks exist for Perl and
Python. Delivering may invoke any program, typically maildrop.
The other way to achieve the same MTA independence is with an SMTP
proxy. But these introduce timing problems. The milter API handshakes
with the MTA to prevent false timeouts.
If we use an SMTP proxy, it should intercept _outgoing_ SMTP calls, as
that is what is more relevant for forwarding. My understanding of
milter is that it only operates on _incoming_ connections. However, a
proxy does not look like the simplest solution at a first glance.
In other words, if we had a nice program that did The Right Thing for
each forwarded recipient, how would we fit it into our differing MTAs?
If written to the milter API, and the MTAs support milter, just add it
to the milter list.
We'll have to evaluate pros and cons of using milter. We can also go
for a library that can be invoked from a any kind of filter, including
milter. However, filtering is more often associated to incoming calls
and I'm not sure it is always possible to "filter" outgoing mail
transactions. Possibly, interfacing the "list" model of forwarding is
the most portable approach.
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription:
http://www.listbox.com/member/?member_id=2183229&id_secret=95887956-51703a
Powered by Listbox: http://www.listbox.com