Re: [spf-discuss] SPF, DKIM, and NIH

Stuart D. Gathman wrote:
> On Tue, 6 Oct 2009, Michael Deutschmann wrote:
> > If I understand DKIM correctly, DKIM validators are to ignore DKIM 
> > signatures that sign what, to them, is the "wrong" identity.  So, there 
> > should be no obstacle to mailservers double-signing a message when the 
> > envelope MAIL FROM: and the header From: are not the same.
> > Since only a simple flag is needed, it would make sense to piggyback 
> > this on SPF records with a special modifier.  (Such as the "fm=dkim" 
> > from my original senderside forwarder mitigation proposal...)
> This can't be verified until the entire message is received.  While 
> using DKIM to validate Return-Path is a good idea, it is not SPF, 
> and is not an SMTP envelope time protocol.  You should take it up 
> with the DKIM folks.  It should be just a matter of adding a new 
> signed identity to the DKIM header.
I don't think it would be a good idea. To allow forwarding is the 
point of DKIM. Signing the Return-Path, then would only allow that 
"traditional" forwarding mentioned below.
As Scott says, the problem is that most mailing lists modify the 
message in ways that break the signature. The solution to this is to 
fix the implementation of the existing protocol and related stuff.
> As to "NIH", it is not so much that as hoping "traditional" forwarding will 
> become inconvenient enough to die away like open relays.  It took a long 
> time for legit admins to realize that open relays had been rendered useless by 
> the abuse of spammers.  The same thing has happened to 
> traditional forwarding, but not everyone has realized it yet.
Much agreed! In addition, traditional forwarding breaks the spirit 
--if not the letter-- of privacy regulations. That's not for being 
deferentially law-abiding, but to recognize the principle, established 
long after SMTP, that an email address is the property of its owner, 
who shall be in full control of it: including the ability to remove it 
from .forward files straightly. I've analyzed that requirement to some 
extent in http://fixforwarding.org/ and I've been surprised to learn 
that implementing that principle would provide means for "fixing" 
newsletters and backup MXes as well.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com