spf-discuss
[Top] [All Lists]

RE: [spf-discuss] Forwarder whitelisting reloaded: Forwarders SMTP-AUTH to receivers?

2008-01-09 22:22:02
-----Original Message-----
From: Julian Mehnle [mailto:julian(_at_)mehnle(_dot_)net] 
Sent: woensdag 9 januari 2008 17:12
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: [spf-discuss] Forwarder whitelisting reloaded: Forwarders SMTP-AUTH to 
receivers?

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
 server.

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:

${auth_author}
The authorization identity (the AUTH= parameter of the SMTP MAIL command
if supplied.

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[28526]: 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
on FAIL.

I must say I'm fair excited about this. :)

- Mark

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: 
http://v2.listbox.com/member/?member_id=2183229&id_secret=84110891-1b1232
Powered by Listbox: http://www.listbox.com

<Prev in Thread] Current Thread [Next in Thread>