I was waiting for more input or comments. I guess it is still early. I will
follow up on some of you input.
----- Original Message -----
From: "Margaret Olson" <margaret(_at_)margaretolson(_dot_)com>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Cc: "IETF-MXCOMP" <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Saturday, July 10, 2004 10:52 AM
Subject: Re: Improving SUBMITTER - Persisent User Address/Account (PUA)
o Suggestion to improve SUBMITTER proposal: Persistent User Account
(PUA)
How does this proposal work where the return path domain does not have
a PUA for this user? This is common for ESPs and various forms of
transactional messages (outsourced shopping carts).
If we are all the same wavelength, I would presume this with be a prior
arrangement situation, hence trust is already established. However, in the
name of a domain authorization, a PUA can be administratively assigned to
the relay sender.
Modifying your example a bit for clarity (please let me know if I
misunderstood it!):
ISP: isp.example.com
user account address: jqp(_at_)example(_dot_)com
2821 MAIL-FROM: private(_at_)alias(_dot_)com
2822 FROM private(_at_)alias(_dot_)com
The problem statement is drastically reduced and solved by removing 2nd
level processes from the 1st level process - "chicken vs egg."
From what I understand the basic argument for 2822 is to statisfy an ergomic
requirement for the end user - "the look and feel." That still doesn't
address the question; "Well it looks and feels good, but who is he and why
did I get it in the first place?"
Anyway, there are far too many direct and indirect implied assumptions and
requirements with this. It presumes the MUA is compliant and it presumes
the entire end to end process is compliant. What I don't understand here
if is the
MUA mail creation and sender process must change to comply, then why doesn't
does the MUA mail pickup and mail display logic doesn't change as well? Why
isn't POP3 or IMAP involed here? If there is a Sender: or other header, the
MUA can change its display.
In all, far too many conflictive design issues that in my view isn't call
far.
We didn't even address the full address yet, and that is one of the main
points about PUA suggestion. It immediately provides strength to the MSA for
immediate impact for ALL current MUAs without alteration a reliable mode of
user operations.
Again, that still doesn't resolve down links possible issues. But PUA I
think gets the ball rolling. When downlinks do adapt, they will understand
that the PUA is must closer to a valid address than anything that is being
proposed.
I should state that I suggest PUA only because we have a big company behind
it, not really because I think SUBMITTER/SENDER-ID is a good idea. I think
they are kludges and are bad terrible ideas. I predict undesirable new
situations. I won't go into them again, but I will ask this rethorical
question:
If there is such as high requirement of software change for
SUBMITTER/SENDER-ID compliant, then why not just add a new HEAD command at
SMTP?
From a design and implementation standard, that would be far easier to help
addresss the qoals of SUBMITTER/SENDER-ID and it also prepares us for the
future for other ideas as well.
Finally, there is no justice in all this generalization. That is what makes
this all thing so complex. But I do have a perspective of looking at ALL
that is being proposed from an implementation standpoint, I do have tons of
operational experience with a real customer base provided valuable feedback.
I'll be among the first to implement sound ideas that first well and also
helps solve the problem. No matter what we do, we still need to able to
address the guy that sends a support question I just say today:
How to I get Joe's mom using an AOL account whitelisted to by-pass
the AOL rejecting of mom's address using a CBV?
I mean, AOL is saying the address is no good at the MX and this guy is
saying it is good! SPF returned a neutral result so that didn't help. But
lets said that AOL got its act together and did validate the IP, we still
have not addressed the "Email Address Validation" problem.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com