On Sat, Sep 10, 2005 at 12:38:03PM +0200, David wrote:
- Receivers doing SPF checks, if that header is present, should
interpret it this way:
You are totally missing the point of checking SPF.
The message can be rejected before it is received.
Nothing in the DATA part will help, there will not be a DATA part.
SMTP session from 10.11.12.13:
EHLO forged.server.example.com
The receiver will ask "forged.server.example.com" for its policy.
This policy does not allow 10.11.12.13
The receiver will reject the session.
END OF SESSION.
Suppose there was no check on EHLO, or suppose it didn't fail:
MAIL FROM: <victim(_at_)forged(_dot_)domain(_dot_)example(_dot_)com>
The receiver will ask "forged.domain.example.com" for its policy.
This policy does not allow 10.11.12.13
The receiver will reject the session.
END OF SESSION.
If this check, again, doesn't result in a fail, only then the
session continues:
RCPT TO: <anyuser(_at_)example(_dot_)org>
DATA
...your proposed header goes here
...message text goes here
.
As is said before: "forwarding" is a receiver problem. The message
is received (by the forwarding party) and is resent. The forwarder
and the next recipient will have to make sure SPF isn't checked at
that point.
The problem: forwarders abuse other people's names.
The solution: stop forging messages, with or without good intent. SRS is
one of the possible solutions
A workaround: don't verify SPF when you receive a message from this forwarder
Alex
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com