Re: [ietf-dkim] list expanders (was Re: chained signatures, was l= summary)
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 >> 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
Re: [ietf-dkim] list expanders (was Re: chained signatures, was l= summary)
Scott Kitterman wrote: > On Tue, 30 Jun 2009 17:01:42 -0400 hector > 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
Re: [ietf-dkim] list expanders (was Re: chained signatures, was l= summary)
On Tue, 30 Jun 2009 17:01:42 -0400 hector 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. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list expanders (was Re: chained signatures, was l= summary)
Dave CROCKER wrote: > > MH Michael Hammer (5304) wrote: > > How does a 3rd party signing a message change the intent of the author >> of a message? One might argue that breaking the original signature does that. >> My response would be to then avoid breaking the original signature. >> >> One of the arguments put forward supporting the DKIM effort was that unlike >> SPF it is not hop dependent. > > > A common source of confusion about this is the difference between an MTA > Relay > and a Mailing List Mediator. A DKIM signature always survives relaying, > whereas > SPF registration cannot any. Not so, David. To make the analogy, you need to put both under the same page, same mail transport considerations. First, you are presuming the MTA is a DKIM resigner. Like wise, SPF also has sender MTA rewriter technology and that includes a standard protocol as well - RFC 4405 (SUBMITTER SMTP Service Extension). In other words, SPF can survive a multi-hop route if each MTA supports RFC 4405. Like wise, DKIM can ONLY survive the multi-hop route if each MTA supports DKIM resigning. Both technologies require middle ware MTA support. So this old marketing benefit does not apply any more. However, with it comes to a Mailing List Server (MLS), SPF does not suffer the problems that DKIM has with a MLS. > The reality is that after receiving the message, the Mediator owns it and can > legitimately do whatever it wants. Or rather, any constraints on its actions > depend on policies and agreements that are far outside the realm of current > email protocol standards. IMO, you are minimizing long time telecommunications mail engineering considerations, reflected by US laws (and foreign laws based on the US model) that help protect user intent and expectations. Push comes to shove, the question of Mediator ownership is not as legitimate as you may think. It is only has been skewed with a renewed direction for centralization (vendor owns the resource). However, copyright ownership of author written content is still an implicit and natural legal right. Lost of mail is still a risk a responsible mail enterprise can not ignore. I believe you are advocating a dangerous precedence which will be felt when USERS are finally presented with a mixed bag of GOOD VALID VOUCHED DKIM MAIL and the many faults left open with this DKIM framework - one where the AUTHOR intent has been lost from its original basic concept. -- Hector santos http://www.santronics.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
