On Thu, 30 Sep 2004, Hector Santos wrote:
Is it all possible to add SPF 2.0 provision for consideration of the most
important entity of the 2821 transaction? The forwarding address;
2821.RCPTTO?
Can you explain what you have in mind and how the checking of that address
should be done that is not being done right now?
If RCPTTO fails, then all your steps is all for nothing.
Well, if you don't know how to route the email in the first place why
bother doing any from address checking...
This is already somewhat implied by existing algorithm, although may not
be perfectly clear. In draft-ietf-marid-mailfrom it says:
Software SHOULD perform this [SPF] authorization check during the
processing of the SMTP transaction that injects the mail. This
allows errors to be returned directly to the injecting server by
way of SMTP replies. Software can perform the check as early as
the MAIL command, though it may be easier to delay the check to
some later stage of the transaction.
A modified version of that is in leibzon-resposible-submitter:
If SMTP Client provided SUBMITTER argument to MAIL command then SMTP
Client SHOULD perform authorization check during the time of SMTP
transaction. The check can be performed directly at the time of MAIL
command or it maybe easier to delay the check to later stage of SMTP
transmission.
[Note to self: change "maybe" to "may be" before publication]
Both basicly are supposed to mean that you can do SPF check directly at
MAIL command but may want to delay it until you see RCPT TO and decide
if its appropriate based on user policies. If I understand, you believe
its better instead of recomendation to directly specify "SHOULD do
verification after RCPT TO". I personally think what we have is fine
and implementors will understand this and that we should not directly
say "SHOULD". But perhaps extra paragraph why they may want to do
verification after RCPT TO would not hurt - so do you want to help and
write something up for inclusion in future drafts?
Actually some modifications to what I wrote are necessary to make
sure if PTR is not there SUBMIT would override MFROM. It should be like:
Come to think of it, the algorithm has some more errors...
Here is another try at it (probably not the last try either):
--------------------------------------------------------------------------
Step | SPF Identity | Result of verification
------+---------------+---------------------------------------------------
1 | SPF2.0/HELO | If Fail -> reject, otherwise go to 2
2 | SPF2.0/SUBMIT | If Fail -> reject, otherwise go to 3
3 | SPF2.0/MFROM | If Pass and #1 is Pass -> accept email, otherwise 4
4 | SPF2.0/PTR | If Fail and #3 is Fail -> reject, otherwise 5
5 | n/a | If #1, #2, #4 are None and #3 is Fail -> reject
| | othewise accept email
--------------------------------------------------------------------------
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/