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.
If you use another MSA just use the MAIL FROM related to this
MON, and if you want the error messages elsewhere forward them.
no, that's not acceptable, for lots of reasons. one is that forwarding
isn't always available, and when it is available it's not always
reliable. another is that you want to be able to use a MON that doesn't
have any address associated with it, maybe because it works better from
your particular location on the network (say you have a fast link to the
MSA you are using but a slow connection to your normal MON's MSA).
another, you sometimes need to use a different MAIL FROM address for
each recipient, or to embed information into a MAIL FROM address so that
bounces carry that information with them.
bottom line: insisting that everyone submit mail through the same mail
network that corresponds to the MAIL FROM is too inflexible.
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.
Yes, but with enforced submission rights it has to know how to
derive a permitted MAIL FROM from the POP-user id, or it has
to hijack both connections (POP and SMTP) from the client.
if you can hijack one, you can hijack both. it's pretty easy to hijack
a connection by setting up your own wireless access point in a public place.
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.
Actually I'm not that paranoid when I use one of my ISPs and
the MSA of an unrelated mail provider. A roaming user in an
internet cafe using the Webmail of his ISP with https is not
necessarily in a better situation than the user in your man-
in-the-middle scenario.
not sure what you mean by that. with TLS the server is authenticated
via the server certificate. a hijacker doesn't have access to the
session key and can't set its own session key without causing the server
signature verification to fail.
of course, there are clients that don't check server certificates, and
there are clients that implement "automatic" fail over from TLS or SSL
to unencrypted - and hijackers can easily defeat those. (we need to
update recommendations for MUAs also)
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.
If your needs are "unnormal" you won't participate in a scheme
offering to limit your routes, you also won't sign up for any
limited acoounts. You then have to solve problems if somebody
forges your MAIL FROM by other means.
this marginalizes a class of users, which is inconsistent with the goal
trying to make email service work well for everyone. to be really
useful email needs to be ubiquitous, and that means it has to be
adaptable to a wide variety of users' needs.
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.
How else should it work ? User defines permitted MAIL FROM
addresses, MSA authenticates user (somehow, see above about the
less desirable ways), user sends mail with permitted MAIL FROM.
If the user tries another MAIL FROM the MSA says "no" (5xx).
RFC 2476(bis) didn't forget MAIL FROM:<>
there are multiple ways to solve the problem. one is that if a user
provides a certificate to the MSA that says "I have permission to use
this set of addresses in SMTP MAIL FROM" then the MSA permits such use.
another way (which only works for individual addresses) is that you get
the MON to send a single message to a MAIL FROM address, the message
contains a cookie, you reply to the message, now the MON knows you can
read mail sent to that address and so are presumably able to use it.
another is that the MSA makes the mail traceable in some way other than
MAIL FROM to a user who can be held accountable for his actions - then
if the user sends out mail that abuses MAIL FROM then he gets billed for it.