ietf-mxcomp
[Top] [All Lists]

Re: Improving SUBMITTER - Persisent User Address/Account (PUA)

2004-07-12 20:10:59


----- Original Message ----- 
From: "Greg Connor" <gconnor(_at_)nekodojo(_dot_)org>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Cc: "IETF-MXCOMP" <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Sunday, July 11, 2004 2:44 AM
Subject: Re: Improving SUBMITTER - Persisent User Address/Account (PUA)


I think everything you suggested here is consistent with the SUBMITTER
draft, though it's probably a good idea to improve the draft with a couple
of use cases so that this is more clear.

Well, it is all indirectly implied, but it has all the conflict direct and
indirect "implied" requirements for compliance at the MUA.

Based on this, I think your explanation of PUA is consistent with the way
PRA and SUBMITTER are already described.

....

Anyway this is yet another way that RFC2476 has given us some ammunition
we
can use -- we just need point people at it and remind them that this has
been expected of them for 5.5 years and what we are proposing is not that
dramatic.

Reminder: ESMTP AUTH is still an extension hence the E in SMTP. :-)

Oh, It is extremely dramatic.

From a user support standpoint, support requirements are drastically reduced
when the user is authenticated by IP.   Since ESMTP AUTH was an extension,
early wide adaptation was unrealistic hence the usage of POP B4 SMTP to
resolve the issue.  (Note: This is how a ISP customer explained it to me in
how POP B4 SMTP help reduced his support requirements for end-users not
having ESMTP AUTH support).

Starting on July 13, Bellsouth now requiring ESMTP AUTH for all MUAs is to
resolve their growing wireless roaming user market.  It had nothing to do
with address the spam problem per se, SPF or the yet to be endorsed and
supported SUBMITTER.

Bellsouth.net added an neutral SPF and it is now force all users to use a
Bellsouth.net SPF domain.   I really don't think bellsouth.net realized
this.

They don't see it yet because  I am white listing bellsouth.net at my final
destination.  But when you remove the white list, you run into situations
where the return path identity is changed and accepted at the MSA but
rejected at the MDA.

This implies a chain of compliance and trust across the board.  Not just at
the MSA.

When you see a problem in your face, you immediate see what are the ideal
required technical solutions.    The PUA only reduces the compliance
requirement at the initial MUA and MSA not requiring ESMTP AUTH (for
SUBMITTER reasons) and at the same time, provides some level of confidence
and accountability for a full address validation. Not just the domain.

In no case , however,  it does not address the downlink compatibility
requirements. That still needs to be address. :-) and if we must change
everything, well, there are full better ideas than SUBMITTER/SENDER-ID, like
just having a HEAD command.

Thanks for your input Greg.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com