ietf-mxcomp
[Top] [All Lists]

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

2004-07-13 17:31:56

-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Hector 
Santos
Sent: Monday, July 12, 2004 11:49 PM
To: Scott Kitterman; ietf-mxcomp(_at_)imc(_dot_)org
Subject: Re: Improving SUBMITTER - Persisent User Address/Account (PUA)
----- Original Message -----
From: "Scott Kitterman"
To: <ietf-mxcomp(_at_)imc(_dot_)org>
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:username(_at_)isp(_dot_)net 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