At 11:44 AM 10/2/2003, Markus Stumpf wrote:
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 :-)))
Yes, it's legal and (yeah, I saw the emoticon) I wouldn't call it a lie. ;^)
I've clarified the meanings of the preemptive declarations in the EHLO
reply for the next draft -- and I'll revisit it to make sure the intent is
clear.
> >As a roaming user I might want to relay a email with a MPC that
> >[snip]
> 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
[ snip ]
The server doesn't have to wait for the AUTH command to know who is
connecting. The certificate is presented during the TLS handshake. In a
circumstance like that, the various servers involved in the agreement could
all agree to accept a certain private CA signer, and choose a policy set
that conforms to that agreed upon in the contract.
> 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.
I suggest you read section 5 and section 7 more closely, then ask your
question again. You and I are talking apples and oranges on this subject.
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
According to my vision all except 2->3 are "private network connections".
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.
Actually I think a *lot* of ISPs (especially free mail providers) will use
"ACCEPT */individual", with some adding "ACCEPT */autoresponder".
All of those connections can benefit from AMTP. The private connections can
gain tremendous flexibility by authenticating the connecting client and
using specific policies for those clients.
Why don't you also define authentification/trust policies for the
receiving host?
[snip]
I had that in the first draft, but I became convinced that it was
unnecessary.
[snip]
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.
Can you document that? I have not seen evidence of DNS spoofing in email
sufficient to warrant an extra burden on the whole system to protect
against it. If DNS is the problem, wouldn't DNS be a better place to deal
with it?
> >------------------------------------------------------------------------
> >SRV records
Dan Bernstein describes MXPS - the Mail Exchanger Protocol Switch
http://cr.yp.to/im/mxps.html
I considered that approach, but I felt that it was messy and overloaded the
MX distance field. It could also confuse an SMTP server that didn't
understand the unconventional usage. SRV seems to me a perfect fit.
What exactly is your objection to SRV?
> >------------------------------------------------------------------------
> >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
> 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
IMHO it is important to even talk about implementation details.
Yes, it's important to discuss them and I intend to. I'm writing a separate
paper about it. But I don't see it as a subject for the protocol
documentation. I may submit my transitional whitepaper as an I-D. I haven't
really decided that yet.
--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