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

At 04:15 AM 10/2/2003, Brad Knowles wrote:
>         If you don't control the other machine, how are you going to 
> control what they use for MPC?  If you don't control the anti-spam 
> settings for the other machine, how are you going to control what spam 
> gets into your system?
You don't seem to belive that trust can be created between two systems. If 
you're right, AMTP will not work. Personally, I think it will.
In my vision, *most* systems will follow the rules. Those that don't will 
try to obfuscate and hide and lie. With authenticated connections they will 
be easier to find and isolate. That sounds to me more manageable than what 
we have today.
> >  The EHLO reply preemptive MPC feature is not for everyone. I'm assuming
> >  most large ISPs will not use it. But it's an excellent solution for
> >  corporate mail servers where the corporation wants to control costs and
> >  set company-wide policies.
>         Homogenous network environments where the same policy is applied 
> to everyone is not going to be a particularly large subset of users.
My research suggests that a significant number of corporate and community 
(co-ops, municipalities, user groups, etc.) admins want server-wide 
policies. ISPs have more complex needs and will use per-recipient settings, 
and even some per-sender settings. (Note that per-sender settings *can* be 
advertised in the EHLO reply.)
> >                              But I expect many ISPs to have various
> >  settings available for their users to set on a recipient-specific
> >  basis. Like they do now with spam filters.
>         Which implies that we need some sort of mechanism to be able to 
> communicate this information later in the SMTP dialog.
Yes, that's done in response to the RCPT command (section 4.4.3 -- see the 
last example, page 11).
>         Moreover, if we had that, and could advertise that information 
> via EHLO, everyone would be better off -- homogenous network environments 
> applying the same policy to everyone would be able to continue to do so, 
> while heterogeneous network environments with per-user control over these 
> features would also be able to make use of this functionality.
That's done in the RCPT response. You seem to be suggesting a per-recipient 
advertisement of MPC values. I decided against that to keep down the number 
of round-trips. As the spec currently stands, a client doesn't get per-user 
MPC values, it just gets 250 or 550 (or occasionally 451) reply codes for 
each RCPT.
I considered advertising the per-recipient settings as a way to preempt 
further transmissions from a sender, but that quickly became overly complex 
to implement. In the EHLO response, the MPC advertisement is really only 
there as a convenience to preemptively abort conversations that are 
guaranteed to result in a 550 response later on. It's not vital to the 
operation of the protocol, but it can be handy in some circumstances.
>         Of course, this doesn't solve the problem with backup MXes.  Or 
> senders that ignore this feature because it is inconvenient.
Do you mean "senders that ignore the MPC values in the EHLO response"? They 
will get a 550 later in the conversation. And they risk getting added to a 
CRL.
Backup AMTP servers may well need some extra logic. I will give that some 
more thought and see if I can find something that needs to be addressed in 
the spec.
--Bill


---
"He who lives by fighting with an enemy has an interest in the preservation 
of the enemy's life." --Nietzsche
~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~
 Bill Weinman <http://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