Re: SPF and SMTP 551/251 result codes.

David Woodhouse wrote:

> On Fri, 2004-03-26 at 14:34 -0500, Theo Schlossnagle wrote:
>  
>
> > Both seem completely legitimate to use.  After all, it's your mail 
> > service and your rules.  The flip side of this is that the owner of that 
> > .forward file might be pretty upset to learn that you are an 
> > "uninterested third party".  Perhaps not -- it is something you'd need 
> > to consider.
> >    
> The owner of that forward file is more likely to be upset by the fact
> that sender of the mail has effectively forbidden me from forwarding 
> the mail intact, as mail hosts have done for decades.
>  
I don't agree with you.  Emperically, mailbox owners tend to be blindly 
irritated with their providers of such problem (legitimately or not).  
Reading CNN.com and nytimes.com on any articles about spam will show 
users being mad at spammers and their own ISPs, but rarely ever at 
legitimate senders.  I think it would take a paradigm shift to make 
users focus frustration on legitimate senders.
The fact that it worked for decades isn't really relevant to the 
opinions of general users.  General users are also aware that spam is 
increasing and are accepting of the fact that things must change for 
things to change.  the fact that accountability (and enforcing 
accountability) is very central to preservation of legitimate email 
means that SPF has a lot of potential and hopefully forwarders will make 
a change that is for the better (taking responsibility of the return path).
In this day in age, I consider it to be a reasonable demand that foreign 
MXs not be allowed to use _my_ domain in their return path.  I 
understand very well that it breaks forwarding, but so many people 
refuse to accept that the concept of forwarding (as implemented now) is 
vulnerable to a variety of accountability problems.
My MTA has looked up the MX for the domain of said recipient and sent 
the message there.  It was received.  If that mailer chooses to remail 
the message, it can do so, but it should take responsibility of the 
return path.  This is a perfectly legitimate approach to the problem.  
Current email infrastructure doesn't do that, the RFCs don't dictate it 
and many systems rely on this weakness -- it doesn't mean it's perfect.  
But SPF finally provides us a tool execute this approach of 
accountability on the return path.
The user likely won't be in the position to be mad at the sender.  This 
only effects users that have chosen to implement SPF validation on 
receipt.  If they've _chosen_ to do so, then they buy into the fact that 
you don't have the right to use our domain in the return path of mails 
you send if we say you don't in our SPF record.
> But if you read what I posted, you'll see that I was suggesting that we
> make appropriate response to a '551' result code mandatory for
> SPF-publishing senders, so that I _can_ give 551 result codes with a
> reasonable expectation that the mail won't be lost.
>
> It's quite simple -- if you say a third party can't forward the mail,
> you have to be prepared to do it for them.
>  
Not true.  551 has been in the RFC for a long time and while acting on 
it autmatically is an option, returning the mail as undeliverable has 
always been (and should continue to be) perfectly acceptable. You told 
the MTA you wouldn't forward the mail and returned a permanent failure.  
That MTA can either transparently act on that response (as you suggest) 
or just as legitimately return said error to the human/auto sender of 
the message.  If the latter approach is taken, the following transpires:
The human or the service can then contact the user out-of-band (via a 
new email address or some other non email mechanism) and explain that 
their forwarding service refused to deliver our message to the email 
address they wanted us to send the mail to.  It was refused because the 
forwarding service wants to be able to use our  domain in the return 
path of mail they send from their system.  The forwarder _could_ 
implement a technology that solves this proble, but chooses not to. So, 
you need to provide us with a new email address that will accept mail 
from us/me.  You'll note that this is how any other SMTP failure is 
handled as well, be it based on "no account", "spam", etc.
The point I set out to make was that sending the 551 back to the sender 
is a completely legitimae thing to do with that sort of SMTP rejection.  
Making it mandatory for the sender to do anything else is ridiculous.  
The message is not _lost_ in this case, it was rejected and the 
rejection was handled in a valid way.
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Postal Engine -- http://www.postalengine.com/
// Ecelerity: fastest MTA on Earth