From: Stuart D. Gathman [mailto:stuart(_at_)bmsi(_dot_)com]
Sent: Saturday, August 13, 2005 4:04 PM
On Sat, 13 Aug 2005, Seth Goodman wrote:
<...>
First look at the return-path. The RFC's say this is the address that
bounces should go to, and there is no MUST that I can find that says
it has to have any relation to the actual sender (whom I will define
as the party who is submitting the message for injection into the
Internet message stream).
<...>
No. It is the *receiver* that designates some other domain to receive
his email and forward it on to another mailbox. If is the receivers
responsibility to take this into account if they want to reject email
based on SPF.
I was talking about setting the address for bounces, which is the
return-path. That is the responsibility of the sender. This has nothing to
do with forwarding, which I agree, is the responsibility of the recipient.
Forwarding involves changing the To: header, not the From:, Sender:,
Resent-From: or Resent-Sender: headers. This is the case for conventional
forwarding. For the case of "redirect" forwarding, the existing originator
headers are kept intact and _additional_ informational headers are added, in
addition to changing the To: header.
<...>
Why accept a submitted message that is going to generate an SPF fail
at the receiving end? The domain owner has already said this is a
forgery, so it should be rejected at submission.
Amen. Checking SPF for outgoing mail is an often overlooked aspect.
I confess, that I have yet to implement it, but even for a small
business email server (which doesn't have the situation you describe),
it serves to detect mistakes in published SPF records before the
message gets out of the company network.
I didn't even think about the added benefit of detecting problems in the SPF
record. Good one. It seems like a pretty painless way for ISP's to put
_some_ restrictions on usage of domains they don't control. It only affects
domains that publish SPF records and the ISP would only reject submissions
where the message would generate an SPF fail without forwarding, so it seems
there is little downside to this. An SPF fail means the domain owner wants
you to reject the received message, so why send one under those conditions?
If there is a domain SPF record and a legitimate domain user can't send mail
through his ISP because it isn't listed in the record, that will prompt the
domain to either modify the SPF record, implement SMTP AUTH or set up a VPN
so their employees can send company mail from home. Just because you set up
SMTP AUTH doesn't mean you have to stop letting users authenticate through
POP before SMTP.
--
Seth Goodman