Re: [ietf-dkim] double header reality check

2010-10-20 Thread SM
At 17:53 19-10-10, Mark Delany wrote: In a DKIM world a list server could reasonable use DKIM to bypass this confirm sequence and make your life a bit simpler. Perhaps it relies on Authentication-Results or somesuch. In any event such a list server is actually *more* vulnerable than it is today if

Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records

2010-10-20 Thread Charles Lindsey
On Mon, 18 Oct 2010 18:06:14 +0100, Murray S. Kucherawy m...@cloudmark.com wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of John Levine Sent: Friday, October 15, 2010 7:14 PM To: ietf-dkim@mipassoc.org Cc:

Re: [ietf-dkim] double header reality check

2010-10-20 Thread Mark Delany
On Wed, Oct 20, 2010 at 01:41:03AM -0700, SM allegedly wrote: At 17:53 19-10-10, Mark Delany wrote: In a DKIM world a list server could reasonable use DKIM to bypass this confirm sequence and make your life a bit simpler. Perhaps it relies on Authentication-Results or somesuch. In any event

Re: [ietf-dkim] detecting header mutations after signing

2010-10-20 Thread Charles Lindsey
On Tue, 19 Oct 2010 16:23:39 +0100, John R. Levine jo...@iecc.com wrote: good signature - good message. Don't you mean Good signature - authenticated message (that is, someone accepts responsibility) I think it needs to mean Good signature - authenticated message (that is, someone

Re: [ietf-dkim] detecting header mutations after signing

2010-10-20 Thread Charles Lindsey
On Tue, 19 Oct 2010 14:18:45 +0100, Wietse Venema wie...@porcupine.org wrote: My preference would be to enforce this within the existing protocol (that is: send h=from:from:subject:subject...), But that only copes with some of the scams that are possible; for full protection you need ...

Re: [ietf-dkim] Data integrity claims

2010-10-20 Thread Charles Lindsey
On Mon, 18 Oct 2010 20:18:16 +0100, Murray S. Kucherawy m...@cloudmark.com wrote: This is no more presumptuous than expecting that MUAs will adapt to consume the output of DKIM as it stands now. In another message I indicated that I don't presume either, but assert that there's no middle

Re: [ietf-dkim] detecting header mutations after signing

2010-10-20 Thread Ian Eiloart
--On 20 October 2010 15:12:47 +0100 Charles Lindsey c...@clerew.man.ac.uk wrote: When I said good, I meant credible, not just one that mechanically validates. I hope that we all agree that a signature from a domain about which one knows nothing is not usefully different from no signature

Re: [ietf-dkim] detecting header mutations after signing

2010-10-20 Thread Ian Eiloart
--On 19 October 2010 07:31:58 -0700 Michael Thomas m...@mtcc.com wrote: On 10/19/2010 06:18 AM, Wietse Venema wrote: valid signature + good signer + no suspicious unsigned content - good message Has nobody learned that good signers from good authors can still be evil? I mean come

Re: [ietf-dkim] detecting header mutations after signing

2010-10-20 Thread Ian Eiloart
--On 19 October 2010 11:35:53 -0400 John R. Levine jo...@iecc.com wrote: True, but there already are UI designs that indicate when a From header is DKIM verified. So you're saying that all a spammer has to do is to put on a throwaway domain's signature, and the MUA will highlight at least

Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records

2010-10-20 Thread Murray S. Kucherawy
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Wednesday, October 20, 2010 3:52 AM To: DKIM Subject: Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records By the way, has everyone

Re: [ietf-dkim] detecting header mutations after signing

2010-10-20 Thread John R. Levine
A reputation service can only say that a domain is BAD GOOD or NO EVIDENCE AVAILABLE EITHER WAY. I think the last case has to be treated pretty much like GOOD, otherwise newcomers to the internet will never even get their messages accepted. Heck, no. Treat it like there's no

Re: [ietf-dkim] double header reality check

2010-10-20 Thread Murray S. Kucherawy
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Mark Delany Sent: Tuesday, October 19, 2010 5:53 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] double header reality check Any filter or agent that makes any

Re: [ietf-dkim] double header reality check

2010-10-20 Thread MH Michael Hammer (5304)
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy Sent: Wednesday, October 20, 2010 1:55 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] double header reality check SNIP There has been

Re: [ietf-dkim] double header reality check

2010-10-20 Thread Hector Santos
MH Michael Hammer (5304) wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy Sent: Wednesday, October 20, 2010 1:55 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] double header reality

Re: [ietf-dkim] What shows up with duplicated headers?

2010-10-20 Thread John R. Levine
Here's another batch of spam with extra From or Subject lines. I see the same thing as last time, the extra subjects are all the same, and the extra From lines look like bugs, not attempts to evade filters. The spam with 6,981 From lines is impressive in a wacky way. R's, John

Re: [ietf-dkim] double header reality check

2010-10-20 Thread Rolf E. Sonneveld
On 10/20/10 9:30 PM, MH Michael Hammer (5304) wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy Sent: Wednesday, October 20, 2010 1:55 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim]

Re: [ietf-dkim] What shows up with duplicated headers?

2010-10-20 Thread Hector Santos
John R. Levine wrote: Here's another batch of spam with extra From or Subject lines. I see the same thing as last time, the extra subjects are all the same, and the extra From lines look like bugs, not attempts to evade filters. The spam with 6,981 From lines is impressive in a wacky way.

Re: [ietf-dkim] double header reality check

2010-10-20 Thread Michael Thomas
On 10/20/2010 01:31 PM, Rolf E. Sonneveld wrote: On 10/20/10 9:30 PM, MH Michael Hammer (5304) wrote: Seeing as the M in DKIM stands for Mail, we don't have to put a but only when used in the email context clause. If a DKIM like approach is used for other protocols then we might reasonably

Re: [ietf-dkim] double header reality check

2010-10-20 Thread Douglas Otis
On 10/20/10 10:55 AM, Murray S. Kucherawy wrote: I think a lot of this discussion conflates protocol specification with implementation. I'm focused on the former. I maintain that including wording intimating that a DKIM implementation is non-compliant if it fails to do mail format

Re: [ietf-dkim] detecting header mutations after signing

2010-10-20 Thread Douglas Otis
On 10/20/10 8:10 AM, Ian Eiloart wrote: --On 19 October 2010 11:35:53 -0400 John R. Levine jo...@iecc.com wrote: True, but there already are UI designs that indicate when a From header is DKIM verified. So you're saying that all a spammer has to do is to put on a throwaway domain's

Re: [ietf-dkim] double header reality check

2010-10-20 Thread Douglas Otis
On 10/20/10 3:19 PM, Murray S. Kucherawy wrote: [] I totally agree that that's an important distinction to make, document, highlight and shout from the rooftops. But... Does it *have* to use RFC2119 normative language? Here's maybe a better way to frame the question: Should we empower

Re: [ietf-dkim] double header reality check

2010-10-20 Thread Steve Atkins
On Oct 20, 2010, at 3:19 PM, Murray S. Kucherawy wrote: Validating mail syntax belongs in the specification for the mail components and DKIM work belongs in the DKIM components. That's why, layer violation or no, I think it's important to distinguish between format errors that are likely

Re: [ietf-dkim] double header reality check

2010-10-20 Thread John R. Levine
Here's maybe a better way to frame the question: Should we empower ourselves to label a DKIM implementation that doesn't do format enforcement as (a) non-compliant, or (b) low-security/low-quality? The latter. Hey, we agree. I think I always said SHOULD rather than MUST. The DKIM spec is

Re: [ietf-dkim] double header reality check

2010-10-20 Thread Michael Thomas
On 10/20/2010 04:36 PM, Steve Atkins wrote: On Oct 20, 2010, at 3:19 PM, Murray S. Kucherawy wrote: Validating mail syntax belongs in the specification for the mail components and DKIM work belongs in the DKIM components. That's why, layer violation or no, I think it's important to

Re: [ietf-dkim] double header reality check

2010-10-20 Thread Scott Kitterman
Michael Thomas m...@mtcc.com wrote: On 10/20/2010 04:36 PM, Steve Atkins wrote: On Oct 20, 2010, at 3:19 PM, Murray S. Kucherawy wrote: Validating mail syntax belongs in the specification for the mail components and DKIM work belongs in the DKIM components. That's why, layer violation or

Re: [ietf-dkim] double header reality check

2010-10-20 Thread Steve Atkins
On Oct 20, 2010, at 6:08 PM, Scott Kitterman wrote: Michael Thomas m...@mtcc.com wrote: On 10/20/2010 04:36 PM, Steve Atkins wrote: On Oct 20, 2010, at 3:19 PM, Murray S. Kucherawy wrote: Validating mail syntax belongs in the specification for the mail components and DKIM work

Re: [ietf-dkim] double header reality check

2010-10-20 Thread Murray S. Kucherawy
-Original Message- From: John R. Levine [mailto:jo...@iecc.com] Sent: Wednesday, October 20, 2010 5:08 PM To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] double header reality check Here's maybe a better way to frame the question: Should we empower