alan wrote:
At 13:19 20/07/2009 Monday, Hannah Schroeter wrote:
*Which* RCPT to domain should it expand in this transaction:
HELO a.first.example.com
MAIL FROM: <user(_at_)first(_dot_)example(_dot_)com>
RCPT TO: <user1(_at_)second(_dot_)example(_dot_)com>
RCPT TO: <user2(_at_)third(_dot_)example(_dot_)com>
i would assume the assumption is the spf would be being verified as standard
after each rcpt To: command is issued
That would be redundant in this case, since both second.example.com
and third.example.com have a common MX, which is the machine receiving
the commands above. I note that, unless one makes braindead
comparisons between HELO and MAIL FROM, the receiving server doesn't
know whether the message is being forwarded, rather than delivered
directly.
{why spf looks currently only at helo and "mail from"}
HELO is unreliable because it may be an IP address, it may be
anything, and even if it is correct one cannot reliably infer the mail
domain name by stripping its leftmost label, as stated in rfc 5507.
MAIL FROM is the first command where the receiving server learns the
mail domain of the transmitting server. Even if it's not its original
purpose. Even if it may be empty.
If there were a command whose argument consisted of the domain name,
e.g. "VHLO example.com", SPF would be perfect for authenticating a
transmitter as SMTP-authorized member of a mail domain. IMHO, that's
SPF's strong suite.
{to return an accept or reject for that recipient depending on their
SPF/reject/ignore/tag policy+result}
In plain English, the SPF record would say "I know you're broken, so
please forget about any SPF results that are intended for smart
recipients only."
but if spf is being checked elswhere {say after data} it would have to have
either to be decided by receivers implementation choice
That makes sense, since the recipient presumably knows better whether
it is broken.
hopefully no "wild" implementations leave it so late
SpamAssassin is an example. It interprets Received headers, determines
the addresses and reckons how SPF authorizations contribute to a
message spamminess. SA may be configured to whitelist_by_spf on a per
mail domain basis. I'd guess this use of SPF outscores rejecting
forgeries before DATA.
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com