ietf-asrg
[Top] [All Lists]

Re: [Asrg] 6. Proposals - AMTP (rev 01) - MPC

2003-09-29 08:37:04
On Sun, Sep 28, 2003 at 09:24:41PM -0500, Bill Weinman wrote:
I have just finished a new draft of the AMTP specification. I would welcome 
comments from this group.

------------------------------------------------------------------------
Comment on MPC:
From an ISPs point of view (and even from a multi-user/address
mailserver's point of view) per server MPCs are IMHO useless.

We have mailservers that host some 1000 domains each with 5-500 users.
Same problems apply to big ESPs that might implement MPC based on users.
As one message can have multiple RCPTs the server would always have to
send  250-MPC-ALLOW */*, because it cannot signal an MPC unless it knows
about the recipients email address.

From your examples:
   S: 250-MPC DENY com/* ALLOW com/individual ALLOW com/confirmed
The Client knows about MPC classification of the message it is trying to
send. Maybe you should add a short paragraph about what the Client is
considered to do, if it knows the messages doesn't meet the server
criteria. I assume you want the client to quit the connection
immediately and treat it like a "all recipients permanent failure".

Roaming users + MPC
As a roaming user I might want to relay a email with a MPC that
violates the general server classification (which is IMHO pretty valid,
even more if the remote server/recipient will accept it). I am missing a
specification on how to handle this.

Backup Servers
How should MPC work with backup servers implementing stronger MPC than
the destination host does.

IMHO the biggest problem with your MPC idea is that you reduce the
specification to end-to-end connections, but these are relevant only to
a very small fraction of every days Internet email connections. Most
connections are  client <> server <> server ... server <> client
and this makes server MPC unusable at all.

------------------------------------------------------------------------

TLS/X.509

Just for clarification ...
Do you want to enforce both encryption (TLS) and authentification (X.509)?
Authentification via X.509 doesn't necessarily need encryption. Thus you
could "gain trust" without TLS just by exchanging/validating X.509 certs.

Why don't you also define authentification/trust policies for the receiving
host? This would add additional security and address the problem of
rogue receiving MTAs intercepting emails.

------------------------------------------------------------------------
SRV records

Why do you want to make MX records obsolete?

------------------------------------------------------------------------
AMTP + SMTP

For (at least) a grace period AMTP and SMTP have to life together.
How should a AMTP capable sending MTA behave? What if the destination
signals AMTP capability via SRV records but the connection cannot be
established. Should it fallback to SMTP?

        \Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>