-----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: Friday, July 09, 2004 9:58 PM
To: IETF-MXCOMP
Subject: Improving SUBMITTER - Persisent User Address/Account (PUA)
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: jqp(_at_)example(_dot_)com
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: private(_at_)alias(_dot_)com
S: 250 mail from ok
C: rcpt to: <hsantos(_at_)santronics(_dot_)com>
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: <private(_at_)alias(_dot_)com>,
submitter=jpq(_at_)example(_dot_)com
S: 250 mail from ok
C: rcpt to: <hsantos(_at_)santronics(_dot_)com>
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.
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:username(_at_)isp(_dot_)net 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