Folks,
G'day.
I've now caught up on the list activity and am sending my combined
comments in a single posting, especially since I think there's really a
single organizing issue that's being missed...
On 6/13/2014 12:46 AM, Stephen J. Turnbull wrote:
Well, for Author Domains publishing
I don't know anyone who's checked whether DKIM validators verify the
version number, but if it's an issue, there aren't that many widely
used DKIM engines so it wouldn't be hard to check.
Just FYI, libdkim which all our products use does check the v= and if
it's not v=1 verification fails
On 6/15/2014 8:01 AM, Murray S. Kucherawy wrote:
How about a new tag, shf= (special header fields). Ignored by legacy
verifiers, as required; otherwise, contains a colon-separated list of
fields that get special handling by verifiers. Special handling
depends on the header field and would
Murray S. Kucherawy writes:
How about a new tag, shf= (special header fields). Ignored by legacy
verifiers, as required; otherwise, contains a colon-separated list of
fields that get special handling by verifiers. Special handling depends
on the header field and would need to be
On Sat, Jun 14, 2014 at 11:53 PM, Stephen J. Turnbull step...@xemacs.org
wrote:
How about a new tag, shf= (special header fields). Ignored by legacy
verifiers, as required; otherwise, contains a colon-separated list of
fields that get special handling by verifiers. Special handling
When DKIM-Delegate is used, there are two, valid signatures for the same
domain. One is 'stronger'.
The scenario being discussed is for a recipient who gets both signatures
when they are valid, but who does not know about DKIM-Delegate. They
only know about DKIM.
That's not a problem -- if it
If a signature has an rsf= tag, verifiers ignore it unless there's a
matching signature from a domain the rsf= points to.
This is not backward compatible, since verifiers that don't understand
rsf= will often get the wrong answer, so it needs a version bump.
Can't both the version
If a signature has an rsf= tag, verifiers ignore it unless there's a
matching signature from a domain the rsf= points to.
This is not backward compatible, since verifiers that don't understand
rsf= will often get the wrong answer, so it needs a version bump.
Can't both the
On Jun 14, 2014, at 3:35 PM, ned+dm...@mrochek.com wrote:
If a signature has an rsf= tag, verifiers ignore it unless there's a
matching signature from a domain the rsf= points to.
This is not backward compatible, since verifiers that don't understand
rsf= will often get the wrong answer,
On Sat, Jun 14, 2014 at 12:35 PM, ned+dm...@mrochek.com wrote:
Yes, you could do the equivalent of the version bump by changing the
name of the header, but I don't see the point.
If you're going to bump the version, you need to use the opportunity to
solve the more general underlying
Elizabeth Zwicky writes:
No, I mean to say that never stopped does not mean never slowed
down, it means never stopped.
OK. I'll remember that.
In any case, now I wonder what they're really trying to do. They can
check for p=reject without sending *any* mail. (I know, you're not
in a
On Jun 13, 2014, at 7:18 AM, Stephen J. Turnbull step...@xemacs.org wrote:
In any case, now I wonder what they're really trying to do. They can
check for p=reject without sending *any* mail.
That's not an integration test. It's all automated. The answer you want is,
Can I make money now?
John Sweet writes:
That's not an integration test. It's all automated. The answer you
want is, Can I make money now? This is how you get the
answer. The DMARC record is only part of the story, whether
recipients act on it or not is just as important.
Well, for Author Domains publishing
On Wed, Jun 11, 2014 at 10:39 PM, Dave Crocker dcroc...@gmail.com wrote:
The irony of your suggestion is that it requires having 'unupgraded'
software reliably use the version number, given that they haven't needed
to do that before either...
Section 6.1.1 of DKIM makes it a MUST that
On 6/12/2014 8:37 AM, Stephen J. Turnbull wrote:
Dave Crocker writes:
Hence this is merely the case of two, competing signatures and deciding
which to choose.
An invalid DKIM signature should not be treated differently from the
absence of that signature.
I wasn't referring to any
On 6/12/2014 8:40 AM, Murray S. Kucherawy wrote:
On Wed, Jun 11, 2014 at 10:39 PM, Dave Crocker dcroc...@gmail.com
mailto:dcroc...@gmail.com wrote:
The irony of your suggestion is that it requires having 'unupgraded'
software reliably use the version number, given that they haven't
Answering four messages at once:
Someone sends off a message to a mailing list with the two DKIM
signatures and DKIM-Delegate. Someone else, perhaps a list
subscriber, notes that the weaker signature doesn't cover the body, so
he replaces the body with nose enlargement spam and blasts it
There is nothing about DKIM-Delegate that changes DKIM.
We disagree.
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.
___
dmarc mailing list
dmarc@ietf.org
Dave Crocker writes:
The scenario being discussed is for a recipient who gets both signatures
when they are valid, but who does not know about DKIM-Delegate.
I didn't understand that from previous posts. At least Hector seems
to be concerned (though not exclusively so) with the case I
On 6/12/14, 3:10 AM, Stephen J. Turnbull step...@xemacs.org wrote:
John R Levine writes:
For this application I don't see x= as much protection. If a bad guy
subscribes to the list or gets messages via something like gmane, he
can do the mutate and spam in close to real time.
Is this
DKIM-Delegate does not need or use any externally-maintained list.
please, solve this spoofing example:
1. so, a sender sends DKIM-D with every email, regardless whether
it is meant for a mailing list or not, cause they maintain no
whitelist to make a difference,
2. sender sends an
Elizabeth Zwicky writes:
I did not say that the levels were the same; I said the attackers
have not gone away. They are not at high volume, but they're sure
sitting there checking to see whether or not it's working.
What you said, exactly, is
But I do, in fact, have data, and that data
On Thu, Jun 12, 2014 at 4:05 PM, Stephen J. Turnbull step...@xemacs.org
wrote:
Can't both the version bump issue and the token signature issue be
ameliorated by incorporating the token signature in the DKIM-Delegate
field?
There's a protocol collision on the t= tag which would need to be
Murray S. Kucherawy writes:
Interesting. So DKIM-Delegate is syntactically the same as DKIM-Signature,
but with augmented semantics? Or did you have something else in mind?
That's what I had in mind. But the semantics are not merely
augmented, they're conceptually different.
On 6/12/14, 3:59 PM, Stephen J. Turnbull step...@xemacs.org wrote:
Elizabeth Zwicky writes:
I did not say that the levels were the same; I said the attackers
have not gone away. They are not at high volume, but they're sure
sitting there checking to see whether or not it's working.
What
On Wed, Jun 11, 2014 at 7:15 AM, John Levine jo...@taugh.com wrote:
Right. So if you don't want people using unforwarded weak signatures
for reputation management, you need to put something into them so that
old clients don't accept them as signatures and ignore the t= tag.
Either call them
On 6/11/2014 4:58 PM, Murray S. Kucherawy wrote:
One thing that is missing (and there's a placeholder for it) is
examples so you can see how it works. I'll make sure that's there for
-01.
Examples are good. Can we work it out here, a software walkthru?
Save some drafting time.
The
On Wed, Jun 11, 2014 at 7:49 PM, Hector Santos hsan...@isdg.net wrote:
On 6/11/2014 4:58 PM, Murray S. Kucherawy wrote:
One thing that is missing (and there's a placeholder for it) is
examples so you can see how it works. I'll make sure that's there for
-01.
Examples are good. Can we
On 6/12/2014 12:22 AM, John Levine wrote:
One could make an argument that it's not technically
a semantic change to DKIM (indeed, Dave just did), but in practical
terms, it is likely to interact poorly with existing unupgraded
software, so I'd want a version bump so that the old software
- Original Message -
From: Dave Crocker dcroc...@gmail.com
To: Murray S. Kucherawy superu...@gmail.com, Franck Martin
fra...@peachymango.org
Cc: dmarc@ietf.org
Sent: Tuesday, June 10, 2014 4:06:13 PM
Subject: Re: [dmarc-ietf] Fwd: New Version Notification for
draft-kucherawy-dkim
On Tue, Jun 10, 2014 at 7:13 AM, Franck Martin fra...@peachymango.org
wrote:
--
On Tue, Jun 10, 2014 at 6:58 AM, Franck Martin fra...@peachymango.org
wrote:
--
On Mon, Jun 9, 2014 at 11:52 PM, Franck Martin fra...@peachymango.org
On 6/10/2014 4:19 PM, Murray S. Kucherawy wrote:
Yes but are you assuming you only put the weak DKIM signature, when
you specifically know you are emailing a mailing list?
Or what about a receiver which is not a mailing list? You are just
allowing better replay of the
Murray S. Kucherawy writes:
It would require MLM to not drop DKIM headers... Still some
configuration on MLM side, but less in the way messages are
modified
That's a much less visible and thus probably more tolerable change
for MLM operators.
Mailman added an *optional*
On Sat 07/Jun/2014 12:43:57 +0200 Dave Crocker wrote:
I've been stewing on this idea for awhile and Murray pressed to get it
into writing, adding his usual, significant enhancements to the original
concept. We've gone a couple of rounds before releasing it, but it's
still nascent enough to
Hi Alessandro,
On Tue, Jun 10, 2014 at 8:14 AM, Alessandro Vesely ves...@tana.it wrote:
First, weak signatures which are not part of a chain should be ignored
by verifiers. An authentication chain can be defined as a set of
valid DKIM signatures and possibly an SPF authentication of
Stephen,
Thanks for the comments...
On 6/7/2014 8:08 PM, Stephen J. Turnbull wrote:
Two nits to pick. First, I'd like a whole (sub)section (containing
approximately one sentence :-) for Mediator responsibilities, even if
it's redundant with step 4 of the specification. Maybe a subsection
36 matches
Mail list logo
