At 10:35 AM 9/29/2003, Markus Stumpf wrote:
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.
I added this language to the next draft version:
If there is no MPC declaration in the EHLO reply, "ALLOW */*" is
implied and the client may proceed.
>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".
I also added this language:
If the MPC value of message to be delivered matches any DENY
declaration in the EHLO reply, the client MUST issue a QUIT command
and refrain from retrying the message, and the client SHOULD deliver
a corresponding bounce message to the sender.
Thanks for noticing those.
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.
I don't really understand the question. Why would a user relay a message?
Backup Servers
How should MPC work with backup servers implementing stronger MPC than
the destination host does.
MPC is policy-neutral, and doesn't have a concept of "stronger" or
"weaker", perhaps you mean "more restrictive"?
Why would backup servers have different MPC than the servers they back up?
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.
In AMTP, a message cannot be relayed from one "public" MTA to another
"public" MTA. In your example, all but one transaction would be
accomplished with private network connections (i.e., using privately-signed
certificates).
------------------------------------------------------------------------
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.
As I understand it, the TLS handshake includes logic to verify that the
presenter of the certificate has the corresponding private key for the
certificate. I don't see an easy way to do that without TLS.
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.
I had that in the first draft, but I became convinced that it was unnecessary.
Part of the goal of AMTP is to produce the least-restrictive specification
that still provides the required benefits. Unless I'm missing something,
there is not a significant problem with rogue receiving MTAs hijacking
email. If I'm wrong about that, please let me know.
------------------------------------------------------------------------
SRV records
Why do you want to make MX records obsolete?
It wasn't a goal to obsolete MX records, and the SRV records weren't in the
original draft. But it solves a significant problem: How to transition from
SMTP to AMTP without the overhead of attempting both protocols for a lot of
deliveries.
If both protocols were to use MX records, the only way to know if a server
MTA speaks AMTP would be to try the AMTP port #. That would fail often,
especially at the beginning of the transition period. With SRV records, you
will know which protocol to use before you connect.
The side benefit is that the MX RR was a kludge and AMTP will allow it to
eventually die of natural causes.
------------------------------------------------------------------------
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?
That's an implementation detail, and I think that what you described is a
smart behavior and will likely prevail during the transition period. On the
other hand I can see where some servers may not want to do that, so I think
it's best to leave it out of the specification.
Thanks for the thoughtful comments. I've added your name to the
acknowledgements section in the next draft.
--Bill
---
Never send a monster to do the work of an evil scientist.
~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~
- Home <http://bw.org/> | Whois <http://whois.bw.org/>
- Music <http://music.bw.org/> | Blog <http://blog.bw.org/>
- Gimme back my email! <http://amtp.bw.org/>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg