In article <20180210092127.33398.qm...@f3-external.bushwire.net> you write:
>In any event, 822 is an existence-proof that decades-long upgrades are entirely
>possible without the scorched-earth approach of versioning. ...
Nope, see the PS. But anyway.
I don't understand this scorched earth
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 A-R
specs.
R's,
John
___
NOTE WELL:
In article <20180208203207.26575.qm...@f3-external.bushwire.net> you write:
>After all, what are most senders going to do? They will not want their
>signatures to be suddenly unrecognized by 99% of the planet so they'll continue
>to generate a v=1 header and they will also want to reap the bennies
I'm surprised Network Solutions had this problem.
Unfortunately, I'm not. The current incarnation of NSI is a pale
shadow of its former self, a subsidiary of web.com that as far as I
can tell exists primarily to provide one-stop registration and
hosting, along with business from the
http://wiki.apache.org/spamassassin/Rules/DKIM_ADSP_CUSTOM_MED
If you look at the DKIM configuration files, you'll see that the ADSP
usage is almost entirely faked up, via a list of entries for the usual
phish targets (ebay, paypal, etc.) to pretend that they have ADSP
records:
This is a formal request, to have DomainKeys Identified Mail (DKIM) Author
Domain Signing Practices (ADSP) (RFC 5617) moved to Historic status.
I'm one of the authors, and I think it's a dandy idea.
Other than a few experiments and one or two impressive misfires, such
as one that bounced
My problem is that absent a draft, you're lobbing a vague proposal over the
wall and hoping the community will do all of the work for you.
That was my sense, too.
Writing a draft and submitting it is not a huge effort (at least, not
if you know what you're going to say), and it has the advantage
It has many potential uses, but within DKIM itself, it's an expansion socket.
Keep in mind that there are IANA registries for the tag names in both
the signatures and the key records. If you want to try something new,
just pick a tag name or two and have at it. RFCs 6541 and 6651 have
recently
My understanding matches Dave's. The i= value is an opaque token
which for purely historical reasons has to look like an address in a
subdomain of the d= domain.
I've asked the client why they chose that, we'll see what they day.
Huh, that's what the code does. Should it do something else?
I haven't been able to find anything that discusses the intention behind the
i=. I expect
they chose this i= because that's the envelope from, but the i= is suppose to
be a person,
not a mechanical address, correct?
Historical bit: it is my impression that i= was invented by people who
were
At one stage i= was thought to represent different mail streams with different
reputation,
however this did not get any traction...
As far as I can recall, I don't think anyone but you had that theory.
If you want two streams, you use two d= domains.
On my system the i= tells how the mail was
Will your assume one more From than listed in h= lead to failed
verifications on messages that actually follow the advice in the RFC
to list duplicate headers in their h= values?
The RFC also says you shouldn't sign messages that aren't RFC 2822. So
pick your poison.
I have to say it's a little
Ian's MTA has a buggy callback system that tries to use fake bounces
to guess whether a sending address existed. I thought these had been
stamped out due to both the fact that they mostly attack innocent
bystanders, and the fact that they don't work, but I guess not yet.
R's,
John
Let's say I route all traffic from list X to its own separate
mailbox, but I also want my MUA to flag for special attention mail
sent to that list by people I hold in high regard, for example, and I
want that to be based on their accumulated reputations. I either
have to base that on something
In my experience, the reputation of the list is unrelated to the
reputation of its participants.
Given how little DKIM-related reputation work has been done, deployed and
heavily used so far, perhaps we should all be a bit cautious about taking
existing practices and treating them as
The idea is to anticipate any unknown signature breaker.
I'm pretty sure that's specifically out of scope.
And I promise that whatever you do, short of wrapping the whole
message in opaque armor, I can come up with something that will
break it.
Regards,
John Levine, jo...@iecc.com, Primary
Of the 31, 20 were from Keith Moore signed messages into the IETF-SMTP
list with a 3rd party signature and Hoffman's list server (non-dkim
aware) doing this:
Oh, it's a mailing list. Why are we even having this discussion? We all
know there's a million ways that lists break incoming
Could you get the effect of this by including the
Content-Transfer-Encoding header in the 'h=' and doing some fancy checks
involving the 'bh=' (to detect whether it was the body or the headers or
both that were broken)?
No, of course not. The bh= and h= are just hashes, so all they can
recently someone asked me whether it would have any added value if the
DKIM public key, which is stored in DNS, would be 'certified' in some
(yet to be determined) way by a 3rd party like VeriSign, Thawte etc.?
Sure. See RFC 5518.
R's,
John
___
NOTE
Since I more or less started this, my assertion was that relaxed doesn't
do much better than simple, which at this point I think we can categorize
as not disproven.
The point I was making was that ever more complex ways to decide that
two mutated versions of a message are the same aren't likely
It's unnecessary and unwelcome to call what other people write stupid.
FYI, that section is taken verbatim from the MLM draft that Barry sent
off yesterday. I guess now we know who read it and who didn't.
R's,
John
___
NOTE WELL: This list operates
Oddly, I'm finding myself coming to believe that its use within a coordinated
template for mediators might actually being helpful. This assumes, of course,
that the template can be specified and gain consensus, and that signers,
verifiers and mediators all are willing to implement it. Hence,
I think it was a mistake to include l= in the first place, but I
find Murray's arguments against taking it out now persuasive.
I would also really like to have a better idea of how people are
using it, notably, for all those messages where l= doesn't cover
the whole body, what's in the naked
I appreciate the work that Doug and Charles put into their proposal,
but for reasons already discussed, I think we should leave section
6.1 as is in -09.
R's,
John
___
NOTE WELL: This list operates according to
I don't think this is correct. The signer creates and signs the i= value,
so it's not garbage, and it can't be false either.
Perhaps the word stable would be more applicable. The d= value is
tied to the DNS, is relatively stable, and the verifier can check that
there's a key record in the DNS
It is indeed an effort based, at least in part, on clarifying stuff
we learned since the earlier version based on experience. I think
it's pretty clear that's what's being done. Dropping g= is a prime
example.
We've hardly changed the parts that describe how to create and verify
the signature
4.9. Output Requirements
The output of the verifier MUST embody:
embody -- include (if it embodied them, that arguably implies that it doesn't
include anything else)
- A result code that indicates whether or not the signature was
validated (PERMFAIL or TEMPFAIL as
described in
Whether the name in the DNS record should be brisbane or
brisbane._domainkey or brisbane._domainkey.example.org depends
entirely on the most recent $ORIGIN line in the master file. If the
$ORIGIN is _domainkey.example.org, an entirely plausible scenario, the
current text is correct.
I see no
I agree with Dave, the proposed change is entirely outside the scope
of DKIM. Suggest closing the ticket with no change.
R's,
John
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
As previously discussed, a binding between the domain in d= and the
domain in another header is outside the scope of DKIM.
I suggest deleting the paragraph with no replacement.
R's,
John
___
NOTE WELL: This list operates according to
I don't so much view DKIM as protecting content; rather, my current view
of its semantics aligns with the whole taking some responsibility for
approach.
So far, so good, the signer takes some responsibility for the message.
And thus, a signer should only sign those parts of the header and
body
Pretty short-sighted if you ask me.
NANOG is an interesting mix of cutting edge network managers and
people who seem to have configured their networks in 1998 and see no
reason to change it now. The latter group often go out of their way
to avoid seeing reasons to change it now.
R's,
John
Nits:
In 4.5: for consistency, please use the same a-label language for d=
and i= tags. The same language needs to go in s= since selectors are
domain names, too. Suggested language all three places:
Internationalized domain names MUST be encoded as A-Labels, as
described in Section 2.3 of
The only thing that's not obvious to me is whether the hash functions
should hash the bytes of the UTF-8, or convert them to UTF wide
characters and hash those. Depending on the way the MTA is written,
either might seem more natural, but I'm inclined to say you hash the
UTF-8 bytes because
That's what I did. The only ADSP I see this year is Paypal.
That's a success story of a sort. We know that ADSP is only
potentially useful in a narrow set of circumstances. Data that
indicates the protocol isn't being widely deployed for domains for
which is not suited is good news.
Along
Sorry, this message makes no sense. The IETF has been working on non-ASCII
domain names and
e-mail for over a decade, and we are certainly not going to do random things
that ignore that
effort and the many RFCs that describe the use of IDNs in the DNS.
Sounds like what we actually need is
Would it be acceptable to put some text like the following?
Internationalized domain names MUST be represented as A-labels
as described in [RFC5890].
NOTE: For experimental use only, domain names MAY be
represented in UTF-8 as described in [RFC5335].
Please, no. If you're
The stuff having to do with producing an alternate version of the
text is certainly wrong insofar as there's no extra visible copy
produced, but I've always interpreted that language as referring to
the internal copy that gets fed to the hash function. It certainly
could be that I've just been
Oops, this is a separate issue. But I hope it's also not
contentious.
3.5, d= and i= tags: references to RFC3490 should be RFC5890. The
reference to ToASCII() should go, or else in both places say IDNs are
represented as A-labels.
Suggested new language under d= on page 22:
Change:
For there to be reasonable semantic meaning, it must be understandable.
Whether it were done by adding semantic signposts for i=, additional tag
values, or additional 5322 headers, it should *not* be done in an ad-hoc
fashion.
Quite right. We need drafts, implementations, all the usual stuff.
Isn't it obvious?
Yes, but not in a good way.
We'd like to be able to deploy DKIM, coupled with some ADSP-like protocol
(The real ADSP is hopelessly inadequate) in order to block all forgeries at
the MX. *All* forgeries, not just phish.
Well, as we've established long past the point of
One new-ish data point: I believe Hotmail is leveraging the ADSP records from
domains they trust to be operating with consistency.
As has often been pointed out, if it's domains you already know
something about, you don't need ADSP.
ADSP is only the most obvious of assertions that people make
Signers SHOULD NOT remove any DKIM-Signature header fields from
messages they are signing, even if they know that the signatures
cannot be verified. Instead, when a relay alters a message such
that any valid signature gets broken, it SHOULD re-identify the
message by synthesizing a
Another way is to have a dkim tag that specify the header that
indicates the stream classification
Many ways to kill the same bird.
If there is a reason why people aren't able to use a d= domain per
stream, I wish someone would explain in simple terms that even a
dimwit like me can understand.
2.3. Identity
A person, role, or organization. In the context of DKIM, examples
include the author, the author's organization, an ISP along the
handling path, an independent trust assessment service, and a mailing
list operator.
The current language looks fine to me.
R's,
John
Anyway, the list should be signing messages after adding subject line
prefixes, and after adding body footers. It's the list's signature,
and the list's reputation that need to be assessed by the
recipient. There are many other modifications that a list might make
(like stripping attachments, body
With the output of DKIM being the SDID, the identity associated with the
signature is of course that of the domain. But when my author-specific
domain signs a message for me, it's the domain that does that -- it
doesn't matter that it's an organization of one. Putting author here
just hints
On 3/28/2011 11:27 PM, Jim Fenton wrote:
1. authors and their organizations could be misinterpreted ...
I'm with Dave. It looks clear ro me that it's a list of examples.
The Signer MAY choose to use the same namespace for its AUIDs as its
users' email addresses or MAY choose other means
Furthermore, I'm not sure whether the DKIM WG has concluded on
thinking about the value of DKIM, what it can be used for. Is it's
purpose limited to providing input to a reputation engine? Is that
it? Or is there more than that?
Those are all interesting questions, but I don't see what they have
Hence, I could send a phish as:
From: PayPal mich...@talamasca.ocis.net
Um, you must be new here. We've argued about this ad nauseam
over the years.
As Dave points out, DKIM does not validate anything other than that
the message you received is the same as the one the signer signed (for
a
Therefore, a verifier SHOULD NOT validate a message that is not
compliant with [RFC5322, RFC2045 and RFC2047] specifications.
IMHO, it is somewhat vague. That SHOULD-NOT could be promoted to a
MUST-NOT for a finite number of specific features --to be explicitly
listed for readers'
will generally produce a response to a DKIM query that
is not a valid DKIM key record. This problem applies to many
other types of queries, and client software that processes DNS
responses needs to take this problem into account.
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator
sense to do DOSETA, which strikes me as premature
until we have a better idea of what the applications are, make it a
short document that defines a subset of DKIM features by reference to
the DKIM spec.
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies,
Please
Here's the proposal that Barry just announced, for splitting the DKIM
specification into a DKIM-specific portion and an underlying, more generic
portion that could be re-purposed for other services. It's current working
acronym is DOSETA.
Seems reasonable to me, both the split, and the plan
Comments welcome, even if it's just I read this, looks good to me
so that some support or consensus can be recorded.
I read it, it almost looks good to me. A VBR-Info header can list
multiple certifiers, so unless there's something I missed, the vbr
clause in the A-R header should include the
A DKIM verifier generates a single bit, validly signed or not,
and an identifier in the validly signed case.
Well, actually, if you read 4871, it also produces an edited version
of the message. As I suggested in my message a few days ago, I don't
think that's what we intended, and we should fix
The thought is that two Subject lines is worth rejecting, an extra at
sign in the Message-ID is not.
I'm fine with that if we think implementers will find it easier to construct a
comprehensive likely list versus just enforcing the spec.
It's not easier but I'm with Steve here. People are not
I mostly agree. (Wow!)
1) During the handling of a message in conjunction with a DKIM result that
indicates a
valid signature, consider as valid only those fields and the body portion that
was
covered by the signature. Note that this is not to say unsigned content is
not valid,
but merely
Page 11, informative implementation note at the bottom of the page:
Delete it. If we want to support EAI, we should support EAI, but
this language just encourages code that won't interoperate.
I don't see anything on page 11 about EAI, nor any informative notes.
Oops, that's page 12, the
DKIM makes no statement about the validity of a sender address.
d/
I guess I should have said Author address.
DKIM makes no statement about the validity of an Author address.
In practice, if I look at mail with yahoo.com author addresses for example,
I find that with DKIM yahoo.com
difference between a green bar SSL page and one with no SSL. I don't want
to mess with the MUA at all, but rather use DKIM to help decide what
messages to show her and which messages to consign to the junk folder.
Why do we think such a sorting module can't/won't have the
intelligence to do
There's a strong correlation between badly structured emails (SMTP,
MIME, HTML) and email that the recipient doesn't want to see.
You're right, but I think that's largely orthogonal to DKIM. If a
message has a good signature from a credible signer, I expect I'd want
to show it to the user even
US PATENT 7487217
http://www.freepatentsonline.com/7487217.html
but then it seems prior art existed in the form of DKIM (which was
started around 2004 http://news.domainmonster.com/dkim-email/)
This isn't a patent about authentication, it's about spam filtering
using the reputation of domains
In article 201010151013.26823.ietf-d...@kitterman.com you write:
On Friday, October 15, 2010 10:04:40 am MH Michael Hammer (5304) wrote:
why don't we just deprecate l=?
Yes. Please.
Agreed. Has anyone ever found it useful for its nominal purpose of
messages transiting MLMs?
R's,
John
In this case, we've gone to some lengths to make the environment
pure, by using the underscore branch. And then along come these
pesky wildcards.
Even without wildcards, there's been a variety of broken key records.
I would hope it would be obvious that you have to assume that any data
you
- In order to make use of ADSP, Y needs to change which MTA it's
using. This is almost certainly an expensive effort.
- Y simply can't use ADSP.
- The DKIM reporting extensions should have a flag that says DSNs
should not cause generation of fraud reports.
I'll take
Subject: Buy fake watches at fakewatch.example.com!
Will some clients display the second subject line? I suspect some
will. Do we need to recommend that signers also add a protective second
subject: to their h= value? Or do we need to require that verifiers
make sure that any header fields
A) You have to sign either all occurences of a header or none of them, ...
B) Same as A, but limited to an enumerated set of headers that are
supposed to occur only once.
c) Same as B, but tell signers to use the h= trick to make verification
fail if extra headers show up.
My perception of the rough consensus is that we do want to make
some statements about the issues discussed in the draft. However,
the only truly normative thing upon which we appear to agree is that
MLMs should sign their mail. I would rather we produce this more
complete document at a
It has been observed by implementations that is it possible to replay
a message with a 2nd 5322.From header at the top ...
A thing with two From: headers isn't a valid RFC 5322 message.
You may recall a lengthy argument about what to do with messages with
bare carriage returns, with the final
Still, though, it's a solution to deal with malformations to which
MUAs are susceptible, and not strictly a DKIM problem.
Would it be a good idea to recommend in 4871bis that DKIM
implementations should not sign or verify invalid messages? I
cheerfully admit that I haven't thought out all the
This might be a good time to remind people that MLMs in their
current form are not broken, and any proposal that requires them to
stop doing something that they're currently doing, like rewriting
messages or adding message tags, is a non-starter.
Since nothing requires anyone do anything with
That no workable envelope-level DKIM equivalent has materialized to
date is unfortunate.
Not for lack of trying, but I just don't see how you could prevent bad
guys from replaying good envelopes on bad mail.
Yeah. Short-lived keys is the best thing I can come up with.
Do you think it's
Do concepts generalize enough to allow issuing
draft-ietf-dkim-mailinglists also for these authoring MLMs?
No. All of the complications in mailing lists arise from the fact
that the author of the message is not related to the operator of the
list.
Even though ESPs are generally sending mail
Sounds like an improvement to me.
Yes and thanks!
Seems unanimous. Dave, do you have enough changes to do another
version?
R's,
John
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
To apply the 'normal' and commonly used in other contexts (eg contracts
and insurance) definitions.
The sender is the first party.
The recipient(s) jointly and individually are the second party.
Anyone else is a third party.
I have never heard anyone talk about 2nd party signatures.
S/MIME
But what everyone has been telling me is that it would be better in
fact to go and deploy something before drafting the I-D and debating
it here. This is the main reason why I went quiet on these lists
since the Barcelona MAAWG meeting (until this week).
Yes indeedy.
Keeping in mind that
Forgot to mention: I'd totally support the creation of a separate
draft listing Things We Thought Of But Haven't Tried Yet, so long as
it's clearly labeled.
Of course. This is the Experimental I-D and perhaps RFC that I've
been encouraging people with paper designs to write.
R's,
John
It's not clear to me that there's consensus that anything qualifies as Best
Current. We have some small samples of a few things that some people have
tried, but I don't sense we're there yet.
I hope that lists signing their outbound mail qualifies. Large
providers Googlegroups and Yahoogroups
This is not the only potential use of such a feature. I've spoken
to one MLM developer who told me the feature has been previously
requested for privacy reasons nothing to do with DKIM or ADSP.
That sounds like a somewhat different feature. What we've been
talking about so far is basically
ANNEX A - MUA Considerations
Is a draft about mailing lists the right place to make recommendations
to MUA developers? Seems like those should probably be in a separate
document.
No, but the entire document is riddled with advice that has no basis
in experience and is unlikely ever to be
At this point, unless we can cut back the MLM document to stick to
items that we have consensus about, e.g., that it is typical for
signatures applied to incoming mail not to verify after a message
passes through an MLM, and that it would be nice if a list or its MTA
signed its outgoing mail,
l= over substantial opposition under the theory that it would compensate
for a significant fraction of MLM modifications. I think we now have
found that was overoptimistic. The right thing to do is to deprecate
l=, not make more mistakes.
This is, as usual, shamelessly wrong. We showed
I went through it. It's a very thorough piece of work.
So far I only have two comments.
Section 3.5, near the bottom of page 23:
Local- part MAY be drawn from a namespace that does not contain the
user's mailbox
I'd suggest changing that to
Local- part MAY be drawn from a namespace
Why isn't a signed 822.From sufficiently accurate sender information
from a provider who cares?
The who cares bit is a reputation system, you know.
I also suspect that my signing model is fairly typical of small
providers. I sign everything, and make no effort to validate stuff on
the From:
* DKIM is a really well developed standard for signing email
Right, but emphasize that the granularity is a signing domain -- it is
not and cannot be a way to attribute mail to individual people.
* Combined with ADSP=discardable it can filter email at ISP gateways without
too much fear of
Encouraging use of DKIM, and avoiding confusion between ADSP flaws
and DKIM flaws is a big part of the work at hand, I think. If it's
not, it should be.
Agreed. It would be nice to collect enough data about ADSP so we can
figure out whether my take on it or Mike's is closer to reality.
R's,
I'm trying to get the same goal by recommending adding some non-artisicly
specified form of a list: mlm.example display so its more evident to the
user without percentage hacks.
I must be missing something. What does this have to do with DKIM?
If this were important, why don't MUAs look for
If the original was
From: Joe Doe j...@discardable.example
and a recipient sees it as
From: Joe Doe joe%discardable.exam...@mlm.example
then he will still have a pretty clear idea that it originated from Joe
Doe, ...
Actually, in both cases, most MUAs will show:
From John Doe
It's the
I was going on a desireable assumption that a verifier would add a
Authenticated-Results header field and online/offline MUAs could
depend on this if it falls within the right domain or its domain is
accepted by a user.
You are aware, I hope, that nothing in an Authenticated-Results header
has
I have to say that this particular proposal is currently no more than
1/3 baked, since unless I've missed something, I don't see much effort
to work out failure and security models. For example:
OK, in the scenarios which follow, you is some MLM, and the proposition
is that the MLM might
But what you're saying seems antithetical to most of the document,
which goes to some lengths to describe ways that MLMs and DKIM can
co-operate better. So should we not bother?
Oh no. (That is. we shouldn't not bother.) There's plenty of good
stuff in your draft, but on reflection I think the
Comments? And if you agree, your rationales in either direction?
(I'll take Daniel's text at that link into account.)
Unless I misunderstand, this is a paper proposal that has never been
implemented that addresses a quite possibly purely hypothetical
problem.
There's nothing wrong with
In article 548b10a3a5fcf3025a4b5...@lewes.staff.uscs.susx.ac.uk you write:
However, if there's a need to trust the original sender, and you don't
quite trust the list to get that right for you, ...
It appears that we can discard this concern as counterfactual. I
asked how people sort their list
Let me try to explain. If the identity of the list contributor is of
any value to the receiver of an MLM-distributed message, ...
We're going in circles here.
Please see Steve A's recent message.
R's,
John
___
NOTE WELL: This list operates according
This assumes mail from MLMs is treated differently than other mail.
While individual users may (and probably do) treat it differently,
receivers of non- trivial scale don't and can't.
Sigh. Anyone who uses gmail would know that your assertion is just
plain wrong.
And in any event, even if your
I agree with most of Dave's suggestions, but as a niggle:
Upon DKIM and ADSP evaluation, a receiver may decide to reject a
message during an SMTP session. If this is done, use of an [SMTP]
DKIM and ADSP evaluation are not performed during an SMTP session, unless the
session is
And in any event, even if your assertion were true, so what? Our
working assumption is that receivers will use valid DKIM signatures to
whitelist mail from signers they like. How does it matter whether the
signer happened to be a related to a list?
If I'm a consumer of your list of domains
I went through -01 again.
Basically, it's fine. There's a few places where it says things that
are out of scope of DKIM. A signature either verifies or it doesn't,
and there's nothing inherently good or bad about that.
RFC 4871 carefully describes the way one verifies a signature, and
that
there are phishing attacks possible that work through lists but are
extremely unlikely to work when the message is part of a digest.
Could you give some examples of phishing attacks that work through
lists? Real ones you've seen would be much more helpful than
hypothetical ones.
The only
1 - 100 of 534 matches
Mail list logo
