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

From: "Scott Kitterman" <[email-masked]>
Date: Tue, 13 Jul 2004 20:31:32 -0400

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Hector Santos
> Sent: Monday, July 12, 2004 11:49 PM
> To: Scott Kitterman; [email-masked]
> Subject: Re: Improving SUBMITTER - Persisent User Address/Account (PUA)
> ----- Original Message -----
> From: "Scott Kitterman"
> To: <[email-masked]>
> Sent: Saturday, July 10, 2004 3:54 PM
>
> > > o Suggestion to improve SUBMITTER proposal:
> > >    Persistent User 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.
>
> 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?
>
Right.  The domain is hosted at, nominally, host.net.  The MX is
servername.host.net.  What I want to include is the DSL provider (that I
described as isp.net).  So currently I put the ? in front of the
include:isp.net because there is no way to tell if an e-mail from the
isp.net smtp server was actually sent by my account or someone else's.  Your
suggestion allows a resolution to that problem.

> > 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
> > a position to make a stronger statement about the message being
> authorized.
> > If I could, instead, have +submitter:[email-masked] in my record it
> would
> > say something positive.
>
> 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.

Yes, I expose to the spammers the name of a valid e-mail address, but other
than getting more spam, I don't think there's a major risk here.  If they
can break SMTP Auth, we have bigger problems than this.
>
> > I believe that your proposal in combination with supporting changes in
> > sender policy definition would add significant strength to the Sender-ID
> > proposal.
>
> 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 :-)
>
Actually I was hoping to avoid the sign up part.  The ISP really has no good
way to validate who is authorized to send for what external domain.  By
adding an authorized submitter to the SPF (or whatever) record, then the
domain owner can make a positive statement about who is authorized to submit
for the domain.  No added work for the isp, other that adding SUBMITTER into
their SMTP setup.

Could do it your way too, but that would put more of a burden on the ISP's.
I don't know that they'd sign up for all the validation effort that would be
required.

I think this is a critical change for small domain owners that outsource
their MTA services (vanity domains).  As it stands now, almost all valid
e-mail from my domain will come back neutral because of the exact problem
your suggestion can solve.

Scott Kitterman

---

From: "Harry Katz" <[email-masked]>
Date: Thu, 15 Jul 2004 14:56:24 -0700

On Friday, July 09, 2004 6: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)
> 
[snip]
> 
> 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.
> 

In principal, I think this is a good idea, and in fact the spec already
provides an example (5.3 - Mobile User) which illustrates how this could
be done.  I will add some wording to this example to the effect that
ISPs may want to do this generally whenever the MAIL FROM is not an
account on their network.

The -02 revision actually makes SUBMITTER mandatory whenever the PRA
differs from MAIL FROM (in -01, it's a SHOULD).  I think that covers
part of the requirement you've stated above.  Beyond that, I do not want
to prescribe _which_ account the ISP should use in SUBMITTER.  That's a
matter for ISP policy.   

Thanks