[ietf-dkim] off the air till after the holidays

Please don't expect to see new issues opened until after the 2nd. Happy Holidays, Eliot ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Accidental versus malicous error

> Hector, > > You know me as a logical person that can persuaded into understanding > something that I might have disagreed with in the past and we usually > think alike. In this case, I am really trying to figure out how > promotion from BAD to NONE doesn't break ALL and promotes to STRICT. > Bec

Re: [ietf-dkim] Accidental versus malicous error

> Under the default SSP policy (UNKNOWN or OPTIONAL signing), a bad > signature promotion to NONE will validate the message as it never > occurred. The same will occur when a domain has a ALL|STRICT policy but > the verifier does not support SSP. Of course, opinion may vary, to me, > I stand by t

Re: [ietf-dkim] Accidental versus malicous error

Douglas Otis wrote: Only that you want resources wasted on invalid DKIM signatures? Who said that? I would appreciate you stop making up stuff and blurting it out as if that is what I said. TPA-SSP was to permit a safe and reasonable means to "authorize" other domains. We are not talki

Re: [ietf-dkim] Accidental versus malicous error

> > A mailing-list not breaking signatures is a scary idea. This would > > open the door for all sorts of abuse. > > Yesterday, of the 32082 messages that Cisco sent through mailing lists, > 99.6% of them passed verification. Keep your grubby mitts off of the > supposedly broken signatures like RF

Re: [ietf-dkim] Accidental versus malicous error

Douglas Otis wrote: On Dec 20, 2007, at 10:44 AM, Michael Thomas wrote: That would be a bad idea. I believe they changed this in the most current version, but gnu mailman -- as an example -- was stripping out DKIM signatures thinking they were doing the originating domain a favor since they

Re: [ietf-dkim] Accidental versus malicous error

On Dec 20, 2007, at 10:44 AM, Michael Thomas wrote: That would be a bad idea. I believe they changed this in the most current version, but gnu mailman -- as an example -- was stripping out DKIM signatures thinking they were doing the originating domain a favor since they "knew" that the si

Re: [ietf-dkim] Accidental versus malicous error

On Dec 20, 2007, at 10:30 AM, Hector Santos wrote: Douglas Otis wrote: Once SMTP clients find they might be blocked for having issued too many invalid DKIM signatures, they might remove invalid DKIM signatures beforehand. Although this is in conflict with the base specification, at leas

Re: [ietf-dkim] Accidental versus malicous error (was: SSP assist DKIM)

Can someone message Doug and tell him to stop blocking Gmail *sigh*. The day Google become spammers is the day I will likely have to just power down my systems and go home. -- Forwarded message -- From: Mail Delivery Subsystem <[EMAIL PROTECTED]> Date: Dec 20, 2007 12:29 PM Subject

Re: [ietf-dkim] Accidental versus malicous error

> leave it alone. It's not hard to understand their perspective though: they > thought a broken signature would look more spammy than a missing > signature. Rinse, repeat. > > Mike > Just leave it to the developers to find a way around the problem rather than just fixing it ;-) I am sure th

Re: [ietf-dkim] draft-kucherawy-dkim-reporting-01 posted

Folks, Murray S. Kucherawy wrote: The secretariat appears to be catching up, and the DKIM reporting draft I discussed at the Vancouver WG meeting is now available for review and discussion. pdf and html versions are now at d/ -- Dave Crocker

Re: [ietf-dkim] Accidental versus malicous error

Damon wrote: I do not see this as being correct and I never agreed with it. I am going to have to do "something" whether the signature is broken or not. Just because messages have broken signatures does not mean that I am going to have to add even 1 more linux server to my farm to handle them. My

Re: [ietf-dkim] Accidental versus malicous error

Douglas Otis wrote: Once SMTP clients find they might be blocked for having issued too many invalid DKIM signatures, they might remove invalid DKIM signatures beforehand. Although this is in conflict with the base specification, at least this measure ensures SMTP clients are not associated wi

Re: [ietf-dkim] Re: Issue 1530 - replace use of term "suspicious"

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 19, 2007, at 2:16 AM, Charles Lindsey wrote: > On Wed, 19 Dec 2007 06:27:55 -, Eliot Lear <[EMAIL PROTECTED]> wrote: > >> Bingo. We are wasting time on what I think is an extraordinary >> superficial issue. Jim's original term "Suspiciou

Re: [ietf-dkim] Accidental versus malicous error (was: SSP assist DKIM)

Although an invalid signature should be considered equal to no signature (as also specified in the base specification), from the responses on this list, expect many will bet on initial statistics and get this wrong. This does not bode well, and could represent a sizeable loss of receiver resources

Re: [ietf-dkim] Re: Issue 1530 - replace use of term "suspicious"

Eliot Lear wrote: Hector, So much for getting the "easy issues" out of the way. :-) Bingo. We are wasting time on what I think is an extraordinary superficial issue. Jim's original term "Suspicious" was defined within the document, and did not in itself mean that the message was a forgery -

Re: [ietf-dkim] Accidental versus malicous error (was: SSP assist DKIM)

On Wed, 19 Dec 2007 14:55:42 -, Wietse Venema <[EMAIL PROTECTED]> wrote: Will you give "no signature" equal treatment to "bad signature", or will you give mail with bad signatures (such as a valid header that was pasted on top of a forged body) more favorable treatment? That is a matter