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).
I was referring to client-to-server authentication, not
originator-to-server authentication.
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.
yes, but there are legitimate reasons for not using the MSA offered by
the mail network where you receive your mail, and there are also
legitimate reasons for setting MAIL FROM to something other than the
address at which you normally receive mail.
Based on that knowledge they can "enforce submission rights".
yes they can, but it's not something we should encourage.
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.
that's just broken.
And for SMTP-after-POP "enforcing submission rights" closes the
window of an "enabled" IP ready to relay for everybody who has
the IP.
it doesn't solve the problem of spoofing. SMTP-after-POP is easy for an
man-in-the-middle attack to break. the attacker intercepts the traffic
between the MUA and the POP server, using its own IP address to talk to
the POP server, then it can submit mail from the same IP address at
will. SMTP-after-POP should be a SHOULD NOT or NOT RECOMMENDED just
like AUTH PLAIN and AUTH LOGIN and CRAM-MD5 and APOP, because it's
defeated just as easily.
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.
yes, it's easy to do. it's also wrong.
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.
users have a wide range of needs. it's not acceptable to limit all
users to what you think "normal" users need. and this won't solve the
spam problem anyway, not by a long shot.
I'm all for having a way for MTAs to insist that the originator had
permission to use that MAIL FROM address to send the message. What's
not acceptable is for SMTP or MSA to decide this solely on the basis of
SMTP AUTH credentials or source IP address.
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.
no. MAIL FROM has always been where bounces go. It was often, but not
always, the same as Sender. In the case of mailing lists Sender should
be the original originator (so the list members will know who really
sent the message) and MAIL FROM should point to an address that will
accept bounces from the list.
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.
maybe the owner of a domain has the right to say who can use addresses
from that domain - that makes some sense to me. but a MON should not
have to be associated with a domain. users of an email address have
legitimate needs to be able to submit mail through other MONs. so SMTP
AUTH isn't the right way to establish whether a user can use a
particular domain. there are cases where it is sufficient, but it's not
sufficient in general.
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.
anything that tries to tie domains to source-IP addresses is hopelessly
broken. we should make this a MUST NOT, or at least a SHOULD NOT.
Keith