One thought I had: What you call "MON" in your memo should be
also an "MRN". Otherwise I'd say that those who don't want to
get mail (incl. error messages) have no business to send mail.
MONs aren't tied to addresses; MRNs are. A holder of an
address needs an MRN to be able to receive mail, but he might
wish (or need) to send mail from that address via an MON
unrelated to the MRN that accepts incoming mail for that address.
But they must not send a MAIL FROM "non-local user" (in your
terminology) where error messages would hit another MON / MRN.
That BTW is the pretty simple idea of SPF.
and that's one of the reasons SPF is broken. there are plenty of
valid reasons to send a MAIL FROM that's unrelated to the MON
being used to send it.
what I would say is that there needs to be a way for originators
to establish the ability to use a particular MAIL FROM address
without having to submit the mail via a particular MON - say
by using a digital signature with a cert signed by the MRN for that
address.
When you said 'brain-dead authentication schemes' on the IETF
list I hope you meant PRA or whatever else, not the simple SPF,
both SPF and anything using PRA fall into that category, for
different reasons. though some parts of SPF are saner than
others, and I am not sure what you mean by "simple" SPF.
That started with your "define 'sender'" remark, and checking
RfC 3834 I found that you also avoided to define it. But you
have a very clear concept which of the "return addresses" is
suited for auto-replies, of course the MAIL FROM, and not some
braindead (now I say it) PRA / Sender / Reply-To / 2822-From.
The real "purported responsible address" is the MAIL FROM, the
PRA idea is just wrong, and tricks with Resent-* addresses are
madness.
no, the purported responsible address isn't MAIL FROM, nor
should it be. there are valid reasons to send bounces to an address
other than that of the person responsible for sending the message.
but there is a need to establish that the originator has _permission_
to use that address.
<rant> If the IESG really allows this PRA-"experiment" abusing
policies designed for the MAIL FROM they are too incompetent
to serve the net at large in any position. </rant> Cowardly
bypassing a proper "last call" is also a very bad sign. It
would not only hurt SPF, but also SMTP.
yup, and I need to start explaining why PRA is a lousy idea. I've
been too busy with other things.
I don't think it's good to require a special-type of MSA for
anonymous mail.
For anonymous mail you need special authentication and privacy
tricks, the goals are very different from a simple accountable
sender. I don't know much about the technical problems, and
reading the APAS (alt.privacy.anon.serers) FAQ some years ago
didn't help, but unlike MSAs and SMTP it's not more "simple".
And draft-hutzler wants to be simple, the audience are normal
admins at normal ISPs.
well, there's different degrees of anonymity.. you need a different
level of anonymity to protect you if you're whistleblowing
on your employer than you need to protect you if you're trying
to expose the crimes of the Bush administration.
but I don't want a BCP that precludes anonymous mail, or for
that matter, one that precludes letting a sender use any From
or MAIL FROM address he has permission to use, regardless
of what MON he is using to send the mail.
we need to stop pretending that there's a relationship
between From address and the MSA used by the originator
See above, of course there's a relationship between a "sender"
and the MSA where MAIL FROM "sender" is submitted.
yes, there's a relationship between the originator and the MON.
yes, the originator needs permission to use the MAIL FROM address,
and perhaps the From header address also. But there doesn't
need to be a direct relationship between the From address
or the MAIL FROM address and the MOA.
It doesn't
work without this accountability. With your idea, only an ID
in the timestamp, you'd get first the "bounces to" the forged
MAIL FROM, that's reported to abuse(_at_)MSA, and then somebody has
to decode the ID and warn / block the user of the infected box.
really what I think should happen (eventually) is that every MTA
can establish whether the originator had permission to use the
MAIL FROM before it agrees to accept a message. but that
requires protocol extensions that aren't in scope for the current
document(s).
Keith