Re: [ietf-dkim] list expanders (was Re: chained signatures, was l= summa

One other point Scott, to keep this "On Topic",

Where RFC 4405 described the Responsible Submitter concept, Dave's 
DKIM errata is basically about focusing and describing a
"Responsible Submitter Signer" concept.

In the case of SPF, it is about a broken transition (hop to hop) 
DOMAIN::IP association mismatch and the restoration with SUBMITTER.

In the case of DKIM, it about the possible hop to hop broken mail 
signature integrity and the restoration with DKIM resigning.

So from technical point of view, the same hop to hop protocol support 
requirement is the same. Neither can survive if their basic protected 
information is broken and not restored by compliant MTAs.

-- 
Hector Santos
http://www.santronics.com

hector wrote:

> 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