Seth Goodman wrote:
RFC2821 and RFC2822 do define and use those keywords
Yes, 2821 > 2119.
STD 10 is 821, 821 < 2119, and STD 3 is 1123, 1123 < 2119.
STD 3 contains another RfC, but we're only interested in
1123 as far as SMTP is concerned.
Together, they replace 821, 822, 974 and 1869 plus update
and clarify 1035 and 1123.
Propose to replace, both are at PS, not at full standard.
Return-Path, it's not any report-trouble-elsewhere-address".
I'm afraid that's exactly how it is described, even though I
dislike that concept at least as much as you.
I'm afraid you're more or less right, but I consider this as
FUBAR for obvious reasons. Let's see what 2821bis will do
about it. Until then I have my own STD 10 quote collection:
<http://mid.gmane.org/42843EFB(_dot_)7791(_at_)xyzzy(_dot_)claranet(_dot_)de>
~~~ beg ~~~
"reverse-path which can be used to report errors" (STD 10)
Yes, it "specifies who the mail is from", "a return route (which
may be used to return a message to the sender when an error
occurs with a relayed message)", "contains the source mailbox",
"a reverse source routing list of hosts and source mailbox",
"a source route from the current location of the message to the
originator of the message)". Finally "send it to the originator
of the undeliverable mail (as indicated by the reverse-path)".
Want more ? I skipped some less CLEAR "should", but when I said
*_criminal negligence_* about any "bounces-to" I was NOT joking.
~~~ end ~~~
That was in one of those discussions with Bruce, and the bit
about "criminal negligence" was with John (the author of 2821).
IIRC you also find the "literal" concept of MAIL FROM in 2821,
not only the "bounces to" version. In chapter 2.1 you find:
Such a transaction consists of a series of commands to specify the
originator and destination of the mail and transmission of the
message content (including any headers or other structure) itself.
So here the MAIL FROM is an originator, whatever that might be.
[RFC2821, section 4.1.1.2 MAIL (MAIL]
The reverse-path consists of the sender mailbox.
That's also fine.
[RFC2821, section 4.4, Trace Information]
It is possible for the mailbox in the return path to be different
from the actual sender's mailbox, for example, if error responses
are to be delivered to a special error handling mailbox rather
than to the message sender.
Yes, we discussed this, Note "other mailbox", as long as it's
in the same "MON" (mail originating network, a term created by
Keith) as the "originator" I've no problem with it. Only if
it's elsewhere we're in the known 2821-deep-shit.
the standard clearly allows that.
The _proposed_ standard. Otherwise we're back to 1123. They
screwed up royally, everybody sees it in his mailbox or his log
files.
I think we can safely say that there is never a valid reason
for the domain to be different in the return-path and From:
headers.
No, when I sent MAIL FROM:<####(_at_)hamburg(_dot_)de> I still used my
normal 2822-From: nobody(_at_)xyzzy What I do in the mail (DATA)
is nobody's business but mine (and of the receiver).
And of course error reports went to ####(_at_)hamburg(_dot_)de because
that was the route I used.
if mail from A does not make it to B, then the very last you
need to analyze this problem between A and B is a third
system MAIL FROM C.
Agreed. This is totally screwed up, but permitted.
Okay, then set A = ####(_at_)hamburg, B = dont.care, I can then
still use 2822-From: nobody(_at_)xyzzy The point is that I really
submitted at the MSA of A. Then it's okay.
But if I'd use MAIL FROM xyzzy submitted at the MSA of A it
would match the 2822-From, but it won't work for several
reasons:
- the MSA of A won't let me use an unknown MAIL FROM
- my own xyzzy sender policy would FAIL for all IPs of A
- it's stupid if I'm interested in errors between A and B
- it's not what STD 10 intended, it's "bounces to" but no
"return path" / "reverse path" / MAIL FROM / originator
have you ever worked in a place where they actually had
someone designated to receive bounces for you? Would you
even want that?
At the moment yes, I get tons of "misdirected" bounces. And
generally I do want nobody@ as a "public" address (also for
bounces when I send via that route), but rarely I use other
2822-From addresses for special purposes.
It's a catch all, sometimes this makes sense. In CfVs (call
for votes, Usenet) I use the Message-ID also as 2822-From.
In nanas I use From: reason(_at_)symantec(_dot_)invalid if it's again a
case of net abuse by Symantec products. Etc., but it's rare.
For a human mail sender, I think this is a theoretical idea
but not a real case.
For me it's a rare case. And sometimes I even use a Sender
reflecting the MAIL FROM, especially if I send abuse reports
about spam to my A-address using an MTA with my C-address -
I don't want to confuse abuse desks, so I say 2822-From: A
plus MAIL FROM C with Sender C.
[...]
I thought RMX was a great idea and supported it, but it got
zero adoption and is all but off the radar today.
Yes, SPF replaced it.
[...]
remailers SHOULD append another header, as should anyone else
sending a message on behalf of the original author.
But Resent-* for a mailing list ? I've never seen that. They
use Sender or Errors-To and/or List-* header fields. I can't
really judge it, I'm behind a mail2news gateway, and almost all
lists I know are Mailman lists. The one Errors-To exception is
a Sympa list.
The last sentence in the above citation makes it perfectly
clear that the requirement in SID for forwarders to add
Resent-*: headers is contrary to the RFC's, not to mention
actual practice since the beginning of email.
Yes, although I'm not sure where that could cause any trouble.
[...]
Please don't say "you" and "Sender-ID drafts" in the same
sentence, thank you very much.
Okay, I thought you started to "reinvent" SenderID with some
minor twists. IMHO they did the best they could do with the
2822 header fields. It's not good enough, but I also see
no way to make it better. Not below DKIM or William's ideas.
[...]
I suggest that as SPF gains deployment, MTA's that send a lot
of messages that fail SPF are going to get bad reputations.
Oh yes, a.s.a.p. please. Each and every FAIL for my "xyzzy"
is a 99.9% sure indicator that a zombie is talking with you.
"Greylist" it for some time if you're paranoid - it will show
up on normal blacklists very soon. Or just block it (AGUPI).
SPF FAIL can be used as "blacklist accelerator" for some time.
Maybe not forever, spammers will adapt, but for some years.
Why the IETF, as a technical organization, will even give
them the time of day after that debacle is a complete mystery
to me.
Please don't confuse Mr. Hardie with the IETF. Three IESG
members rejected Sender-ID (Sam, Scott, David - but the latter
also hates SPF), and three didn't vote (Bill and two others I
don't know). I've no idea why Russ and Margaret let it pass,
I thought that they are decent folks. Maybe an error on my
side, or some other "process failure".
Bye, Frank