I think I may have gotten lost reading this proposal, here are some
comments based on my best understanding. Let me know if I'm just
missing the point:
On Jul 9, 2004, at 9:58 PM, Hector Santos wrote:
Maybe I didn't quite see if this is "implied" in SUBMITTER proposal.
If
not, then the following may add some strength to the proposal.
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).
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
In this case, alias.com must have a MARID record that authorizes
example.com to send mail on it's behalf. Why is anything more
necessary?
If you meant:
2821 MAIL-FROM: private(_at_)alias(_dot_)com
2822 FROM jqp(_at_)example(_dot_)com
then the SUBMITTER must match the 2822 from which in this case is
jqp(_at_)example(_dot_)com, so additional restrictions are not necessary.
If you meant:
2821 MAIL-FROM: private(_at_)alias(_dot_)com
2822 FROM someone(_at_)somewhere(_dot_)com
then somewhere.com still has to have authorized example.com to send
mail on it's behalf.
As many people have pointed out, somewhere.com may be a pretty
worthless domain, and authentication is not sufficient to end spam.
If example.com is well run, they will have their own policies to make
sure that someone(_at_)somewhere(_dot_)com is legitimate regardless of whether or
not somewhere.com has authorized them to send mail on their behalf. I
can see the option of forcing the SUBMITTER to the PUA as being one way
for an ISP to enforce such a policy, but I'm not clear on how it works
with the rest of the PRD algorithm. ESPs and hosted vertical
applications will need to use other methods, and a large majority
already have some level of controls in place.
This does serve as a reminder of Dave Crocker's point at the interim
meeting that channel does matter, but I am inclined to think that
channel validation and domain validation should be kept separate.
I'll observe that ISP email accounts are in general a fair amount
(sometimes infinitely) cheaper than ESP or vertical application
accounts that permit anything other than trivial volume, and therefore
the cost constraints in these sectors are quite different. I would not
expect to find a single end user verification method that worked well
for all types of channel.
Margaret.