Seth Goodman wrote:
Sender and Resent-* (like Reply-To) are rarely used, and
where they are used they might be often redundant.
Rarely used, yes, but redundant? Show me an example.
Sender = Return-Path might be redundant. All cases where
the dubious SHOULD in senderid-core would work as expected.
Hector sometimes says that this is about 80% of all mails.
Sender: indicates one party submitting mail on behalf of
one or more other parties.
Submitting it _somewhere_ but not necessarily SMTP, it can
be UUCP, NetNews, a mailing list, a Web form, whatever.
When it's _later_ "injected" into SMTP or redistributed
by a mailing list the original sender is unrelated to the
"injector" (some gateway) / redistributor / 251-forwarder.
Gateway / redistribution / 251-forwarding isn't the same
as MSA = 2476-submission. In some cases you can map it
to "like an MSA" (e.g. Webmail), in others you can force
it to be like an MSA (mailing list abuses Sender for its
own purposes), but generally it's different.
please show me where the standards say otherwise.
It's an _old_ problem, one coherent predecessor of what
we know today is apparently RfC 724 (1977). It's fun to
read how that changed over time 733, 822 (1982), and how
they tried to get the "interface" between mail and SMTP
right (822 explains why Return-Path is not the same as
Reply-To, and adds Resent-* to the mess)
Then they refrained from making it worse for two decades,
the next and so far last attempt was 2822. Mainly about
syntax identifying obsolete crap, but also claiming:
| 10. Forwarding and resending redefined.
For Resent-* that's apparently the new idea of multiple
Resent-* blocks, and an explanation why that's not the
same idea as MIME-forwards or 251-forwards.
I'm far from sure what 822 wanted, maybe it offered the
Resent-* idea for 251-forwarding. It's also fascinating
to read appendix C in 822 (changes from 733). At this
time (1982) SMTP was one of many ways to transport mail,
and the Internet was not everywhere.
Your proposal to ignore gateways and talk only about SMTP
probably won't pass a 1982-giggle test, we'll test it as
soon as Wayne has fixed the 2003-restriction in his time
machine... ;-)
As ex-Fido- and ex-UUCP- and still Usenet-user I refuse to
ignore gateways and related issues. If you want to talk
only about SMTP it's fine, but in that case let's treat
Sender / From / etc. as opaque, for SMTP what we have is
HELO / MAIL FROM / RCPT TO, the details of what's within
the DATA are mostly irrelevant (excl. the timestamp lines
and the Return-Path).
As soon as you look _into_ the DATA for any other header
fields it's not more SMTP-only, but a gateway perspective.
SPF only has meaning under SMTP,
Yes
ditto DK, DKIM
As long as you have DNS it's not restricted to SMTP. or
did I miss something ?
CSV
Yes
and last and certainly least SID.
Same question as for DKIM, is PRA limited to SMTP ?
Even forwarders rewriting the return-path, as in SRS,
is treading on very thin ice with regard to standards
Yes, and that's probably why they claim that SPF is
"experimental", they want us to test how thick the ice
really is... ;-) OTOH I've no problem if a forwarder
emulates 551 with 251-forwarding to an SPF-enabled MTA.
Still only one incident in now more than 15 months.
SID repurposing of headers that have had a more or
less clear meaning for a couple of decades, even if
they are rarely used, directly contradicts existing
standards.
Hard to tell for Resent-*, if it was meant to reflect
251-forwarding before 2822. But even then it doesn't
address all gateway issues.
what the dickens is a page describing the operation of
Sender-ID as a recommended way for large companies to
send bulk mail doing on openspf.com?
Oops, I didn't know "what the dickens" ;-) Is that the
same Dickens (admittedly I read only one, and it's the
oldest lang=en stuff I ever tried - but it was funny ;-)
Could somebody please take this page down?
Seconded. Bye, Frank