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.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com