Scott Kitterman wrote:
On Tue, 30 Jun 2009 17:01:42 -0400 hector
<gmail(_dot_)sant9442(_at_)winserver(_dot_)com>
wrote:
Like wise, SPF
also has sender MTA rewriter technology and that includes a standard
protocol as well - RFC 4405 (SUBMITTER SMTP Service Extension).
I know it's OT, but in the interests of correctness, RFC 4405 is tied to
Microsoft's Sender ID and not at all related to SPF. Sender Rewriting
Service/System (SRS) is, I'm pretty sure, what Hector was thinking of. It
has never been standardized.
Its odd you say this. But lets not mix semantics here and create the
erroneous idea that SUBMITTER is not related to SPF.
First, RFC4405 is related SPF because SENDERID is the 2822 version of SPF.
The whole purpose of SUBMITTER, which I suggested, promoted and
instigated during MARID was my repeated concern over and over again in
the forum and in private emails with MS to address the payload
overhead associated the 2822 version of SPF - Microsoft SPF version
called SenderID. That was my #1 complaint about SenderID and I
submitted these concerns to the FTC request for comments.
In short, SUBMITTER allows SENDERID to work as a SPF protocol at the
SMTP LEVEL. It is considered an optimization (the 2822 PAYLOAD is not
required) as cleared stated is MS marketing and the specification
security section:
6. Security Considerations
This extension provides an optimization to allow an SMTP client
to identify the responsible submitter of an e-mail message in
the SMTP protocol, and to enable SMTP servers to perform
efficient validation of that identity before the message
contents are transmitted.
The overall problem with SENDERID was its dependency on the payload.
SUBMITTER helps resolves this problem by keeping the processing at the
2821 level, in addition, it also helps keep the persistent nature of
the 2821 return path which was a concern with suggested ideas like SRS.
As stated in 4.2:
4.2. Processing the SUBMITTER Parameter
Receivers of e-mail messages sent with the SUBMITTER parameter
SHOULD select the domain part of the SUBMITTER address value as
the purported responsible domain of the message, and SHOULD
perform such tests, including those defined in [SENDER-ID], as
are deemed necessary to determine whether the connecting SMTP
client is authorized to transmit e-mail messages on behalf of
that domain.
If these tests indicate that the connecting SMTP client is not
authorized to transmit e-mail messages on behalf of the
SUBMITTER domain, the receiving SMTP server SHOULD reject
the message and when rejecting MUST use "550 5.7.1 Submitter
not allowed."
The operative term here is "connecting SMTP client" and logic to
reject at the 2821 level. For the transition to work, the submitter
domain MUST match that of the client IP.
This is best shown in the examples, in particular
5.4. Guest E-Mail Service
where clearly the SUBMITTER is not the Author or PRA but rather the
Hotel Service, the Responsible Submitter of the email which MUST match
the connecting IP address according the email.hotel.com SPF record.
--
Hector Santos
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html