[Ietf-dkim] Re: DKIM with body length

savvy MBPs will already be invalidating signatures containing l=, while driving the point home for smaller providers or those who may be more of a stickler about RFCs. Cheers, Al Iverson -- Al Iverson // 312-725-0130 // Chicago http://www.spamresource.com // Deliverability http://www.aliverson.com //

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

of this from the definition of DKIM replay; it says nothing yay or nay about the potential for additional headers. And I think that's fine, as exploits evolve and it would be limiting to have done otherwise. Cheers, Al Iverson -- Al Iverson / Deliverability blogging at https

Re: [Ietf-dkim] Call for adoption

+1 on adoption of Wei's latest draft. -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ Ietf-dkim mailing

Re: [Ietf-dkim] Misuse of antiforgery protocols

d-carbon-copy. > > Blind-carbon-copy is already a sign of spam. Except when it's not, like this very mailing list. Cheers, Al Iverson -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.co

Re: [Ietf-dkim] Problem Statement

s. You're more likely a sender, not a forwarder. Cheers, Al Iverson -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time)

Re: [Ietf-dkim] Taking Responsibility

seem right to me. There'd be an awful lot of existing, current usage to unwind there to get back to your desired square one, and I'd argue that there's value and utility to lose by doing so. Cheers, Al Iverson -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekl