Re: DRAFT charter

["Hector Santos" <hsantos@xxxxxxxxxxxxxx>]

----- Original Message ----- 
From: "Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx>
To: "'Ted Hardie'" <hardie@xxxxxxxxxxxx>; <ietf-mxcomp@xxxxxxx>
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