----- Original Message -----
From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>
To: "'Ted Hardie'" <hardie(_at_)qualcomm(_dot_)com>;
<ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Monday, March 15, 2004 9:04 PM
Subject: RE: DRAFT charter
This makes sense to me.
Yes. Same here, with the same concern you have:
I am a little concerned that we have the 'authorization' language in the
draft. There is a concrete distinction here as to scope.
For example, this is what I have to deal with from a production standpoint.
At the layman level (my customers), the distinction will need to be very
clear with the SMTP authentication options already provided:
Allow Relay/Routing Options:
[X] IP relay tables
[X] ESMTP Auth
[_] Required for all connections (Intranets Only)
[X] POP3 before SMTP
Of hand, I don't think I want to get into addition a forth option:
[X] LMAP based authentication
atleast not using the current specification that lacks LMAP/DNS record
sender profile spoof protection and has the high protection to hide
reputation (LMAP compliant spammers).
However, if it does become a general MTA authorization method, I might
have to change it to something like this but I will most definitely add a
sub-option to LMAP to keep it with backward SMTP compatibility (or BCP) of
allowing only final destination mail for anonymous access.
Sender Authentication Methods
[X] IP relay tables
[X] ESMTP Auth
[_] Required for all connections (Intranets Only)
[X] POP3 before SMTP
[X] LMAP based authentication
[_] Allow Relay/Routing
Also, in the issue of "reputation" we have an option:
[X] Use RBL for IP rejection
[X] Ignore RBL rejections if authenticated
Anyway, I didn't want to get into details like this and I certainly hope I
am not out of line with the IETF process, but that is what I have to think
about across the board. A genreal "MTA authorization" concept has the
potential of creating a stirred pot of too many other interface point
considerations.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com