Keith Moore wrote:
in mail submission the client is the originator, in mail
relaying the client is just a random MTA. so authentication
means different things in the two cases.
Yes. For the latter MTAMARK, CSV, or the HELO-part of SPF can
do the trick (add SIQ and it shouldn't be too expensive).
eventually I think we need a way for originators to
demonstrate that they have permission to use a particular
MAIL FROM, but this requires protocol extensions
Depends. MSAa offered by ISPs or mail providers normally know
which mailbox(es) an authorized user has, for SMTP-after-POP
it's more or less obvious. Not that I'm a fan of this scheme,
but removing POP from the equation won't change the knowledge.
Based on that knowledge they can "enforce submission rights".
One MSA I know with millions of customers (mailto.t-online.de)
even _sets_ the MAIL FROM and the 2822-From no matter what the
MUA says. One of the reasons why I've always supported you and
Bruce when you say that "Reply-To" is strictly user territory -
I just need it for this MSA. Of course no 2476bis-MSA, option
6.1 does not cover to _set_ MAIL FROM, let alone the 2822-From.
They just do it anyway, and those who don't like it can get a
premium account on another MSA.
And for SMTP-after-POP "enforcing submission rights" closes the
window of an "enabled" IP ready to relay for everybody who has
the IP. Hector's one minute window is probably short enough,
so he doesn't need 2476 to close it.
we'd like to get something less ambitious out the door sooner
than that.
It's not that ambitious for ordinary users of the big ISPs. If
the ISP is say AOL the user has an address @aol. While we all
hate to mess with mail headers - trying to fix it makes it often
worse, everybody learned that lesson - it's no big problem to
check and enforce a proper MAIL FROM. Or even _set_ it after
discussing it with the legal department, the privacy officer,
and ideally the user.
Normal users just don't care about it, they want to send mail,
they want to get mail, they hate spam, they need "experts" to
interpret a bounce, so it's our duty that they only get really
relevant bounces, and not arbitrary forged "bounces to" crap.
we need to stop trying to overload MAIL FROM, From, Sender,
etc to be the originator identity. We need a new concept
for that. Sender was close to the right idea
Yes, and MAIL FROM used to be a copy of this Sender. In your
MON-terminology it's an internal business of each MON how they
organize it, as far as I'm concerned they can use BATV, SES,
secy(_at_)MON, secy-daemon(_at_)MON, anon(_at_)MON, user(_at_)MON,
crypto-id(_at_)MON,
or whatever they like, but not whatever(_at_)xyzzy(_dot_)claranet(_dot_)de for
any MON != claranet.de.
So I don't see any need for a _new_ concept, we need the _old_
STD 10 concept, and that's what the RMX-part of SPF does. With
any freedom you like, from not participating at all, aggregate
MONs, or only exclude MONs (e.g exclude IPs listed by SPEWS if
that's what you want).
it's probably not a good idea to assume that the originator
ID is an email address.
If 64 base64 characters are enough just add @MON as RHS. Bye