Re: [ietf-dkim] DKIM and EAI

On Fri, Feb 9, 2018 at 3:22 PM, John Levine wrote: > In article <1707398.kN3rUcK64s@kitterma-e6430> you write: > >Does this need to update RFC 7208 since there are SPF related MUST > >requirements? > > I would think so, also 6376, 7489, 7601 since it updates DKIM, DMARC, and >

Re: [ietf-dkim] Where is the formal definition of DKIM-Signature?

On Thu, Feb 8, 2018 at 5:22 AM, John R. Levine wrote: > someone asked me about case sensitiveness of the header field name. I >> looked >> for an ABNF in RFC6376, but only found examples and informative notes. >> > > I was going to say that can't possibly be true, but it's true,

Re: [ietf-dkim] Mailsploit

On Tue, Dec 5, 2017 at 2:52 PM, Pawel Lesnikowski wrote: > > DKIM works as expected, but as you said it may re-enforce an incorrect > assumption that email is from respected source. > > Only if it's abused by saying "DKIM signature verified, it's safe!" rather than "

Re: [ietf-dkim] Mailsploit

I disagree that it's specifically a DMARC issue, because from that I infer that you think DMARC is at fault here, i.e., that you expected it to deal with this. On Tue, Dec 5, 2017 at 1:44 PM, Steve Atkins wrote: > That's DMARC working exactly as designed but not as

Re: [ietf-dkim] [Technical Errata Reported] RFC6376 (4926)

On Tue, Feb 7, 2017 at 10:25 AM, Barry Leiba wrote: > >>Murray, Tony, or someone else: Can you independently check that these > >>examples need the extra space in order to be verified correctly? > > > > Murray did that for us a decade ago -- it's one of the test cases

Re: [ietf-dkim] draft-kucherawy-dmarc-rcpts

: > > On 11/13/2016 09:38 PM, Murray S. Kucherawy wrote: > > On Sun, Nov 13, 2016 at 9:39 PM, Mark Delany <sx6un-fc...@qmda.emu.st> > wrote: > > Hi Murray. > > > Mark! > > > RFC6376 and even RFC4871, but now it's apparently happening > > I'd be intere

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

On Tue, Nov 22, 2016 at 7:45 AM, Michael Storz wrote: > >> The negative side of the proposal is the requirement to split all >>> multi-recipient-emails to single-recipient-emails, which is a show >>> stopper for me. >>> >> >> That's curious; why? >> > > Because SMTP is

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

On Fri, Nov 18, 2016 at 3:47 AM, Michael Storz wrote: > Normal DKIM-Signatures give us a way to check if the body and/or header of > an email has been changed on the way from the signer to the verifier. The > new extension extends this to the recipients of the email. A

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

On Thu, Nov 17, 2016 at 9:51 PM, Michael Storz wrote: > > Thanks, I see. That means the recipient is bound to the message and an > attacker cannot delete or change the new tags. Great solution, I like it, > though I do not like the consequences when this extension will go

Re: [ietf-dkim] Intended status (was: Re: [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts)

On Fri, Nov 18, 2016 at 1:11 AM, Rolf E. Sonneveld < r.e.sonnev...@sonnection.nl> wrote: > Hi, Murray, > > On 16-11-16 02:45, Murray S. Kucherawy wrote: > >> There's been a lot of great feedback here. I just cranked out an update >> based on the discussion so f

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

On Thu, Nov 17, 2016 at 7:28 PM, Alessandro Vesely wrote: > > Yes. >> > > Well, if its title were *Incompatibility with Current Infrastructure*, I > would agree there is a statement on the risk of disrupting how DKIM works. > That section talks about some things that are

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

On Thu, Nov 17, 2016 at 3:09 AM, Terry Zink wrote: > > This means ARC will be needed not only for mailing lists which modify > the header or > > body of an email, but for EVERY mailing list and EVERY forwarded email > or EVERYTIME > > the recipient has been modified

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

On Thu, Nov 17, 2016 at 3:47 AM, Alessandro Vesely wrote: > > That way it will stay dormant until someone gets hurt and has to activate >>> it, at which time it may cause more damage than improvement. A loose >>> cannon. >>> >> >> The document makes that risk clear, or so I

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

On Wed, Nov 16, 2016 at 11:50 PM, Michael Storz wrote: > > Ok, I see you have removed the hashing of the recipient together with the > email itself. But how do you prevent a replay attack, if the new tag is not > bound to the email and signed with the DKIM-key (that's how I

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

(dropping DMARC again) On Wed, Nov 16, 2016 at 9:51 PM, Michael Storz wrote: > Version 01 is purely incremental, meaning you can just ignore the new >> tags if you're more worried about breakage of forwarding than the >> attack it's trying to address. >> > > Optional for

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

On Wed, Nov 16, 2016 at 7:57 PM, Alessandro Vesely wrote: > That way it will stay dormant until someone gets hurt and has to activate > it, at which time it may cause more damage than improvement. A loose > cannon. I'd keep it in its own header field [Ned's (1)(a)], so as to

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

On Wed, Nov 16, 2016 at 1:05 PM, John R Levine wrote: > > So far this exercise has mostly served to persuade me that putting > envelope info in the DKIM signature is a bad idea, and our advice to people > who have problems with recipients remailing spam they've signed remains >

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

On Wed, Nov 16, 2016 at 10:59 AM, Terry Zink wrote: > Large email receivers forward tons of email. This proposal causes email > from DMARC-passing messages to be incapable of forwarding. As a large email > receiver who gets tons of complaints about breakage of DKIM

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

On Wed, Nov 16, 2016 at 10:56 AM, John R Levine wrote: > https://www.ietf.org/rfcdiff?url2=draft-kucherawy-dkim-rcpts-01 >> >> I forgot to update the title of Section 3, but other than that I think I >> captured what's been discussed. Please let me know what I've missed. >> > >

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

On Wed, Nov 16, 2016 at 5:11 AM, Michael Thomas wrote: > So, when the filters catch up, it will then mark it as spam again > regardless of the DKIM signature. > > So what exactly is the problem here? > I suppose when the filters catch up, the spammer can no longer get

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

On Wed, Nov 16, 2016 at 4:17 AM, Martijn Grooten wrote: > My understanding is an attack where the email is sent to an outside > address owned by the sender, who then gets a copy of the email, signed > by the provider who didn't think the email was bad. > > Signing an

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

On Tue, Nov 15, 2016 at 6:01 PM, Vladimir Dubrovin <dubro...@corp.mail.ru> wrote: > 15.11.2016 2:07, Murray S. Kucherawy пишет: > > On Mon, Nov 14, 2016 at 10:36 PM, <ned+dm...@mrochek.com> wrote: > >> Let's break this down. If we're going to include recipients in t

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

On Mon, Nov 14, 2016 at 10:36 PM, wrote: > Let's break this down. If we're going to include recipients in the DKIM > signature, it seems we have at least three key design decisions to make: > [...] > That's a pretty excellent summary. A couple of points: I think you

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

Hi Rolf, On Tue, Nov 15, 2016 at 7:41 AM, Rolf E. Sonneveld < r.e.sonnev...@sonnection.nl> wrote: > At the time SenderID was proposed, back in 2004 or something, the act of > propagating header information into the transport stream was seen by many > as a layering violation. The proposal of

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

On Mon, Nov 14, 2016 at 8:40 AM, Ned Freed wrote: > > Actually same message to same destination may be > > sent to different MTAs (e.g. different MXs with same weight). > > 2.3 Canonization must be better defined. It's usual for MTA to e.g. > > lowercase the domain of

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

On Mon, Nov 14, 2016 at 6:01 AM, Vladimir Dubrovin wrote: > 1. This standard is not backward compatible with existing DKIM > implementations. It makes it useless. In addition, in it's current form it > can not be implemented in most MTAs (see below) > 2. This standard

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

On Mon, Nov 14, 2016 at 5:41 AM, Scott Kitterman wrote: > Wouldn't a DMARC option to allow senders to specify only messages that > pass verification and alignment for BOTH SPF and DMARC accomplish the same > result with less complexity and without the layering violation

Re: [ietf-dkim] draft-kucherawy-dmarc-rcpts

On Sun, Nov 13, 2016 at 9:39 PM, Mark Delany wrote: > Hi Murray. > Mark! > RFC6376 and even RFC4871, but now it's apparently happening > > I'd be interested to hear about the actual scenarios. Are the targeted > users somehow given an indication that the email verifies

[ietf-dkim] draft-kucherawy-dmarc-rcpts

I've posted a draft that attempts to address an attack that's begun to appear with DKIM. Interestingly, we called it out as a possible attack in RFC6376 and even RFC4871, but now it's apparently happening and being annoying enough that people (I believe from the MAAWG community) are asking if

Re: [ietf-dkim] DKIM and EAI

On Tue, Sep 27, 2016 at 8:15 PM, Jiankang Yao wrote: > Since EAI deployment is on the way, gmail, outlok2016, postfix, yandex, > xgenplus and many more have adopted EAI. > In order to make EAI environment more friendly, I suggest that this WG > considers to move this

Re: [ietf-dkim] [Technical Errata Reported] RFC6376 (4810)

That looks correct to me. Barry or Dave? On Mon, Sep 26, 2016 at 2:55 PM, Stephen Farrell wrote: > > If someone familiar with the dkim abnf could comment I'd be > happy to approve/reject this as appropriate. > > S > > On 26/09/16 20:15, RFC Errata System wrote: > >

Re: [ietf-dkim] DKIM Key Size Constraints

On Tue, May 12, 2015 at 8:31 AM, Martijn Grooten martijn.groo...@virusbtn.com wrote: Why remove 512 support from the verification side? Does this mean the verifier will take valid 512 signature and make it invalid, no signature message? Is there a correlation out there that 512 bits

Re: [ietf-dkim] DKIM Key Size Constraints

On Tue, May 12, 2015 at 8:28 PM, Scott Kitterman ietf-d...@kitterman.com wrote: Is it appropriate to change the protocol document for this? Isn't it really more of a BCP? I think when key size got put in the protocol, then it's a protocol update to change it. Is it part of the

Re: [ietf-dkim] [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic

On Thu, Sep 12, 2013 at 7:57 AM, Michael Thomas m...@mtcc.com wrote: The list of things DMARC does that ADSP doesn't in its appendix, is a trip down memory lane of constraints that were placed on it by the against-it-before-they-were-for it set. True SPF wasn't ever on its radar -- SPF has

Re: [ietf-dkim] [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic

I also agree with this proposal. I don't have much to add over the text in the formal request; it lays out the case based on my experience implementing DKIM and ADSP in open source. I can also say that I have never encountered an operation that actively uses it, including current and previous

Re: [ietf-dkim] IPR Disclosure: ENTERKHAN CO., LTD's Statement about IPR related to RFC 6376, draft-allman-dkim-base-01, and Creative Commons

On Thu, Aug 15, 2013 at 8:46 AM, Stephen Farrell stephen.farr...@cs.tcd.iewrote: That looks weird. Do we know its not spam? S First I've heard of it. -MSK ___ NOTE WELL: This list operates according to

Re: [ietf-dkim] Seeking Clarification of the l= Tag

On Sun, Aug 4, 2013 at 1:35 PM, Pawel Lesnikowski lesnikow...@limilabs.comwrote: There are few details I'd like to clarify. Body hash for this message is correctly computed by the sender. Entire signature of this message in fact valid - this is why Port25, Gmail, and Mail.dll validate DKIM

Re: [ietf-dkim] Seeking Clarification of the l= Tag

If the message is totally empty or consists only of CRLF sequences, or not even that, then the l= value should be zero since they would all be ignored and not fed to the hash; the total number of bytes fed to the hash would be zero. I suggest reaching out to Gmail to find out what's going on.

Re: [ietf-dkim] That weird i= is most probably EDSP

On Sat, Aug 3, 2013 at 2:09 AM, Michael Deutschmann mich...@talamasca.ocis.net wrote: Your question about drafts has two possible implications. The first is I'm not going to pay any attention to Michael until he takes up RFC lawyering. In which case I can't help you. My problem is that

Re: [ietf-dkim] The problem with the DKIM design community

On Sun, Jun 30, 2013 at 9:21 AM, John R. Levine jo...@iecc.com wrote: What I'm asking for is nothing like SES. I want the signature to be based on the envelope MAIL FROM:, but it is still the body that gets signed. No VERPing is called for. ... Where can we read the draft? +1. I pledge

Re: [ietf-dkim] The problem with the DKIM design community

On Mon, Jul 1, 2013 at 12:24 PM, Michael Deutschmann mich...@talamasca.ocis.net wrote: On Mon, 1 Jul 2013, Alessandro Vesely wrote: Well, not really. MAIL FROM: is only visible after delivery, so to avoid dangling signatures one should store its value in some other header field or... in

Re: [ietf-dkim] The problem with the DKIM design community

On Sat, Jun 22, 2013 at 9:49 PM, Michael Deutschmann mich...@talamasca.ocis.net wrote: (I have deployed DKIM alone senderside, but that's just to keep in practice in case someone invents an accessory protocol that's actually sane. Allowing me to declare that all mail bearing my RFC821 MAIL

Re: [ietf-dkim] value-added DKIM-ish enhancements )was - Re: Weird i= in client mail)

On Tue, Jun 18, 2013 at 7:59 AM, Dave Crocker dcroc...@bbiw.net wrote: On 6/18/2013 7:18 AM, Tony Hansen wrote: I always thought it would be a nice follow-on to DKIM to provide a way for a site to specify how that site was using i=; that is, to provide some clarity and comprehension for

[ietf-dkim] DMARC working group charter proposal

At the IETF meeting in Atlanta, Tim Draegen presented a proposal for DMARC, which is an email authentication and reporting layer atop SPF and DKIM. The externally-developed proposal is now in widespread deployment by a number of large-scale providers. The group that developed it is seeking to

[ietf-dkim] Authentication-Results

Colleagues, (with apologies for the cross-posting if you get more than one copy of this) As you may have seen already, I'm working on a revision to RFC5451. A Proposed Standard bis effort always benefits from describing extant implementations. I know about the ones I've written, and about some

Re: [ietf-dkim] The good ol' t= tag in key records

On Wed, Jul 25, 2012 at 10:42 PM, Roland Turner roland.tur...@trustsphere.com wrote: This appears to be the inverse of the use case that was originally put forward (we're concerned that we're signing rubbish, please disregard signatures made with this selector); the very case that you're

Re: [ietf-dkim] The good ol' t= tag in key records

On Mon, Jul 23, 2012 at 6:26 AM, Richard Dawe rich.d...@messagesystems.comwrote: Do you think that DMARC provides a better way of testing your DKIM signatures than DKIM's t=y? E.g.: p=none DMARC policy. I don't understand what you're after here. How would a mail receiver apply p=none as

Re: [ietf-dkim] The good ol' t= tag in key records

On Mon, Jul 23, 2012 at 6:42 AM, Michael Thomas m...@mtcc.com wrote: There seems like there are many things wrong with this sort of helpfulness. If a given selector is dodgy, the reputation system should figure that out for itself. Believing even a vaguely positive-assertion from the source

Re: [ietf-dkim] The good ol' t= tag in key records

On Mon, Jul 23, 2012 at 6:13 AM, Barry Leiba barryle...@computer.orgwrote: Should't have been signed by us clearly can't mean that someone stole the private key or otherwise hacked things, so you're saying, Our processes might not be set up right, and we might be signing crap sent by bad

Re: [ietf-dkim] The good ol' t= tag in key records

On Mon, Jul 23, 2012 at 7:28 AM, Dave Crocker d...@dcrocker.net wrote: Here are two small tweaks that might correct things: y This domain is testing DKIM. Verifiers MUST NOT treat messages from Signers in testing mode differently from unsigned email. This covers

[ietf-dkim] The good ol' t= tag in key records

And you thought this list was dead. I was asked to consult recently on some DKIM questions raised by a customer of a former employer. The questions involved the meaning of t= in DKIM keys and the text in RFC6376. The focus of this tag has always been, to the best of my recollection, the notion

Re: [ietf-dkim] Is TLS-OBC for SMTP (in theory) a good alternative to SPF?

On Tue, Jun 19, 2012 at 5:49 AM, Chris Lamont Mankowski makerofthing...@gmail.com wrote: I realize my last message talked about TLS-OBC for SMTP but didn't preface it with any information on how I see how it can replace, or compliment SPF in a given situation. First, does anyone know of a

[ietf-dkim] FW: RFC 6541 on DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures

FYI -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of rfc-edi...@rfc-editor.org Sent: Wednesday, February 29, 2012 10:59 AM To: ietf-annou...@ietf.org; rfc-d...@rfc-editor.org Cc: rfc-edi...@rfc-editor.org Subject: RFC 6541 on

[ietf-dkim] FW: [marf] Last Call: draft-ietf-marf-dkim-reporting-11.txt (Extensions to DKIM for Failure Reporting) to Proposed Standard

FYI, in case anyone wants to comment. -Original Message- From: marf-boun...@ietf.org [mailto:marf-boun...@ietf.org] On Behalf Of The IESG Sent: Wednesday, February 29, 2012 6:58 AM To: IETF-Announce Cc: m...@ietf.org Subject: [marf] Last Call: draft-ietf-marf-dkim-reporting-11.txt

[ietf-dkim] FW: Document Action: 'DKIM Authorized Third-Party Signers' to Experimental RFC (draft-kucherawy-dkim-atps-16.txt)

Hi all, This got approved by the IESG. Note that it is slightly different than the last time it was discussed here, courtesy of some suggested changes during IESG evaluation. OpenDKIM has already implemented the revised version and is thus available for interop testing if anyone wants to try

Re: [ietf-dkim] Final update to 4871bis for working group review

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Monday, July 11, 2011 3:52 AM To: DKIM Subject: Re: [ietf-dkim] Final update to 4871bis for working group review Agents that evaluate or apply DKIM

Re: [ietf-dkim] Doublefrom language should be in ADSP, not core

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Michael Deutschmann Sent: Sunday, July 10, 2011 12:53 AM To: DKIM List Subject: Re: [ietf-dkim] Doublefrom language should be in ADSP, not core The attack only matters if

Re: [ietf-dkim] Doublefrom language should be in ADSP, not core

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Sunday, July 10, 2011 6:46 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Doublefrom language should be in ADSP, not core I think we should

Re: [ietf-dkim] Final update to 4871bis for working group review

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Sunday, July 10, 2011 6:00 AM To: DKIM Cc: Pete Resnick Subject: Re: [ietf-dkim] Final update to 4871bis for working group review Implementors of

Re: [ietf-dkim] Final update to 4871bis for working group review

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy Sent: Sunday, July 10, 2011 8:39 PM To: Charles Lindsey; DKIM Cc: Pete Resnick Subject: Re: [ietf-dkim] Final update to 4871bis for working group review

Re: [ietf-dkim] Final update to 4871bis for working group review

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Friday, July 08, 2011 3:59 AM To: DKIM Subject: Re: [ietf-dkim] Final update to 4871bis for working group review My favourite counterexample, which

Re: [ietf-dkim] Final update to 4871bis for working group review

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Friday, July 08, 2011 3:52 AM To: DKIM Subject: Re: [ietf-dkim] Final update to 4871bis for working group review 1. The fact that DKIM choose headers

Re: [ietf-dkim] Final update to 4871bis for working group review

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Thursday, July 07, 2011 3:09 AM To: DKIM Subject: Re: [ietf-dkim] Final update to 4871bis for working group review The signer most certainly CAN

Re: [ietf-dkim] Final update to 4871bis for working group review

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Alessandro Vesely Sent: Thursday, July 07, 2011 4:56 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Final update to 4871bis for working group review I'd s/to be

Re: [ietf-dkim] Final update to 4871bis for working group review

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Thursday, July 07, 2011 6:32 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Final update to 4871bis for working group review I'm working with

Re: [ietf-dkim] Final update to 4871bis for working group review

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Thursday, July 07, 2011 9:44 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Final update to 4871bis for working group review I agree it's not

Re: [ietf-dkim] Final update to 4871bis for working group review

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Thursday, July 07, 2011 12:31 PM To: DKIM Subject: Re: [ietf-dkim] Final update to 4871bis for working group review I think Murray is wrong. There is

Re: [ietf-dkim] Final update to 4871bis for working group review

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Douglas Otis Sent: Thursday, July 07, 2011 6:47 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Final update to 4871bis for working group review Unfortunately, the

Re: [ietf-dkim] Final update to 4871bis for working group review

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Barry Leiba Sent: Wednesday, July 06, 2011 9:32 AM To: Charles Lindsey Cc: DKIM Subject: Re: [ietf-dkim] Final update to 4871bis for working group review As Pete has

Re: [ietf-dkim] Final update to 4871bis for working group review

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Barry Leiba Sent: Saturday, July 02, 2011 8:27 PM To: DKIM Mailing List Subject: [ietf-dkim] Final update to 4871bis for working group review We have a week. Murray will

Re: [ietf-dkim] Pete's review of 4871bis

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Thursday, June 30, 2011 7:05 AM To: DKIM Subject: Re: [ietf-dkim] Pete's review of 4871bis The problem is that an apparently valid signature (albeit

Re: [ietf-dkim] Pete's review of 4871bis

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Wednesday, June 29, 2011 9:20 AM To: DKIM Subject: Re: [ietf-dkim] Pete's review of 4871bis I agree that 8.14 is poorly written (and it was even

Re: [ietf-dkim] Pete's review of 4871bis

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Dave CROCKER Sent: Wednesday, June 29, 2011 11:56 AM To: Pete Resnick Cc: DKIM Subject: Re: [ietf-dkim] Pete's review of 4871bis If I missed it, I apologize, but have you

Re: [ietf-dkim] spam filtering 101

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Alessandro Vesely Sent: Tuesday, June 28, 2011 12:13 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] spam filtering 101 +1, revising RFC 2505, whose date is in last

Re: [ietf-dkim] spam filtering 101, was DKIM expert group meeting for Dutch 'comply or explain' list

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Monday, June 27, 2011 2:43 AM To: DKIM Subject: Re: [ietf-dkim] spam filtering 101, was DKIM expert group meeting for Dutch 'comply or explain' list

Re: [ietf-dkim] I-D Action: draft-ietf-dkim-rfc4871bis-13.txt

-Original Message- From: i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org Sent: Friday, June 24, 2011 12:08 PM To: i-d-annou...@ietf.org Cc: ietf-dkim@mipassoc.org Subject: I-D Action: draft-ietf-dkim-rfc4871bis-13.txt A

Re: [ietf-dkim] I-D Action: draft-ietf-dkim-rfc4871bis-11.txt

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Ian Eiloart Sent: Friday, June 17, 2011 2:41 AM To: dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] I-D Action: draft-ietf-dkim-rfc4871bis-11.txt

Re: [ietf-dkim] Certified DKIM verification

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Alessandro Vesely Sent: Friday, June 17, 2011 8:13 AM To: ietf-dkim@mipassoc.org Subject: [ietf-dkim] Certified DKIM verification Hi all, does anybody know about

Re: [ietf-dkim] New canonicalizations

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Steve Atkins Sent: Monday, May 30, 2011 9:14 AM To: DKIM List Subject: Re: [ietf-dkim] New canonicalizations The most obvious thing that MLMs do that invalidate signatures

Re: [ietf-dkim] New canonicalizations

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Alessandro Vesely Sent: Saturday, May 28, 2011 9:29 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] New canonicalizations On 27/May/11 19:16, Murray S. Kucherawy

Re: [ietf-dkim] MLMs and signatures again

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Alessandro Vesely Sent: Friday, May 27, 2011 9:08 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] MLMs and signatures again Certainly a possible feature, but it

Re: [ietf-dkim] New canonicalizations

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Alessandro Vesely Sent: Friday, May 27, 2011 10:09 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] New canonicalizations By introducing a loose canonicalization we

Re: [ietf-dkim] MLMs and signatures again

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Thursday, May 26, 2011 10:44 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] MLMs and signatures again This sounds like you are missing a point

Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Ian Eiloart Sent: Thursday, May 26, 2011 3:08 AM To: John R. Levine Cc: DKIM List Subject: Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades I think the long term solution

[ietf-dkim] MLMs and signatures again

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of John R. Levine Sent: Thursday, May 26, 2011 6:40 AM To: Ian Eiloart Cc: DKIM List Subject: Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades Mailing lists have worked

Re: [ietf-dkim] MLMs and signatures again

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Steve Atkins Sent: Thursday, May 26, 2011 12:21 PM To: DKIM List Subject: Re: [ietf-dkim] MLMs and signatures again In my experience with traditional discussion MLMs

Re: [ietf-dkim] MLMs and signatures again

-Original Message- From: John R. Levine [mailto:jo...@iecc.com] Sent: Thursday, May 26, 2011 1:29 PM To: Murray S. Kucherawy Cc: DKIM List Subject: Re: [ietf-dkim] MLMs and signatures again If anyone's claiming that contributors' DKIM signatures on list mail are important, a good

Re: [ietf-dkim] MLMs and signatures again

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Franck Martin Sent: Thursday, May 26, 2011 1:13 PM To: Steve Atkins; DKIM List Subject: Re: [ietf-dkim] MLMs and signatures again side note: do mail receivers treat

Re: [ietf-dkim] MLMs and signatures again

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Steve Atkins Sent: Thursday, May 26, 2011 3:20 PM To: DKIM List Subject: Re: [ietf-dkim] MLMs and signatures again That's relying on an awful lot of vaporware in the MUA,

Re: [ietf-dkim] MLMs and signatures again

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Steve Atkins Sent: Thursday, May 26, 2011 3:47 PM To: DKIM List Subject: Re: [ietf-dkim] MLMs and signatures again It's not vapourware in general. Such feedback systems

Re: [ietf-dkim] MLMs and signatures again

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of MH Michael Hammer (5304) Sent: Thursday, May 26, 2011 4:15 PM To: Scott Kitterman; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] MLMs and signatures again The other

Re: [ietf-dkim] MLMs and signatures again

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Thursday, May 26, 2011 5:36 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] MLMs and signatures again My experience is it varies a lot by

Re: [ietf-dkim] New canonicalizations

-Original Message- From: Dave CROCKER [mailto:d...@dcrocker.net] Sent: Tuesday, May 24, 2011 5:33 PM To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] New canonicalizations Let's make it be the right work. To make a canonicalization algorithm

Re: [ietf-dkim] New canonicalizations

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Monday, May 23, 2011 2:21 AM To: DKIM Subject: Re: [ietf-dkim] New canonicalizations Could you get the effect of this by including the

[ietf-dkim] No signatures, bad signatures, cousin domains

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Monday, May 23, 2011 10:12 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] 8bit downgrades Do you have numbers to show that broken signatures

Re: [ietf-dkim] No signatures, bad signatures, cousin domains

-Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Sent: Wednesday, May 25, 2011 7:03 AM To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] No signatures, bad signatures, cousin domains Heuristic based systems like SA are subject to the phases

Re: [ietf-dkim] 8bit downgrades

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Sunday, May 22, 2011 10:43 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] 8bit downgrades Please refrain from passing the buck to the WG. The

Re: [ietf-dkim] New canonicalizations

-Original Message- From: Ian Eiloart [mailto:i...@sussex.ac.uk] Sent: Thursday, May 19, 2011 4:00 AM To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] New canonicalizations Right, but you can't address that by examining only the traffic from the high

Re: [ietf-dkim] New canonicalizations

-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Ian Eiloart Sent: Thursday, May 19, 2011 3:21 AM To: John Levine Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] New canonicalizations Probably true, but if the

[ietf-dkim] 8bit downgrades

Can anyone remember why there's a SHOULD for the downgrade to 7-bit in RFC4871 Section 5.3, rather than a MUST? The likelihood of breakage is so high when sending 8-bit data that DKIM almost becomes pointless without the upgrade. Not advocating for this to be changed in -bis (yet), but

  1   2   3   4   5   6   7   >