On Wed, Oct 01, 2003 at 09:16:39PM -0500, Bill Weinman wrote:
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.
Ok. So it is also "legal" for a Server to send a
ALLOW */* (which means no restrictions)
and later on do
C: RCPT TO:<paul(_at_)beatles(_dot_)example(_dot_)com>
S: 550 MPC policy violation
i.e. oviously "lie" about the initial MPC policy declaration :-)))
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?
Example: you have a large company with field workers. You have contracts
with various service providers. The notebooks autoconfigure. If you
are a field worker, you dialin, send your email and disconnect. You
don't want to stay online minutes or hours for a end-to-end connection
to the mailserver of your employer.
So you relay the message through the mailserver of your dialin provider
in any case, to get it off fast, disconnect and the MTA of the dialin
provider delivers the message.
Authorization for relay is accomplished with SMTP AUTH.
Now the field worker wants to tell his boss a funny story about a
customer. He selects MPC per/individual and clicks send.
However the MTA at the ISP only accepts com/* wheras the MTA at the
company would accept */* for the CEO.
As the MTA sends MPC declaration com/* and the clients knows it is
per/individual it will not send the message and QUIT immediately.
Tou cannot outrules this say with a correct SMTP AUTH because they do
not reach that stage in communication.
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"?
Yes. Sorry, non native english speaker ;-)
Why would backup servers have different MPC than the servers they back up?
This has been discussed in this thread meanwhile ;-)
Nothing new to contribute from my side.
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).
I don't understand that.
Assume the following example:
Dialin-User at DialinProvider A
-1-> In-MTA at EmailProvider B
-2-> Out-MTA at EmailProvider B
-3-> MTA at ISP C
-4-> MailGate at Customer D (of ISP C)
-5-> Internal Mailserver at Customer D
This is a scenario happening on the Internet millions of times each day.
All MTAs in that scenario either would have to use ACCEPT */* als MPC
declaration or may not have a less restrictive MPC declaration than
"Internal Mailserver at Customer D" or else their policy will dictate
the what the recipient will (not) see.
-1-> will be authenticated, probably SMTP AUTH
-2-> will not be authenticated (internal conn, time/CPU overhead)
-3-> will use AMTP
-4-> will use AMTP
-5-> might or might not be authenticated (internal conn, time/CPU overhead)
The weak point is -1->. The AMTP connection will not gain much
authentication or security. It is unlikely that "MailGate at Customer D"
does not trust "MTA at ISP C" and still use it as MX to protect itself.
It is unlikely that -3-> will get denied. No ISP can block yahoo,
hotmail, AOL, ... for policy reasons and keep it's customer base.
So except for having some clear evidence that "In-MTA at EmailProvider B"
accepted the evil spam initially it doesn't help much.
------------------------------------------------------------------------
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.
Ok, didn't think of that.
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.
It would add security. DNS spoofying still takes places as there are
enough broken DNS caches out there. Requiring a valid (and CA signed) key
not only on the sending but also on the receiving side would IMHO be
fair and add security. And as the receiving MTA probably wishes to send
out emails itself it would be required to have a valid (and CA signed)
key anyway.
------------------------------------------------------------------------
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.
Dan Bernstein describes MXPS - the Mail Exchanger Protocol Switch
http://cr.yp.to/im/mxps.html
He utilises the distance (prio) field of MX records to indicate
different protocols. E.g. QMTP is at 12801, 12817, 12833, 12849, 12865,
..., 13041
space.net IN MX 12816 mail.space.net.
IN MX 12801 moebius.space.net.
This signals (12801) that a QMTP connection to moebius.space.net is
wanted most. If that fails it falls back to a SMTP connection to
moebius.space.net. If that fails if falls back to the next distant MX
record and as 12816 is not particularly assigned to a protocol is
tries a SMTP connection to mail.space.net.
------------------------------------------------------------------------
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.
IMHO it is important to even talk about implementation details. Look at
HTML and missing details and what the Browser Wars make out of it.
Not specifying this will lead to some MTAs implementing AMTP will fall
back and some won't. So with a misconfigured system some emails will
arrive and some won't. IMHO either all should arrive to compensate for
the misconfiuration or none should arrive to signal the admin that
something is horribly wrong.
Thanks for the thoughtful comments. I've added your name to the
acknowledgements section in the next draft.
Oh .. thanks!
\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