Keith Moore wrote:
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.
Now all I mentioned _is_ client to server, and unrelated to any
originator: SPF-HELO and CSV are about HELO. MTAMARK is about
"yes, this IP is used for an MTA" vs. "no, this IP is no MTA".
SIQ simplifies the lookup of FQDN and IP simultaneously, it
could cache (FQDN, IP, TTL, result) removing the different
methods to determine such results from the equation, from the
POV of the MTA (server) interested in the result for a client.
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.
If you use another MSA just use the MAIL FROM related to this
MON, and if you want the error messages elsewhere forward them.
The results are very similar:
1 - you submit at A with MAIL FROM:<you(_at_)B> RCPT TO:<trouble(_at_)C>
- trouble(_at_)C, somehow C sends an error message RCPT TO:<you(_at_)B>
2 - you setup .forward your(_dot_)errors(_at_)A => you(_at_)B
- you submit MAIL FROM:<your(_dot_)error(_at_)A> RCPT TO:<trouble(_at_)C> at A
- trouble(_at_)C, C sends a error message RCPT TO:<your(_dot_)errors(_at_)A>
- A forwards your errors to you(_at_)B
The second scenario is 100% pure STD 10, you could only say
that it introduces a new source of trouble between A and B.
OTOH it removes any potential trouble between C and B in the
first scenario (which doesn't work well for trouble near A):
1: A --> C 2: A --> C
/ A <-- C
/ |
/ v
B B
Based on that knowledge they can "enforce submission rights"
yes they can, but it's not something we should encourage.
IBTD, it does what STD 10 used to do, take the responsibility
for what the MTA sends, including any trouble it might cause.
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.
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.
I don't see SHOULD NOT, but seeral security considerations and
a SHOULD for more desirable ways.
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.
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:<>
Bye, Frank