[ietf-dkim] feature tags

Just for fun I sent in a new I-D of the dkim-conditional draft that takes out version numbers and adds feature tags in a backward compatible way. https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for

[ietf-dkim] features and versions and running code

The current point of departure into DKIM is by the header field name. So I'm not sure why 'other than' is being queried, since it's the natural, existing point for going to a different protocol. Hmmn. Yesterday someone seemed to agree that keeping the same header name would make life

Re: [ietf-dkim] versions of RFC822 mail messages, Where is the formal definition of DKIM-Signature?

MIME was in significant use quite a bit before ESMTP was operational. In fact it's a non-trivial feature that MIME only requires adoption by author and recipient and not by /any/ of the infrastructure. IE, not by SMTP. Yes, I know, but I wish you'd read what I've said about 8BITMIME. It's

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

Sorry. Where is the version number for SMTP? MAIL FROM:<Борис@пример.ru> SMTPUTF8<-- These are not 'version' flags. They are feature indicators. They're both. If you use the feature, you're using the new version of the message. R's,

Re: [ietf-dkim] versions of RFC822 mail messages, Where is the formal definition of DKIM-Signature?

Well, that's simply and completely false. The message format specification(s) have no dependency on the email transport mechanism. Huh. When I look at RFC 822, section 3.1 says: The body is simply a sequence of lines containing ASCII charac- ters. It is separated from the

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

In article <20180209202621.31355.qm...@f3-external.bushwire.net>, Mark Delany wrote: Oh I dunno. The precedent of RFC822 - the very standard we rely on - has survived numerous upgraded and enhancements over a 36 year period and managed to do just fine without a version.

Re: [ietf-dkim] DKIM and EAI

If I may once again change the topic for a moment ... https://datatracker.ietf.org/doc/draft-levine-appsarea-eaiauth/ I pushed out a new version that says something about SPF macros, attempting to say that if you try to expand a UTF-8 local part, it doesn't match anything. I

Re: [ietf-dkim] [Editorial Errata Reported] RFC6376 (5260)

NEW Header fields are lines beginning with a field name, followed by a colon (":"), followed by a field body, and terminated by CRLF. A field name MUST be composed of printable US-ASCII characters (i.e., characters that have values between 33 and 126, inclusive), except colon.

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

The code that knows to dispatch to v=2 can, just as easily, parse for the strings associated with the new features. True, but not very interesting. In my spamassassin example, the outside code knows nothing about DKIM versions, it just sees a dkim-signature header and sends it to the DKIM

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

the DKIM library.  If it passes a v=2 signature to a library that only knows about v=1, the library will say it's invalid, which isn't ideal but isn't wrong. the code that tests for the v= parameter could, just as easily, check for the presence of the new features. Huh? v=1 code doesn't

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

They seek to distinguish important differences in processing for what is claimed to be the /same/ protocol. Except really they don't. Except when they do. I'm thinking, f'rinstance, that there is a bunch of code in things like Spamassassin that looks at headers and switches out to routines

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

On Thu, 8 Feb 2018, Mark Delany wrote: Heh. I'm still waiting to hear a good reason as to why "v=" exists at all - apart from exposing brittle parsers which mistakenly expect it to show up as the first tag. I had a draft that invented v=2, for headers with a tag syntax that is not quite

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

Header field name rules are in RFC 5322. That deals with case sensitivity for field name strings. Section 1.2.2 provides the basis for knowing whether a defined string is to be parsed in a case sensitive or insensitive manner. That's right, and all of the fields defined in 5322 have case

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

"v=1" doesn't have to come first. It just usually does. I think there was a version of RFC4871 that did that, but then when challenged we couldn't come up with a good reason to keep it that way. I wonder how many DKIM libraries will accept a signature where it doesn't. Regards, John Levine,

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

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, there's no ABNF for the header. So, for example, I don't know whether the v=

[ietf-dkim] DKIM and EAI

If I may change the topic for a moment ... I'm working on some stuff for ICANN to help people get EAI mail working. One of the underspecified bits of EAI is how authentication works with SPF, DKIM, DMARC and now, I suppose ARC. There's a bunch of places where one needs to make arbitrary

Re: [ietf-dkim] Mailsploit

From: =?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=00?==?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=@ mailsploit.com I'm with Steve, this is overclever in a world where most MUAs just show you the From: comment. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for

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

I'm with Murray -- why is this a problem? Single recipient has been the de-facto standard for years, and unless you are extremely bandwidth constrained, it's faster. No, it's not faster, see my answer to Murray. It's wasting a lot of ressources. People who've measured say the elapsed time

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

Also realize that this isn't "Gmail shouldn't sign spam", it's everyone who normally has a good reputation needs to not sign spam, this is a way to steal reputation from any service allowing you to choose your own message, and can be used against any mail receiver. Just wondering, roughly when

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

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. I'm with Murray -- why is this a problem? Single recipient has been the de-facto standard for years, and unless you are extremely bandwidth

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

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. Ah, I'd missed that you took out the magic hash goop. If it's optional, it's still a bad idea, but it breaks a lot less stuff.

Re: [ietf-dkim] DKIM Key Sizes

It's also probably worth ensuring that the major open source DKIM implementations support both signing and verifying with 4096-bit keys. Aside from OpenDKIM and dkimpy, are there any others that should be checked? Perl Mail::DKIM is still widely used. It calls Crypt::OpenSSL::RSA which is a

Re: [ietf-dkim] DKIM and EAI

In order to make EAI environment more friendly, I suggest that this WG considers to move this document/work forward. Which working group? DKIM hasn't existed in years. We'd have to spin up another one. It's one fairly short and I hope uncontroversial draft, so I'd suggest running it

[ietf-dkim] DKIM and EAI

On a bit of a side note, I wonder how much appetite there is for a document update? Besides this, we have no way to include non-ASCII UTF-8 local parts in i=. I wrote a draft about it, but I can't say it's gotten a lot of attention other than from Alexey:

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

ess someone proposes better text that gets a better reaction. S On 27/09/16 03:30, John R Levine wrote: > tl;dr the proposed correction does the right thing > > >>> Section: 3.5 >>> >>> Original Text >>> -

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

tl;dr the proposed correction does the right thing Section: 3.5 Original Text - x-sig-q-tag-args = qp-hdr-value Corrected Text -- x-sig-q-tag-args = dkim-quoted-printable ; with ":" encoded ... Section 2.10 shows: qp-hdr-value= dkim-quoted-printable;

Re: [ietf-dkim] DKIM Key Size Constraints

Apart from that I think we should start a (separate) effort to determine where we go from here. For the most part 2048 length keys seem not to be a problem in the wild at this time. On the other hand, given the speed (or lack thereof) involved in working groups generating useful output,

Re: [ietf-dkim] need for clarification on key size

Signer using a key larger then 2048 (like I do for years now) aren't inside the specification because there is no MUST on the validation side. From operational perspective I experience no drawback using 4k RSA keys for DKIM. I'm not surprised that 4K keys work. Most crypto software can

Re: [ietf-dkim] need for clarification on key size

The most likely issue would be that the TXT records don't fit in a 512 byte response packet which is a problem for some cruddy middleboxes. that was exactly the reason I started using 4k keys. I wanted to make sure at least my infrastructure could handle DNS over TCP everywhere. That's

Re: [ietf-dkim] EAI and 8bit downgrades

On Wed, 9 Jul 2014, Jiankang Yao wrote: Is there any RFC which deals with EAI DKIM ? how to deal with EAI message in the DKIM? Do we have a decision about it? We had a small amount of discussion but I don't recall any conclusions. Signing an EAI message should work the same as signing a

Re: [ietf-dkim] Timeouts retrieving keys from ietf.org

Sep 7 12:58:19 v2 opendkim[1019]: r87JwCmq008446: key retrieval failed (s=ietf1, d=ietf.org): timeout DNS query for `ietf1._domainkey.ietf.org' I did a little poking around and the problem appears to me that the IPv6 address for ns0.ietf.org, 2001:1890:126c::1:2, doesn't work. I tried it

Re: [ietf-dkim] Timeouts retrieving keys from ietf.org

Traceroutes confirm that it's dead, I sent a note to ietf-action. On Sun, 15 Sep 2013, Jim Fenton wrote: Slightly off-topic for this list, but the dkim-ops mailing list seems to be dormant... I'm getting a fair number of DKIM key lookup failures from ietf.org. I have run into this on two

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

That looks weird. Do we know its not spam? Well, he managed to put in plausible looking contact info. I'd say it's a crank or at best someone who is deeply confused about what IPR is. R's, John On 08/15/2013 04:44 PM, IETF Secretariat wrote: Dear Murray Kucherawy, Dave Crocker, Tony

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

EDSP would be tier 1 both senderside and receiverside. That's its selling point. ... TPA ADSP enhancements are tier 1 receiverside and just-barely-above tier 3 senderside. ... Did I miss some I-Ds describing these? Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet

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

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? Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies,

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

In reality, the recipient end DKIM deployment will be driven by sysadmins representing end-users who want less bad mail to reach them. Unlike the participating senders, they are not afraid of a phish or virus mail succeeding --- they merely do not want to be disturbed unless the mail is

Re: [ietf-dkim] Weird i= in client mail

Now on the other hand, if an administrative domain wanted to go to the trouble to authenticate down to the user level, we didn't want to prevent that, either. The primary audience for DKIM includes regulated industries, after all. Seems to me that works fine as is. If a stock broker wants

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

I've opened a ticket to arrange that t=y suppresses any positive impact domain reputation has in the next version of OpenDKIM, as an experiment. I'm inclined to leave well enough alone. That wouldn't have been an unreasonable interpretation six years ago when DKIM was new, but this is the

Re: [ietf-dkim] Thoughts on ADSP discardable messages BCC'ing the postmaster? (akin to a FBL)

I'm reading the archives on ADSP and haven't seen anyone pitch the idea that on verification failure, we could have the message in question would be BCC'd to the domain owner's administrator for review. I am a teenager with a lot of spare time, so I'm going to send thousands of random

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

I'm not seeing much agreement on any changes to Murray's final draft, so may I suggest that it's good enough and we should ship it? The potential benefit of the proposed changes doesn't impress me as worth the amount of argument they're provoking. Regards, John Levine, jo...@iecc.com, Primary

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

On 7/6/2011 10:59 PM, Michael Deutschmann wrote: Under the double-From: exploit Otis is so concerned about, one signer can (given favorable winds) trick an end-user into thinking his message was signed properly *by someone else*. So indeed, a signer can attack. A signer can attack a

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

When DKIM signatures serve as a basis for acceptance, ... Since they don't, can we skip the rest of the screed? Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly

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

The first thing is that it's out of scope to address changes to things that were in RFC 4871, which was approved by the working group, the community, and the IESG in 2007, if it's simply a question of one or two people not liking those things so much -- even if one or two of those people now

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

For me, as an MTA operator, I'm happy that I have justification for rejecting messages with the wrong number of From: headers. I have pointed out at least six times, that in the extremely unlikely event that bad guys were to send mail with double From headers you can just dump it, since no

Re: [ietf-dkim] DKIM expert group meeting for Dutch 'comply or explain' list

Acceptance policies and results for DKIM MUST align with what is being displayed in the message. I'm pretty sure that we have uniformly agreed not to attempt to do MUA design, so, no, it doesn't. We have no idea what is displayed in the message. We have no idea if the message will ever be

Re: [ietf-dkim] DKIM expert group meeting for Dutch 'comply or explain' list

I'm pretty sure that we have uniformly agreed not to attempt to do MUA design, so, no, it doesn't. We have no idea what is displayed in the message. We have no idea if the message will ever be displayed at all. Ian, John is right. Most headers are displayed selecting top-down If you'll

Re: [ietf-dkim] DKIM expert group meeting for Dutch 'comply or explain' list

Assuming this is some other protocol layers problem; to ensure consistency between any possible display and DKIM validation, ... ... is, for about the hundredth time, not DKIM's job. Please chant we have no idea how MUAs will display mail over and over until you believe it. This includes

Re: [ietf-dkim] the non-problem of contributor signatures, was DKIM Scouts

I didn't posit this as a problem. Others did. I jumped in at the point that you said s/mime was already a solution, with a message that proved otherwise. It would be better to say that if there were a problem, and people wanted to solve it, the pieces are all there with S/MIME. MUAs all know

Re: [ietf-dkim] New canonicalizations

Chain of trust is always an appealing model. Unfortunately, it hasn't been used successfully over the open Internet. I agree with your doubts about the utility of chain of trust, but I would have to say that SSL signed web sites are used successfully over the open Internet. Regards, John

Re: [ietf-dkim] New canonicalizations

So as far as I can tell, we're at a point where lots of people think they want MLM survivability of signatures, or at least the chain-of-trust capability, but no proof that the increased risk is worth the increased gain. I would quibble with the word lots. Perhaps a few highly vocal. Put

Re: [ietf-dkim] MLMs and signatures again

2) do we need a mechanism to alert the receiving MTA that you have subscribed to a mailing list, and all messages should pass through? Yes, desperately. Certainly a possible feature, but it seems like it won't scale very well. Why not? If I were a spammer, I would tell the victim's MTA

Re: [ietf-dkim] New canonicalizations

By introducing a loose canonicalization we may learn whether signature survivability affects DKIM adoption. Feel free to do some experiments. One of the reasons that DKIM has had relatively few implementation surprises is that we already knew how DK worked. Regards, John Levine,

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

So this tells me that existing mail software doesn't try very hard to recover signatures from modified messages, even for simple changes that don't need any guessing or heuristics to undo. My client found the signature, otherwise it would not have commented on its validity. It just wasn't

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

Well, something's wrong with it. I checked the signature in Alpine, Thunderbird, and Evolution, and they all agree it's fine. FYI, I checked copies coming through the list in Apple Mail 4.5, and it sees the signature, too. I was mistaken about T'bird, 3.1.9 on the Mac and 3.1.10 on FreeBSD

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

It tells me signing and encryption certificates are valid and even their root certificates are valid... Well, something's wrong with it. I checked the signature in Alpine, Thunderbird, and Evolution, and they all agree it's fine. I went back and looked in more detail. The problem appears to

Re: [ietf-dkim] dot-forward, was 8bit downgrades

Although it is a minor number of messages, I don't think that ignore-by-design could play a winning role here, because --unlike mailing lists-- there is no way to eventually fix this at the forwarding MTA. If the EAI work is any guide, in the long run everything will be 8 bit, and downgrades

Re: [ietf-dkim] 8bit downgrades

Barely. That's 0.1 on a default threshold of 5.0, I think. Granted, it's a small penalty, yet it's a penalty. I'll ask the spamassassin developers where the number came from. SM's suggestion that it has to be non-zero to exercise the code may be it. Regards, John Levine, jo...@iecc.com,

Re: [ietf-dkim] 8bit downgrades

Exchange advertises 8bit and then bounces the mail if it tries to forward it to a server that doesn't advertise 8bit. This (entirely RFC valid yet completely broken) behaviour has bitten me a couple of times. Better get used to it, since that's what EAI is going to do, too. Regards, John

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

Are there the same issues with PGP or S/Mime email? Generally no. They're a group of MIME parts that shouldn't need to be recoded, or even if they are, will decode to the same value. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the

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

and back) and the S/MIME signature still is OK. R's, John On 5/24/11 15:35 , John R. Levine jo...@iecc.com wrote: Are there the same issues with PGP or S/Mime email? Generally no. They're a group of MIME parts that shouldn't need to be recoded, or even if they are, will decode to the same

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

It tells me signing and encryption certificates are valid and even their root certificates are valid... Well, something's wrong with it. I checked the signature in Alpine, Thunderbird, and Evolution, and they all agree it's fine. On 5/24/11 18:13 , John R. Levine jo...@iecc.com wrote

Re: [ietf-dkim] 8bit downgrades

In the real world signature reliability matters. If a domain signs mail as a rule then an absent or broken signature will be treated as suspicious. I hope you're wrong, since that violates an explicit SHOULD in RFC 4871, and in my experience, most broken signatures are due to innocent

Re: [ietf-dkim] New canonicalizations

If one were to encode somehow an extension indication that this content was subjected to 8-to-7 downgrade as a hint that a verifier should do the reverse before verifying, the verifier would have to manage to undo the downgrade in precisely, i.e. byte-for-byte, the same manner that the

Re: [ietf-dkim] EAI and 8bit downgrades

Specify MUST, but clarify that this is just for now and may be revisited at a later time -- for example, if the SMTP protcol design community ever backs down and accepts DJB's approach to the 8-bit message problem (http://cr.yp.to/smtp/8bitmime.html, essentially that it is OK to break any

Re: [ietf-dkim] New canonicalizations

Interesting, but not less intricate. The semantics of authenticating only the armored part of a message is not obvious. Resorting to base64 encoding is subject to varying interpretations, including spammers attempts to avoid naive content filtering. S/MIME and PGP MIME have been doing just

Re: [ietf-dkim] Certifying the DKIM public key?

through a separate, value-added mechanism. My own preference would be for using a special header-field that contains the cert, with the specification of using such certs as saying that they are enabled when included in the set of h= covered header fields. I don't see how this is

Re: [ietf-dkim] Certifying the DKIM public key?

VBR queries are about an actor, not a message. Certs can be coupled to a particular message -- this was an interesting semantic distinction about Goodmail's certification scheme -- although I believe that typically they, too, are only scoped to the actor, not the specific content. Now

Re: [ietf-dkim] Certifying the DKIM public key?

But this is exactly what DKIM is. You prove yourself fsvo prove to the registrar who certifies you by virtue of placing your NS records in the root servers instead of issuing a cert. Registrars, as we all know, rarely check any credential beyond the confirmation code from the credit card

Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP

As chair, I can say that consensus was to make this normative, not experimental. With the best will in the world, I was there, and I saw no such consensus. The closest thing I can find in a quick search of the archive is this note, which says that the group agreed on one thing (that lists

Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP

2. Should this be Informational or BCP? a: BCP, making it clear when we're insufficiently certain about something. Last Call will sort out any objections. Well, I couldn't afford to go, so I can't say you're wrong, and I don't know why I didn't see that on the list. I guess

Re: [ietf-dkim] Section 3.7 s/content-hash/body-hash/?

I think this should be limited only to change content-hash to body-hash in the data-hash line, which is correct. +1 Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly

Re: [ietf-dkim] discardable, was Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP

I'd propose to put this item ('writeup a definition of 'discardable') on the to-do list of a successor of RFC5617, if there ever will be one. Or on another future 'policy' document. -1 RFC 5617 has a perfectly good definition of discardable: All mail from the domain is signed with an

Re: [ietf-dkim] New canonicalizations

Thus the following two forms Content-type: text/plain; charset=us-ascii (Plain text) Content-type: text/plain; charset=us-ascii are completely equivalent but they are not DKIM-wise equivalent. I'm sorry, but this is just so wrong. Helpful software can modify mail in a million ways that

Re: [ietf-dkim] New canonicalizations

The underlying concern here actually is pretty reasonable: Variations that do not affect the appearance or semantics of a message could reasonably still permit a signature to verify. Oh, sure, but we also traded off the cost of handling changes and how common they are. For example, old

Re: [ietf-dkim] New canonicalizations

In retrospect, it probably would have been better only to provide simple and tell people more firmly to do the signing after and the checking before any local modification. That implies hop to hop rather than end to end. What would the advantage over SPF be then? The fact that most hops

Re: [ietf-dkim] MLM and C14N

Hi Hector, At 15:20 14-05-2011, Hector Santos wrote: Shouldn't the MLM I-D say something regarding C14N and CR/LF related mutations? No. +1 to the No. I have my reservations about the draft, but this is not one of them. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The

Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP

I think it's best to have an example. cron seems to be an ideal one, though I'd be happy to add a second, Windows-specific, example if there is one. If not, changing 'such as cron' to 'such as the cron UNIX utility' seems a better change to me. Anyone who's ever managed a Unix or linux

Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP

I'd be very surprised to find that mention of cron in an RFC is unprecedented. Maybe I'll download the RFC set, have Google do a word index on it, and see. RFCs 2123, 2839, 4833, and 5427 refer to cron and cron jobs. There may be others, but I found those with a simple grep. (If anyone was

Re: [ietf-dkim] PROTO writeup for draft-ietf-dkim-mailinglists-10

This is a valid point. Sean, please consider that the working group did not discuss the possibility of changing the status from BCP to Proposed Standard. You might remove that from the writeup. I suspect you would find signficant objection to making it a PS. Considering how little of the

[ietf-dkim] DKIM and mailing lists

I realize it's a little late, but here's what I think the MLM document should have said: http://www.taugh.com/draft-levine-mlm-minus-00.html I shamelessly stole Murray's intro sections, but you should blame me for the whole thing, borrowed or otherwise. Regards, John Levine,

Re: [ietf-dkim] DKIM and mailing lists

I think You miss to state the important point that MLMs usually preserve the RFC5322.From when sending the email to the subscribers except in digest mode where it replaces it by the list-owner(?) email. This is why ADSP fails, otherwise if the RFC5322.From was replaced we would have no

Re: [ietf-dkim] I-D ACTION:draft-ietf-dkim-mailinglists-08.txt

4.3 it would be nice to talk about message encoding change like QP-8bits, may be in minor or major body changes. It is a minor change for the human but major for the machines as many characters got changed. Which MLMs do this? I've never heard of that. mj2 does all sorts of MIME smashage,

Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output

1. State principals that are specific to the content of the draft and that give guidance about the scope and boundaries of what should be covered. 2. Make specific suggestions for specific bits of text in the draft. Despite the valiant work that Murray has put into the MLM document, my

Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output

Might not be list traffic. But I have data for that too. Count of signatures with l= that did or didn't appear to pass through an MLM: +--+--+ | count(*) | mailing_list | +--+--+ |77246 |0 | |78853 |1 |

Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

this, but I need to get a clear view of consensus. Doug agrees with Hector's note, below, and Dave and Murray do not. I'd like to hear from others within the next few days, about whether you think we should make the change Hector requests or not. Dave and Murray are right, Hector is not.

Re: [ietf-dkim] 23 again (sorry John) was Output summary - proposing ODID Originating Domain Identity

Alternatively we can allow it, warn, and expect implementers to code heuristics that can discern attacks from regular footers. Speaking as an implementer, I ignore l=, because the hassle of working around it and trying to guess how hostile any added content might be is vastly greater than any

Re: [ietf-dkim] 23 again (sorry John) was Output summary - proposing ODID Originating Domain Identity

I agree, as a participant. Nevertheless, we have consensus to leave it in because of the stats Murray gave us on the usage (on the signing side). I agree we need to leave it in, but as I said, I would rather not offer advice about how to code around its limitations, not least because

Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity

For a scenario where a caller is calling a DKIM milter which in turn calls an API, this is all true. But DKIM will be/is deployed in many more scenarios. Indeed, but you're misunderstanding the point of a standard. The DKIM spec tells signers how to create a signature that recipients can

Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity

Has anyone other than me bothered to generate and review the complete diff? I have. The changes to the parts that actually describe how to create a signature are tiny, and well contained, e.g. updating the punycode definition, making sha-1 more deprecated, clarifying that unknown options and

Re: [ietf-dkim] Ticket 23 -- l= and Content-type

I don't think we yet have consensus to take out l= but it is quite clear that the problems it causes are far greater than whatever problems it might solve. As Hector notes, it is required by non-DKIM aware MLMs. To aim one more kick at the greasy spot on the floor where the horse used to

Re: [ietf-dkim] Ticket 23 -- l= and Content-type

I don't think we actually understand all the ways that l= allows you to shoot yourself in the foot, so I would prefer not to give the impression that if people avoid a few cases we describe, they're safe. -1, I agree we don't know all the ways DKIM can be fooled. Neither we actually saw

Re: [ietf-dkim] Ticket 23 -- l= and Content-type

What's your counter-proposal to Alessandro's proposal to modify 9.1.1? Oh, that. Replace all of sec 9.1 with: As noted in Section 4.4.5, use of the l= tag enables a variety of attacks in which added content can partially or completely changes the recipient's view of the message. I don't

Re: [ietf-dkim] Ticket 23 -- l= and Content-type

1. This is just a variant of the basic hole created by use of l= 2. The premise that having the l= go to a multipart boundary somehow increases security is simply wrong. More generally, the idea that one or another tidbit might tighten things a bit, l= opens such a huge door, the

Re: [ietf-dkim] Ticket 23 -- l= and Content-type

On Fri, 29 Apr 2011, Murray S. Kucherawy wrote: On further consideration, I'm with Dave. Suggest removing the current language about l= and MIME boundaries, and replace with a note that if you use l=, added content can change the appearance of a message in hard to anticipate ways. Replace

Re: [ietf-dkim] Output summary

I wouldn't be opposed to doing so, except that 4871 says in two separate places not to do that. Section 7 is, now that I look at it, really badly written, since it implies that a verifier is an SMTP server. I can take a run at fixing Section 7. What's the other place that says not to do

Re: [ietf-dkim] Output summary

Last paragraph of sec 5.2: Verifiers SHOULD ignore failed signatures as though they were not present in the message. Is that inconsistent with the idea of only reporting signatures that verified or those that TEMPFAILed? In that model, failed ones aren't reported which is logically

Re: [ietf-dkim] ADSP stats

We check ADSP every time we run DKIM and see the following policy distribution: 97.98% unknown (including domains not explicitly publishing policy) 2% discardable 0.02% all That's not surprising. Keep in mind that the design of ADSP means that you're supposed to check mail that's not

Re: [ietf-dkim] Two issues derived from Ticket #20: signature practices

+1, and also for Murray's advice of signing A-R fields. I still don't understand why, if you trust a signer enough to believe the mailing list A-R headers he signs, you don't trust him enough to deliver the mail, and, of course, why we now need to remotely verify contributor addresses when

Re: [ietf-dkim] Output summary

Do we need to say anything about the possibility that there are multiple signatures? How about For each signature not ignored by the verifier or such. Section 5.3 says: Verifiers SHOULD ignore failed signatures as though they were not present in the message. and Section 7 says:

Re: [ietf-dkim] Output summary

As for TEMPFAIL, you'd have to know which signature(s) were temp-failed in order to decide about a later retry, which then leans us back toward giving the whole list of signatures that were present and a status for each. I wouldn't be opposed to doing so, except that 4871 says in two

  1   2   3   4   >