admin at asarian-host
Jan 9, 2008, 9:16 PM
Post #2 of 4
(799 views)
Permalink
|
|
RE: Forwarder whitelisting reloaded: Forwarders SMTP-AUTH to receivers?
[In reply to]
|
|
-----Original Message-----
From: Julian Mehnle [mailto:julian [at] mehnle]
Sent: woensdag 9 januari 2008 17:12
To: spf-discuss [at] v2
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> 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>... not authenticated
But outwardly just replies with:
S: 250 2.1.0 <bla [at] example>... Sender ok
Perhaps we oughta prefix the forwarder identity? Like:
C: MAIL FROM:<bla [at] example> 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> 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=1311532&id_secret=84110643-0c2e6d
Powered by Listbox: http://www.listbox.com
|
