ietf-smtp
[Top] [All Lists]

Re: MTAMARK etc.

2005-05-25 05:06:26

On Wed May 25 2005 05:43, Tony Finch wrote:

On Tue, 24 May 2005, Bruce Lilly wrote:

As I understand it from a quick skim, there are however some issues:
1. it speaks of MTAs and mail severs, however an MUA or MSA may also
   send mail, and there is at present no way for an SMTP receiver to
   determine whether the connected sending client is an MUA, an MSA,
   or an MTA.

This is usually done operationally, by providing different service
addresses for MTAs (your MX hosts) and MUAs (your MSA hosts).

MX refers to receiving servers, not sending clients.  Not all sending
MTAs have MX records, as some are not public MX hosts for a domain.  A
sending MTA with an MX record is either sending inside an administrative
zone, is a host that happens to run multiple types of agents (or appears
to do so via a NAT-like mechanism), or is an open relay.  MUAs (clients)
and MSA (clients side and server side) are separate architectural
entities.

An MUA 
connecting to an MX isn't going to have an easy time.

In fact the SMTP model is just that, and schemes that seek to prevent it
are harmful to the Internet mail system.  From the SMTP RFCs:

               +----------+                +----------+
   +------+    |          |                |          |
   | User |<-->|          |      SMTP      |          |
   +------+    |  Client- |Commands/Replies| Server-  |
   +------+    |   SMTP   |<-------------->|    SMTP  |    +------+
   | File |<-->|          |    and Mail    |          |<-->| File |
   |System|    |          |                |          |    |System|
   +------+    +----------+                +----------+    +------+
                SMTP client                SMTP server

                ^ this interacts with the user, and is therefore an MUA

The MSA concept is rather weak in Internet email. It only really makes
sense as an SMTP receiver. Its sending side operates as an MTA. It isn't
necessary to talk explicitly about MSAs when writing about MTA-MTA
communication.

Nevertheless, it is identifiable as a distinct entity architecturally;
several schemes are based on restricting certain operations to MTA-MTA
connections, and the simple fact is that with the current protocols there
is no reliable way for one party (client or server) to determine whether
the other party is an MUA, MSA, MTA, MDA, a telnet session, a zombie, etc.
 
2. it speaks of "unauthorized message transmission", but SMTP has
   no authorization mechanism (unlike, say, IMAP, but then IMAP isn't
   used for sending (pushing) mail).

Authorization in SMTP is determined administratively, either based on SMTP
AUTH

SMTP AUTH is authentication, not authorization.  See FYI 36.  The only
meaningful type of authorization that could be applied to use of a
MAIL FROM mailbox would be some scheme that includes explicit authorization
records with a public yet secure infrastructure for a database for those
records, incorporates authentication, uses a digital signature, and
(necessarily) involves some sort of PKI. 

or other out-of-protocol criteria such as DNS blacklists. MTAMARK and 
CSA are new ways for one site to communicate authorization policies to
another site. Since it's an out-of-protocol extension,

MTAMARK in particular seems more a way for a receiver to make a
time-dependent assumption in the absence of information.