On Wed, 2004-06-02 at 22:50, Seth Goodman wrote:
You are correct that RFC2821 defines MAIL FROM: as the address to receive
DSN's. While there is currently no requirement for it to match any other
address in the headers, what I was asking was why _couldn't_ we require it
to match the From: or Sender: header? In legitimate email, it very often
does match one of these headers. I was trying to think of a legitimate case
where it would need to be a different address, and I can't think of any. If
we could require this, an SPF pass on the first hop would mean a lot more
than it currently does.
The new spf using RFROM and the PRD concept makes the problem of the
MAIL FROM return-path not matching the From or Sender headers
irrelevant, because if the return-path doesn't match the PRD, the sender
will use an RFROM that does match, or risk the message being
new-spf-rejected.
But there's no reason such a mismatch has to be considered bad, and it
can be useful..
For physical mail, the inside of a letter contains an inside return
address--the recipient can use this address for further correspondence
with the sender.
The outside of a letter has a postal return address--the post office
will use this address for postal returns.
The addresses don't have to match, even though they're (IMHO mistakenly
and implicitly) assumed to match in most any "how to write a business
letter" type of document you might run across.
For a large bulk mailer, it makes sense to have different return
addresses for these sorts of things--postal returns can go to a place
that can handle volumes of return-to-sender mail and fix up addressing
problems, while correspondence returns can go elsewhere.
(And in the case of billing letters, you're likely have even more
addresses--possibly you'll have internally noted "remit payments to" and
"send correspondence to" addresses, but at the very least you'll have
one internal address which may or may not match the external return
address.)
(Oh, and supposing the outside postal return-address differs from the
inside return-address printed in the letterhead, the letterhead may be
pointing to a generic office or group, while the letter is written
so-called "from" a certain person, but typed up and sent (ie, "Sender")
by a secretary. So that's two different return addresses, and a Sender,
and a From, and none of them match any other.)
For email, the same thing applies. I may want automated mail system
returns to go to a different address than replies, and if I'm using any
verp-like system, I *can* have a completely different system process
bounces than the system that processes correspondence.
(As a side note, I never thought the fact that preventing this sort of
mismatched set of return addresses would really in fact be a potential
problem until just a few days ago when reading through a debian mailing
list thread. In that thread, someone objected to SPF on the grounds
that he wanted to send mail from his ISP and with his ISP-provided email
address in the From: body header line, but with bounces and reply-to:'s
going to his personal server elsewhere. While at the time I wasn't sure
why he'd want to do this, I couldn't convince myself that there was any
real reason for the new SPF to *have to* prevent this, given that RFOM
and the PRD can show this person's account as the responsible sender,
and then you can simply trust him or not as you please.)
But to a reason you might want this sort of difference with email:
Let's say you're sending out some sort of notice by email to all your
one million customers, perhaps a monthly invoice. (You're a huge
business.) Some of those customers will respond to the email itself,
but other responses you get will be mail system bounces. At that scale,
it is probably useful to have a separate system handle VERP bounces and
cause postal notices to be sent after permanent failure errors for those
specific messages, (though it's overkill for us mere mortals.)
Of course with email, it's still possible to process bounces and
responses on the same machine, but I can imagine times where it's nice
to be able to separate it.
So, I don't see anything really fundamentally wrong with an invoice from
your ISP with a "MAIL FROM:
<SES-string-invoice-bounces(_at_)bounces(_dot_)accounting(_dot_)example(_dot_)com>"
in the
envelope, but with "From: invoice(_at_)accounting(_dot_)example(_dot_)com" in
the body
header, along with a "Reply-To:
invoice-questions(_at_)accounting(_dot_)example(_dot_)com", and "Sender:
A-L-sender(_at_)accounting(_dot_)example(_dot_)com".
Again, four ~"From"s, not matching, and nothing's really wrong with
this. (I admit this is a more contrived example--it's harder to make an
email scenario with *all four* being different, especially the From and
Sender being different in this example.)
Such a combination was somewhat discomforting with the old spf, since it
readily exposed the fact that the old SPF verified a return-path that
isn't seen or really understood by most users, but the same combination
seems just fine to me with the new spf.
Off-topic side note:
---------------------
I just realized/remembered something--not sure which!
If there's ever an spf modifier for SES, (say for an "exists"-type,
non-CBV SES check), then if you have a MAIL FROM line as follows:
MAIL FROM:<SESed-address-person(_at_)ONE(_dot_)example(_dot_)com> \
RFROM=<person(_at_)TWO(_dot_)example(_dot_)com>
And you do new-spf checks and any SES-described-in-spf-modifiers test,
you'll do the spf check after querying the "TWO.example.com" domain, but
you'll do the SES check after querying the "ONE.example.com" domain!
The new-spf focus on RFROM/DAVE doesn't change anything for SES tests
for what domain would have to be checked to get SES modifier info from.
That's not really related to the current thread, but...I just suddenly
re(?)-realized it.
Mailing lists are handled differently as explained in the RFC. They
preserve the original From: address, put their own address as Sender: and
set MAIL FROM: to be their bounce address. Forwarders, on the other hand,
are not supposed to change MAIL FROM:, From: or Sender:. They typically
just change To:, prepend another set of Received: headers and resend the
message.
And they should add Resent-* headers. :-)
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com