From: Julian Mehnle [mailto:julian(_at_)mehnle(_dot_)net]
Sent: woensdag 9 januari 2008 17:12
Subject: [spf-discuss] Forwarder whitelisting reloaded: Forwarders SMTP-AUTH to
Fascinating stuff. :) I wonder how come we never looked at this before.
For this reason, servers that advertise support for this
extension MUST support the AUTH parameter to the MAIL FROM
command even when the client has not authenticated itself to the
Hmmmm, how exactly does an MTA "advertise support" for the AUTH parameter
to the MAIL command? It's not a VERB (like ENHANCEDSTATUSCODES, or DSN)
that can be advertised in the regular fashion. Or should we simply assume
the AUTH extension to the MAIL FROM command is implemented?
The optional AUTH parameter to the MAIL FROM command allows
cooperating agents in a trusted environment to communicate the
authorization identity associated with individual messages.
So, could it be argued that forwarders could just authenticate to
the receiver (their customer!) using SMTP-AUTH when forwarding mail,
no sophisticated forwarder whitelisting required?
It would appear that way. :) I did some initial testing, and sendmail, at
least, defines the macro:
The authorization identity (the AUTH= parameter of the SMTP MAIL command
Furthermore, we read (RFC 2554):
If the server does not sufficiently trust the authenticated
identity of the client, or if the client is not authenticated,
then the server MUST behave as if the AUTH=<> parameter was
supplied. The server MAY, however, write the value of the AUTH
parameter to a log file.
In other words: there's no 'penalty' for having a value in the AUTH=
parameter the MTA doesn't sufficiently trust enough. So then, what's to
prevent a forwarder from doing?
C: MAIL FROM:<bla(_at_)example(_dot_)com> AUTH=forwarder.org
As per the RFC, my sendmail (8.14.2) DOES log an authentication failure:
Jan 10 05:51:17 asarian-host sendmail: ruleset=trust_auth,
arg1=forwarder.org, relay=localhost [127.0.0.1], reject=550 5.7.1
<bla(_at_)example(_dot_)com>... not authenticated
But outwardly just replies with:
S: 250 2.1.0 <bla(_at_)example(_dot_)com>... Sender ok
Perhaps we oughta prefix the forwarder identity? Like:
C: MAIL FROM:<bla(_at_)example(_dot_)com> AUTH=spf_.forwarder.org
Where "spf_." is just a prefix to distinguish the use of the AUTH= param
from other cases.
Which brings me to another thought. How about this?
C: MAIL FROM:<bla(_at_)example(_dot_)com> AUTH=<spf_>
Which senders can optionally supply as a courtesy to indicate the message
is NOT being forwarded? It might make receivers more confident to REJECT
I must say I'm fair excited about this. :)
Sender Policy Framework: http://www.openspf.org
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription:
Powered by Listbox: http://www.listbox.com