vesely at tana
Feb 28, 2008, 12:45 AM
Post #4 of 7
Stuart D. Gathman wrote:
Re: How to modify the MAIL FROM argument? (was: Re: Top problems with SPF acceptance)
[In reply to]
> 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).
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.
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
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://www.listbox.com/member/?member_id=1311532&id_secret=95897010-3d7186
Powered by Listbox: http://www.listbox.com