Re: [ietf-dkim] Inadvertent Spoof
Shit happens :) On Fri, Oct 8, 2010 at 7:20 PM, Hector Santos hsan...@isdg.net wrote: Jeff Macdonald wrote: Hence my original post with the suggested special consideration text for section 5.4 in regards to 5322.from. -- My apology to Jeff. It was not Jeff Macdonald who wrote the text above. This was not an attempt at a spoof. I somehow replied to the wrong message and my MUA (ThunderBird) somehow used the wrong From: address with the text I was writing. My Apology to Jeff. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html -- Jeff Macdonald Ayer, MA ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
John R. Levine wrote: So here's a 0th cut at a list of headers where we should recommend N+1 entries in the h= rfc 5322 From Sender Reply-To (maybe not, since often smashed by mailing lists) To Cc(not Bcc even though it's 0/1) Message-ID Subject Date rfc 4021 MIME-Version Content-Type I would focus on the main rendering items, the ones common across the mail universe of devices, gated systems, etc. From:required by 822/2822/5322 Date:required by 822/2822/5322 Subject: optional 822/2822/5322 To: required by 822, optional 2822/5322 The others are related to Network Control Lines and are generally hidden and only the ones necessary for a reply (if different than the From) may be kludged in. I know this is old school but it still applies today. Many systems do a Valid Header check in order to see if a header block needs to be generated. This is what allows a human or simple mail bot (print, fax job, etc) to enter no headers in a DATA state and still get mail through because the fields can be filled: From:--- 5321.MAIL FROM To: --- 5321.RCPT TO Date:--- Local Computer Timestamp Subject: --- left blank or filled with (NO SUBJECT) That said I don't see incentives to spoof: Message-ID MIME-Version Content-Type What are the gains? The Sender: can change too, like in a list. Not sure about CC: I guess it should be included. I think for 4871bis, we should keep it simple with focusing on the main security hole, 5322.From (and also make a statement that regarding RFC5322). -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
I don't see incentives to spoof: MIME-Version Content-Type What are the gains? This has been discussed at great length. Please consult the list archives. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
John R. Levine wrote: I don't see incentives to spoof: MIME-Version Content-Type What are the gains? This has been discussed at great length. Please consult the list archives. Thanks - you couldn't summarize or its too hard to explain? I can search, certainly not consult. But let me consult GOOGLE: MIME-Version Exploits IETF-DKIM Without going nuts looking all the results, I see whats in 4871 section 8.1.1. Addition of New MIME Parts to Multipart/* and this seems about the l= body size issue which most people already agreed is a bad idea. I don't see how the 5322.Mime-Version header can be exploited. Anyway, never mind. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
