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

From: "Hector Santos" <[email-masked]>
Date: Fri, 9 Jul 2004 21:58:11 -0400

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)

Background:

Currently SUBMITTER is used basically when the return path has changed
programmatically.

Under common standards and BCP,  an ISP will accept an user account MUA
message for routing as long as there an MUA IP trust or a persistent user
account (PUA)  SMTP AUTH authentication process has taken place.

Under these standard/BCP conditions,  the MAIL FROM address can be any
address like.  Some systems, like an intranet, may offer an option to force
the MAIL FROM to be a local domain account/address.  This is not the general
case for an open internet system.

And the MUA uses a different address that is not part of the ISP controlled
domain,  it causes a problem for the server because there might not be any
information to provide a submitter address.

This can and will occur with legacy or non-submitter compliant clients.

It also causes problem downlink when a responsible domain is not used.

Solution:

A SUBMITTER compliant server *MUST*  use the ISP user account's persistent
user address (PUA) for the SUBMITTER address when the return path is not
part of the ISP domain.

I believe that has been the missing ingredient in all this. It helps
complete a circle of trust with the MSA/ISP providing a link to the
responsible domain with a verifiable and responsible address, i.e, the user
account mail address.

For example:

ISP:  isp.example.com
user account address:  [email-masked]

User connected via PPP/DSL and is authorized to route via IP relay or SMTP
AUTH.  The user wants to use a different return path.  Ergonomically, the
MUA shows this as a Reply Address in the Account manager dialog box.

A outbound MUA --> MSA transaction:

    S: 220 isp.example.com, Welcome EMSTP server ready
    C: HELO netbiosname
    S: 240 Hello isp.example.com
    C: mail from: [email-masked]
    S: 250 mail from ok
    C: rcpt to: <[email-masked]>
    S: 250 rcpt to ok

This would be a typical situation.

The MSA will use the real user account address because the return path was
not part of the ISP domain.  No dependency on MUA compliance.

This adds great strength the transaction process because the ISP has taken
the responsible duty to account for the authorized sender or return path.

The message is routed to santronics.com:

    S: 220 mail.santronics.com,  Welcome EMSTP server ready
    C: HELO isp.example.com
    S: 240 Hello mail.santronics.com
    C: mail from: <[email-masked]>, submitter=[email-masked]
    S: 250 mail from ok
    C: rcpt to: <[email-masked]>
    S: 250 rcpt to ok

Of course, there are all the other issues that make SUBMITTER problematic.

But from a specification standpoint,  this suggestion helps  improve the
SUBMITTER server logic with both functional  and technical operational
expectations.

Benefits:

-  MUA compliancy not required.
-  SUBMITTER design usage and consistent structure.
-  Higher degree of persistent verifiable responsible "contact" address.

Summary:

The basic goal of SUBMITTER was to accomplish the idea of providing:

       o PRA - Purported Responsible Address
       o PRD - Purported Responsible Domain.

The Persistent User Address (PUA) consideration removes the ambiguity with
the fuzzy term - PURPORTED.

The usage of submitter should only be provided when a non-MARID responsible
domain has been removed from the transaction process.  While a typical Mail
Forwarding situation may create such a situation,  the current SUBMITTER
specification doesn't address other non-mail forwarding situations where the
responsible domain is not longer used.

The SUBMITTER server can use the PUA to provide this consistency in design
structure.

o Security Considerations:

Off the top of my head, I can only see a "privacy issue" where the MUA may
not want the MSA to use the PUA in the user's electronic communications.

Comments?

Please tell me where this PUA idea flawed so I can nix it and more on.

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

---

From: Margaret Olson <[email-masked]>
Date: Sat, 10 Jul 2004 10:52:26 -0400

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:

> o Suggestion to improve SUBMITTER proposal:  Persistent User Account 
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 
> user account address:  [email-masked]

2821 MAIL-FROM: [email-masked]
2822 FROM [email-masked]

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: [email-masked]
2822 FROM [email-masked]

then the SUBMITTER must match the 2822 from which in this case is 
[email-masked], so additional restrictions are not necessary.

If you meant:
2821 MAIL-FROM: [email-masked]
2822 FROM [email-masked]

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 [email-masked] 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.

---

From: "Scott Kitterman" <[email-masked]>
Date: Sat, 10 Jul 2004 15:54:09 -0400

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Hector Santos
> Sent: Friday, July 09, 2004 9:58 PM
> To: IETF-MXCOMP
> Subject: Improving SUBMITTER - Persisent User Address/Account (PUA)
>
>
I think this is absolutely brilliant.  From the perspective of a small
domain owner that doesn't run my own MTA (aka vanity domain), this has the
potential to resolve my concerns about use of shared MTAs as designated
senders.  I would go one step farther and allow authorized submitters to be
identified in the sender policy.

I currently use SPF, but have ?include:isp.net in my SPF record because I am
concerned about someone else forging my domain from the isp.  This isn't
much use.  If I could designate an authorized submitter, then I would be in
a position to make a stronger statement about the message being auuthorized.
If I could, instead, have +submitter:[email-masked] in my record it would
say something positive.

Receivers could then retrieve my sender policy record and match the
submitter against my policy statement.  If they don't match (and if nothing
else matches in the record) then the test fails.  If the submitter matches
what's in my policy record, then they would have to retrieve isp.net's
policy record to see if the mesage really came from their network, but they
would have to do that anyway to support the include: that's there now.

I believe that your proposal in combination with supporting changes in
sender policy definition would add significant strength to the Sender-ID
proposal.

Scott Kitterman

---

From: Greg Connor <[email-masked]>
Date: Sat, 10 Jul 2004 23:44:45 -0700

> o Suggestion to improve SUBMITTER proposal:  Persistent User Account (PUA)

Actually, that is very close to the original intent of PRA I think...  Your 
explanation of what Persistent User Account would mean sounds almost 
exactly like what I think "Sender:" is supposed to mean and how it is used. 
This is probably the reason Sender: was included as a part of the PRA spec.

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.

More info on Sender: and return path follows...

RFC2476 went into some detail about Sender:, saying for example that if the 
local user is known on initial submission (MUA to MSA) then MSA may put in 
Sender: based on what it knows.

> 8.1.  Add 'Sender'
>    The MSA MAY add or replace the 'Sender' field, if the identity of the
>    sender is known and this is not given in the 'From' field.
>
>    The MSA MUST ensure that any address it places in a 'Sender' field is
>    in fact a valid mail address.

So there is already a precedent that says MSA should put in the user's 
information and make sure Sender: is right... but unfortunately RFC2476 is 
not followed as often as it should be.

Perhaps the best thing we can do in this case is to remind users (and 
sysadmins and support people) that if their From: address is not local to 
the network they are currently on, at least Sender: should be.

We *could* do this in the document that defines PRA and refer people to 
RFC2476 to lend strength to our assertion that the MSA should add Sender: 
if the locally-known user is different from the claimed From: address.

Based on this, I think your explanation of PUA is consistent with the way 
PRA and SUBMITTER are already described.  PRA is a formula to determine 
"who injected this message into the mail stream" in a way that lends itself 
well to IP-based checking.  Forwarding is one example of this, but when 
From: != Sender: this also applies.  SUBMITTER augments PRA by saying if 
PRA != MAIL FROM, use SUBMITTER to tell who the PRA is.

Therefore ISPs have a choice - either force outgoing mail to have a local 
account in MAIL FROM, or use PRA and SUBMITTER by way of setting Sender: to 
the local account.  I believe this is almost exactly what you are proposing 
with PUA.

RFC2476 also talks about "return path" - and this is interesting in the 
case where ISP allows users to specify any MAIL FROM they want.

>    If an MSA is not able to determine a return path to the submitting
>    user, from a valid MAIL FROM, a valid source IP address, or based on
>    authenticated identity, then the MSA SHOULD immediately reject the
>    message.

It goes on to say that an MSA can deal with problems by rejecting inline 
with SMTP, or by accepting and sending a bounce message, but it 
specifically says that bounce messages are not acceptable in the case where 
it can't correlate the return path to the submitting user.  I think this is 
a key difference between MSA and MTA, but unfortunately a lot of ISPs don't 
follow RFC2476 closely enough.  (I think if more ISPs would take this part 
seriously there would be a lot less forgery going around.)

So, how does an ISP "determine a return path to the submitting user"?  ISPs 
could easily do this by asking users what other email addresses they would 
like to use, even non-local ones, and sending a verification email to the 
claimed address to ensure it really belongs to the user.  (If they want to 
use any localpart in their entire domain, the verification email could be 
sent to postmaster@domain.)  This would allow users to use return addresses 
not local to their ISP, and keep the ISP compliant...  If the return path 
is non-local they would still need Sender: or SUBMITTER or PUA or 
something, so that the receiver has something to check besides the 
non-local name.

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.

--
Greg Connor <[email-masked]>

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 12 Jul 2004 22:48:38 -0400

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" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: "IETF-MXCOMP" <[email-masked]>
Sent: Saturday, July 10, 2004 10:52 AM
Subject: Re: Improving SUBMITTER - Persisent User Address/Account (PUA)

> 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.

> 2822 FROM [email-masked]

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.

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 12 Jul 2004 23:11:34 -0400

----- Original Message ----- 
From: "Greg Connor" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: "IETF-MXCOMP" <[email-masked]>
Sent: Sunday, July 11, 2004 2:44 AM
Subject: Re: Improving SUBMITTER - Persisent User Address/Account (PUA)

> 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.

> PRA and SUBMITTER are already described.
>
> ....
>

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.

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 12 Jul 2004 23:49:17 -0400

----- Original Message ----- 
From: "Scott Kitterman" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, July 10, 2004 3:54 PM
Subject: RE: Improving SUBMITTER - Persisent User Address/Account (PUA)

> concerned about someone else forging my domain from the isp.

At first, I was thinking you meant just having a MX directive in your own
SPF records, but you are adding a directive exposing a 3rd party SPF policy.
Right?

> This isn't much use.

Right.  That would solve the problem for a changed return path that is SPF
ready at the MDA but is not part of the original ISP SPF domain at the MSA.

> If I could designate an authorized submitter, then I would be in

At first thought, ideas like this is "scary" when exposing this type of
information. It might be exploitable, in this or other ways, possibly.  But
I can see where it works.

> sender policy definition would add significant strength to the Sender-ID

Yes.   If anything, if it does get adopted this way,  I can see the ISP
having no qualm about providing a WEB base form where the user can supply a
list of his non ISP domain identities. The USER may have an privacy issue
with that but atleast the ISP is making the offering :-)