spf-discuss
[Top] [All Lists]

Re: SPF and SMTP 551/251 result codes.

2004-03-26 14:18:43
On Fri, 2004-03-26 at 15:48 -0500, Theo Schlossnagle wrote:
I don't agree with you.  Emperically, mailbox owners tend to be blindly 
irritated with their providers of such problem (legitimately or not). 

You speak for your users; I'll speak for mine. I assure you that if
anyone who forwards through virtual (or real) domains on my system finds
that their mail is being rejected and asks me about it, the explanation
they receive from me will leave them in no doubt that the problem lies
with both the sender of the lost mail, whose fault it is for publishing
SPF records, and the admin of the target domain to which they forward,
whose fault it is for obeying SPF records.
 
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.

OK, you're denying me the right to forward the mail to the correct
address for the user in question. I think that's very misguided, but
let's assume for the sake of argument that I accept it. 

Given that, what is _wrong_ with the request that in return for that
deviation from current practice, you take on the responsibility of
delivering it to the correct address if I actually take the trouble to
tell you what that address should be?

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.

Users' parents effect them. We can only seek to affect them; adversely
or otherwise.

  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.

In general, users don't implement SPF checking. Misguided admins do that
on their behalf.

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. 

Indeed. That's why I called it a 'suggestion', not an 'observation'.
Please do try to keep up.

 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:

< user magicks new email address or phone number out of thin air with
which to communicate with the person whose email cannot be forwarded >

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.

Please explain why you think that it is ridiculous. You have caused a
situation in which I may not forward your mail but I offer you the
forwarding address to use for yourself... why is it unreasonable to
expect you to _use_ the address you're offered?

-- 
dwmw2