On Wed, 27 Feb 2008, Alessandro Vesely wrote:
Stuart D. Gathman wrote:
[An MTA maintainer] *should* be interested in allowing user extensions
(via postfix policy daemons or milter api) to modify MAIL FROM.
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
https://www.milter.org/developers/api/index
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. You can also change the result code
and message:
https://www.milter.org/developers/api/smfi_setreply
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.)
Proposals should distance themselves from specific applications. If an
example
is needed to show why it would be useful to modify MAIL FROM, pick
one like BATV, since SRS seems to have accumulated bad vibes in his mind.
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. Just don't remind "him" that this will also enable
SRS :-)
mentioned a number of different policies (i.e. BATV, SRS, ecc.) that
can be applied according with different strategies (i.e. after RCPT,
after DATA, after acceptance), thus an MTA-wise fragmentation on top
of that is quite an hindrance for any development.
There is no MTA fragmentation. A milter runs as a separate process
written in any language and communicates with the MTA via a socket.
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.
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.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------------------------------------------
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