Dear Scott,
Signatures normally offer options not easily supported by
DKIM. One being use of a binary keys, rather than base64.
Indeed shorter keys were a mistake. What other mistakes
should be corrected? I can name a few.
Regards,
Douglas Otis
On 5/11/15 10:06 AM, Scott Kitterman wrote
to not be sloppy about
security. Especially when you don't know who to trust.
Regards,
Douglas Otis
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
to ascertain problem sources. Lack
of standardization due to an unfounded fear this reduces user privacy simply
misunderstood what is meant by the term opaque. What we have now is definitely
not better at preventing abuse or protecting privacy.
Regards,
Douglas Otis
relevant message format standards.
See Section 8.15 for additional discussion.
'---
Regards,
Douglas Otis
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
='.
Regards,
Douglas Otis
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
. This problem
is real.
Regards,
Douglas Otis
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
On 8/10/11 11:18 AM, Michael Deutschmann wrote:
On Mon, 8 Aug 2011, Douglas Otis wrote:
The concept behind the TPA scheme was to enable services on behalf of
senders that lack requisite staffing to support this level of policy
effort when using open-ended third-party services. The list
On 7/28/11 2:03 PM, Mark Delany wrote:
DKIM should be viewed as a Work-In-Progress still missing a viable
policy layer.
+1. But 5+ years WIP? :) It wasn't rocket science.
Well, 7+ years ago it was suggested that Domain policy is nascent
with the stated expectation that MARID would soon
On 7/27/11 12:13 AM, Michael Deutschmann wrote:
I have one comment to make which ties together both my stance on Otis'
doublefrom crusade, and some reforms I have argued for in ADSP.
Basically, at present the doublefrom trick is simply *unnecessary* for
someone trying to pass me a forged
On 7/22/11 7:09 AM, O'Reirdan, Michael wrote:
Chaps
I would like to bring to your attention and solicit comments on the
following draft.
http://tools.ietf.org/html//draft-oreirdan-rosenwald-ipv6mail-transition-00
Thanks
Mike O'Reirdan
Mike,
Indeed, abuse issues represent a challenge
On 7/12/11 12:02 PM, Charles Lindsey wrote:
Essentially, my concern is that an implementor reading this section should
be able to infer the nature of the particular attack I have described (the
one where the signer is the BadGuy himself using a throwaway domain),
including spotting how and why
8.15. Attacks Involving Extra Header Fields ...
,---
Agents that evaluate or apply DKIM output need to be aware that a DKIM
signer can sign messages that are malformed (e.g., violate [RFC5322],
such as by having multiple instances of a field that is only permitted
once), or that become malformed
On 7/7/11 10:09 AM, Pete Resnick wrote:
DKIM can only be deployed to mount a
variety of attacks if the recipient has already made the fatal mistake
of assuming that the existence of a cryptographically valid signature
*means* that the message is reliable and from a known good sender.
Strongly
On 7/7/11 3:21 PM, John Levine wrote:
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
On 7/6/11 3:30 PM, John R. Levine wrote:
When DKIM signatures serve as a basis for acceptance, ...
Since they don't, can we skip the rest of the screed?
In other words, when DKIM signatures serve a basis for acceptance, this
would be an issue? The statement they don't contradicts preceding
On 6/29/11 11:49 AM, Pete Resnick wrote:
On 6/29/11 11:20 AM, Charles Lindsey wrote:
I agree that 8.14 is poorly written (and it was even worse a while back).
However, there most certainly IS an attack here, which is NOT the same as
the related attack discussed in 8.15, and cannot be prevented
On 6/30/11 9:53 AM, Murray S. Kucherawy wrote:
-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
On 6/23/11 8:24 AM, John Levine wrote:
In article4e02ee24.2060...@gmail.com you write:
On 6/22/11 11:14 AM, Dave CROCKER wrote:
Folks,
The bottom line about Doug's note is that the working group extensively
considered the basic issue of multiple From: header fields and Doug is
raising
On 6/24/11 2:43 PM, Steve Atkins wrote:
On Jun 24, 2011, at 10:33 AM, Douglas Otis wrote:
Complaints from John, Dave, and Barry and others is likely and
understandably out of fatigue. They just want the process to be over.
We are now hearing there is a vital protocol layering principle
On 6/23/11 5:16 AM, Ian Eiloart wrote:
On 21 Jun 2011, at 19:47, Douglas Otis wrote:
Hi Rolf,
The general goal of DKIM was to establish a domain relationship as
a trust basis for acceptance. DKIM was also to allow incremental
deployment without requiring undefined additional filtering
On 6/23/11 2:52 PM, John R. Levine wrote:
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.
On 6/23/11 8:34 PM, John R. Levine wrote:
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
On 6/17/11 1:05 PM, Rolf E. Sonneveld wrote:
Dear all,
after some off-list conversation with Dave he suggested I might want to
send this to the list. I apologize in advance if this message does not
apply to you. I also apologize if you get this message twice, when you
are subscribed to both
On 5/22/11 10:38 PM, John R. Levine wrote:
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,
On 5/8/11 10:28 AM, Dave CROCKER wrote:
On 4/27/2011 2:21 AM, SM wrote:
I thought that the advancement of the specifications from Proposed to
Draft would not be too much of an effort as there are existing
implementations of RFC 4871. But then, this is the DKIM WG.
The effort is primarily
On 5/5/11 9:40 PM, Hector Santos wrote:
Dave CROCKER wrote:
I don't think this is correct. The signer creates and signs the i= value,
so it's not garbage,
By garbage, I mean not guaranteed to have any useful meaning.
So, I believe, it's essentially meaningless as far as the
The intended content of this ticket by Charles Lindsey, Rolf Sonneveld
and my self is as follows:
,---
We were asked by Barry to provide an agreed text to resolve the
multiple header problem, for consideration by the WG.
The attack arises when some header (typically From:) which is supposed
to
On 5/6/11 6:28 AM, Charles Lindsey wrote:
On Thu, 05 May 2011 21:24:00 +0100, Barry Leibabarryle...@computer.org
wrote:
Doug says...
This can *only* be achieved by some mandatory test within the Verifier.
Not at all; that's exactly Dave's point in discussing the difference
between the
On 5/4/11 10:01 AM, Dave CROCKER wrote:
Folks,
\
In terms of working group process, one line of criticism demands re-opening
(and, apparently, reversing) the work of the Update (RFC 5672). I haven't
seen
any working group consensus to do this nor any industry feedback indicating
this
is
On 5/5/11 1:24 PM, Barry Leiba wrote:
Dave says...
In terms of working group process, one line of criticism demands
re-opening
(and, apparently, reversing) the work of the Update (RFC 5672). I
haven't seen
any working group consensus to do this nor any industry feedback
indicating this
On 5/5/11 1:34 PM, Michael Thomas wrote:
On 05/04/2011 08:34 PM, Murray S. Kucherawy wrote:
Technical: The AUID is an unvetted value. The local-part and the subdomain
could be garbage. It's inappropriate for a security protocol to return a
possibly false value in the context of saying
On 5/3/11 4:25 PM, Murray S. Kucherawy wrote:
Why does the output of DKIM need to include something when the
consumer of that output already has that information?
Because a consumer should/must not have to re-do the work of the DKIM
verifier. Or put it differently: a consumer is just consuming
On 5/3/11 4:25 PM, Murray S. Kucherawy wrote:
I might even go so far as to say returning that From: field is dangerous
since it is not confirmed by anything, so DKIM (which is an authentication
protocol) returning data that can't be validated, even if it was signed, is
quite possibly asking
On 4/30/11 10:37 PM, Murray S. Kucherawy wrote:
-Original Message- From: Hector Santos
[mailto:hsan...@isdg.net] Sent: Saturday, April 30, 2011 9:10 PM
To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re:
[ietf-dkim] Output summary - proposing ODID Originating Domain
On 4/28/11 12:00 PM, Rolf E. Sonneveld wrote:
Right. I strongly believe in the layered approach. However, that's
exactly the problem here. Like with IP and SMTP and any layered
application, the upper layer is dependent on what the lower layer
provides it with. If DKIM only enforces:
d= and
On 4/27/11 2:21 AM, SM wrote:
Hi Doug, At 18:43 26-04-2011, Douglas Otis wrote:
Not validating input creates a bigger mess when used in conjunction
with RFC5336bis. As such, it seems unfair for the DKIM WG
operating within the Security area to close and then hand a mess
over
Barry,
Ticket #17 was listed as a duplicate of Ticket #4
http://trac.tools.ietf.org/wg/dkim/trac/ticket/17
This is not correct!
The result of Ticket #4 was a change that simply said:
,---
Internationalized domain names MUST be converted as described in Section
2.3 of [RFC5890] to A-Labels
'---
Sorry for the repeated message, but the wrong subject line was used.
Barry,
Ticket #17 was listed as a duplicate of Ticket #4
http://trac.tools.ietf.org/wg/dkim/trac/ticket/17
This is not correct!
The result of Ticket #4 was a change that simply said:
,---
Internationalized domain names MUST
On 4/25/11 9:18 PM, Murray S. Kucherawy wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Douglas Otis
Sent: Monday, April 25, 2011 6:33 PM
To: ietf-dkim@mipassoc.org; Barry Leiba; Pete Resnick
Subject: [ietf-dkim
On 4/25/11 9:29 PM, Dave CROCKER wrote:
On 4/25/2011 9:18 PM, Murray S. Kucherawy wrote:
Double listing in the h= tag can not fully mitigate risks
related to appended header fields when messages are signed by a
different domain than the domain found in the appended From
header field.
On 4/26/11 2:03 PM, Dave CROCKER wrote:
Detecting Fake A-Label use is essential for the safe introduction of UTF-8
throughout email
DKIM does not have the task of validating input. In addition, the nature of
DKIM's crypto algorithms provides quite a bit of validity checking inherently.
Although DKIM is reviewed within IETF's security area, input validation
by DKIM remains dangerously neglected. References of RFC5890 rather
than RFC3490 and removal of the ToASCII function once again neglects
proper input validation. Detecting Fake A-Label use is essential for
safe
Although DKIM is reviewed within IETF's security area, input validation
by DKIM remains dangerously neglected. DKIM's Introduction indicates it
can be implemented independent of clients. As such, few assumptions are
safe in how users become aware of DKIM's intended protections or
acceptance
On 4/20/11 5:02 PM, John R. Levine wrote:
Internationalized domain names MUST be encoded as Non-Reserved LDH,
A-Labels as described in RFC5891, or equivalent U-Labels.
Repeating this bad idea doesn't make it a good idea,
Besides being a bad idea on its own merits, this would without question
On 4/21/11 5:25 AM, John R. Levine wrote:
Use of A-labels within header fields supporting UTF-8 is a bad idea.
Since DKIM is defined on RFC 5322 messages, and 5322 is ASCII-only, no
header fields in a compliant message can contain UTF-8. I don't know
why you keep repeating this uttetly
On 4/20/11 7:09 AM, John R. Levine wrote:
Is there anything that actually needs to be done with a UTF-8 header that
is not covered already in our DKIm spec.?
No, it's fine, so long as we make my proposed changes that clarify that
the bits of domain names in the DKIM-Signature: header (d= i=
On 4/20/11 1:25 PM, J.D. Falk wrote:
On Apr 20, 2011, at 4:36,bill.ox...@cox.com wrote:
Indeed lack of support for 3rd party signers was where I gave up any
interest at all in adsp
As I remember it, there was (or appeared to be) consensus to get ADSP out
there for testing by the entities
On 4/20/11 2:50 PM, Murray S. Kucherawy wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org
[mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Douglas Otis
Sent: Wednesday, April 20, 2011 2:40 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] ADSP stats
On 4/15/11 7:25 PM, John R. Levine wrote:
Instead, conversion to A-label form, or any other special encoding
required by a particular name-lookup protocol, should be done only by
an entity that knows which protocol will be used (e.g., the DNS
resolver, or getaddrinfo() upon deciding to pass
On 4/19/11 2:37 PM, Murray S. Kucherawy wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Charles Lindsey
Sent: Tuesday, April 19, 2011 12:56 PM
To: DKIM
Subject: [ietf-dkim] Issue: Repeated headers
Yes indeed. We
On 4/19/11 3:35 PM, John R. Levine wrote:
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
On 4/15/11 8:59 PM, Michael Deutschmann wrote:
On Fri, 15 Apr 2011, Douglas Otis wrote:
In addition, verifiers MUST
ensure the presence of multiple singleton originating header fields
do not provide a valid signature result.
---
Not including this additional requirement removes recipient
On 4/18/11 12:33 PM, Murray S. Kucherawy wrote:
This working group spent a huge amount of blood, sweat and tears working on
attempts to create a viable policy layer, and after all that, ADSP is what we
managed to get consensus to do. Lots of other alternatives have been
proposed, and none
On 4/13/11 12:23 PM, Dave CROCKER wrote:
On 4/13/2011 12:21 PM, John R. Levine wrote:
i'm also tempted to suggest using months in a different language,
with enero or
Januari...
If you're going to change it, change it to 一月 or يناير
not after i just got done trying to avoid unicode
http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-06#section-3.8
,---
DKIM's design is predicated on valid input. Therefore, signers and
verifiers SHOULD take reasonable steps to ensure that the messages
they are processing are valid according to [RFC5322
http://tools.ietf.org/html/rfc5322],
On 4/11/11 2:06 AM, Charles Lindsey wrote:
I think you may have missed the point of my 'bob' example. It would have
been clearer if I had said:
3. From = al...@example.com i=mal...@example.com d=example.com.
Where mallet is some disgruntled example.com employee posing as Alice. A
human
On 4/7/11 10:08 AM, Murray S. Kucherawy wrote:
2) Can we use i= for a purpose of reputation as a) it's meaning is
loosely defined, b) it is there already (cf (1) ) c) it has been used
by some to differentiate different emails in the same domain.
You could, if you know that the use of i= by
On 4/6/11 3:06 PM, John Levine wrote:
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
On 4/4/11 7:47 AM, John R. Levine wrote:
... kludges to work around short term deployment problems are rarely
a good way to do long term standards development. The problems go
away, but the kludges don't.
Why are A and records used to locate mail servers and not limit
discovery to
On 4/4/11 1:59 PM, Steve Atkins wrote:
On Apr 4, 2011, at 1:21 PM, Franck Martin wrote
I think you are thinking it as only a DNS issue.
But creating a sub-domain, means that the from needs to match too, therefore
you may need to remap all your corporate email addresses from j...@iecc.com
On 4/1/11 2:08 PM, Murray S. Kucherawy wrote:
In our conference call with Jim, Dave and I are left with three things
that need discussion in the working group before we request a working
group last call on it.
The first, and biggest, is the removal of “i=” that Jim has proposed
On 3/19/11 5:17 AM, Barry Leiba wrote:
With Stephen's becoming an Area Director (replacing Tim Polk), Stephen
and Sean have reshuffled the working group responsibilities, thus:
Sean: dkim, emu, isms, msec, pkix, tls, ltans, ipsecme
Stephen: abfab, dane, hokey, kitten, krb, nea
As you see,
On 3/3/11 4:07 AM, Mark Martinec wrote:
On Thursday March 3 2011 12:18:45 Charles Lindsey wrote:
Having just had a deluge of bogus messages from Twitter, all allegedly
DKIM-signed, I think I need a working DKIM checker (my ISP has not
implemented DKIM ckecking so far).
I have not the time to
On 2/22/11 4:08 AM, Alessandro Vesely wrote:
On 22/Feb/11 00:31, Douglas Otis wrote:
Any message containing multiple orig-date, from, sender, reply-to,
to, cc, message-id, in-reply-to, and subject header fields will not
produce a valid signature. See Section 5.3.
The current Section 5.3 says
On 2/16/11 9:18 AM, Dave CROCKER wrote:
Folks,
A new version of rfc4871 has just been posted as an I-D. A diff is
attached.
The draft is available at:
http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-03
This version does NOT contain text that resolves two outstanding
issues:
On 1/13/11 9:10 AM, Dave CROCKER wrote:
Folks,
Summary of the reactions posted so far...[1]
Some of the postings asked questions or expressed confusion about some
procedural or technical or wg scope fact issues that have already been
answered; so they are not covered here. Also, there
On 11/24/10 9:01 AM, Dave CROCKER wrote:
On 11/23/2010 3:14 AM, Ian Eiloart wrote:
Actually, they're complementary. In places where DKIM fails
(mailing lists rewriting messages), SPF can succeed. And in places
where SPF fails (message forwarding), DKIM can succeed.
This assertion of
On 11/22/10 9:25 AM, Steve Atkins wrote:
...
But if you're trying to stop mail that's being sent by a bad
actor... give up on this approach, as it's trivial to add a fake
DKIM header that will not authenticate.
Also, it may discard quite a bit
of legitimate email, if any of your users
rfc4871bis-02 Introduction:
,---
...
DKIM:
o is compatible with the existing email infrastructure and
transparent to the fullest extent possible;
o requires minimal new infrastructure;
o can be implemented independently of clients in order to reduce
deployment time;
o
Append to Section 6 Verifier Actions:
It is not reasonable to assume a message is in compliance with RFC5322.
To mitigate trivial exploitation of trust established by DKIM
signatures, messages having multiple header fields for orig-date,
from, sender, reply-to, to, cc, message-id,
On 11/3/10 6:28 AM, Alessandro Vesely wrote:
On 02/Nov/10 22:58, Douglas Otis wrote:
On 11/2/10 11:47 AM, Alessandro Vesely wrote:
If big-bank.com asserts a restrictive policy, the relevant author
address should make that message fail ADSP verification, since no
author domain signature
On 11/2/10 11:47 AM, Alessandro Vesely wrote:
On 01/Nov/10 22:56, Douglas Otis wrote:
If big-bank.com asserts a restrictive policy, the relevant author
address should make that message fail ADSP verification, since no
author domain signature can be found. Apparently, RFC 5617 already
On 10/30/10 3:05 AM, Alessandro Vesely wrote:
On 28/Oct/10 03:36, Douglas Otis wrote:
I'll repeat the example given previously. The multiple listing of a
header in the h= parameter can not mitigate exploitation of DKIM PASS
results where a valuable domain is prefixed to that of large domain
On 10/27/10 8:53 PM, Hector Santos wrote:
The lack of focus for 1st party domain protection is what allowed this
issue to fall through the crack. We tried our best to make DKIM a
pure signing mechanism with an open ended implicit policy of
unrestricted resigners, remolding the specs with out
On 10/25/10 9:36 PM, Murray S. Kucherawy wrote:
On Monday, October 25, 2010 2:48 PM, Douglas Otis wrote:
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
On 10/25/10 2:12 PM, Steve Atkins wrote:
On Oct 25, 2010, at 1:58 PM, Murray S. Kucherawy wrote:
Isn't the more interesting attack a signature from some throwaway domain
that covered a matching From: but also contained a From: indicating some
high-value phish target?
Not really, no. Signing
On 10/23/10 12:25 PM, Barry Leiba wrote:
On Fri, Oct 22, 2010 at 10:13 PM, Hector Santoshsan...@isdg.net wrote:
John Levine wrote:
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
On 10/24/10 9:05 PM, Murray S. Kucherawy wrote:
Here’s my proposal for a section in Security Considerations to talk
about the malformation issues that have been discussed on the list.
This is an addition to -02 directly and does not continue from any of
the other proposals.
8.14
On 10/20/10 10:55 AM, Murray S. Kucherawy wrote:
I think a lot of this discussion conflates protocol specification
with implementation. I'm focused on the former. I maintain that
including wording intimating that a DKIM implementation is
non-compliant if it fails to do mail format
On 10/20/10 8:10 AM, Ian Eiloart wrote:
--On 19 October 2010 11:35:53 -0400 John R. Levine jo...@iecc.com
wrote:
True, but there already are UI designs that indicate when a From
header is DKIM verified.
So you're saying that all a spammer has to do is to put on a
throwaway domain's
On 10/20/10 3:19 PM, Murray S. Kucherawy wrote:
[]
I totally agree that that's an important distinction to make, document,
highlight and shout from the rooftops. But... Does it *have* to use RFC2119
normative language?
Here's maybe a better way to frame the question: Should we empower
On 10/19/10 1:45 PM, Dave CROCKER wrote:
On 10/19/2010 1:33 PM, John R. Levine wrote:
Re Security Considerations, it's better than nothing,
Not necessarily.
The current issue is part of a much larger one. We will not be
dealing with that larger set of security details because it is out
On 10/18/10 6:49 AM, Wietse Venema wrote:
Mark Delany:
My problem is that if some valuable domain like paypal sends me a
bunch of bits that I or my MUA or my MTA ties to paypal.com then the
end goal of DKIM is, IMO, that those bunch of bits I see are the
ones that paypal sent. No more, no
On 10/18/10 12:18 PM, Murray S. Kucherawy wrote:
This is no more presumptuous than expecting that MUAs will adapt
to consume the output of DKIM as it stands now.
In another message I indicated that I don't presume either, but
assert that there's no middle ground; they will or they
On 10/18/10 4:15 PM, Murray S. Kucherawy wrote:
On Monday, October 18, 2010 3:33 PM, Douglas Otis wrote:
Should the charter of a security related protocol need to
anticipate minor modifications to a verification process, that
appears essential for ensuring a DKIM signature
On 10/15/10 4:50 PM, Murray S. Kucherawy wrote:
On Friday, October 15, 2010 2:30 PM, Douglas Otis wrote:
Citing a layer violation makes little sense. With DKIM, the message
body does not stand on its own. DKIM binds elements related to the
RFC5322 header fields with the message body
On 10/15/10 1:51 PM, MH Michael Hammer (5304) wrote:
On Friday, October 15, 2010 11:59 AM, Bill Oxley wrote: To:
dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re:
[ietf-dkim] detecting header mutations after signing
Well a broken signature is morally equivalent to unsigned so
On 10/14/10 6:54 AM, John R. Levine wrote:
Another potential option is to remove g= entirely:
I'd like to encourage our considering this strongly, for two reasons:
I agree, g= seems to me to be a vestige of the confusion between i=
and d= identity.
If we do, it's probably a good idea to
On 10/15/10 10:58 AM, Barry Leiba wrote:
On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos hsan...@isdg.net
wrote:
Murray S. Kucherawy wrote:
I appreciate the desire to put more information in there to
help, but we really can't be writing a tutorial on managing DNS
records.
+1.
On 10/15/10 8:40 AM, Mark Delany wrote:
h=from:from:subject:subject:to:to:cc:cc:mime-version:mime-version:list-id:list-id?
Yes, it does. The only question is to devise normative statements
correctly, e.g. MUST duplicate From, SHOULD duplicate the rest.
This is _not_ a kludge. It is how
On 10/12/10 12:01 PM, Dave CROCKER wrote:
On 10/12/2010 11:21 AM, Murray S. Kucherawy wrote:
... I furthermore submit that we are
compelled to describe the known attack, as that's precisely what
we are supposed to include in Security Considerations.
We should keep in mind that DKIM's
On 10/5/10 8:45 AM, Dave CROCKER wrote:
At a deeper level, there is a continuing problem with casting DKIM as a
mechanism to protect a message. That's something that OpenPGP and S/Mime
do;
it's not something DKIM does. DKIM merely tries to do enough to ensure that
the
d= is valid, to
On 10/4/10 11:00 AM, Jeff Macdonald wrote:
On Fri, Oct 1, 2010 at 5:40 PM, MH Michael Hammer (5304)
mham...@ag.com wrote:
To pick on you a little, if a domain owner uses your approach to
authorize signing by an ESP1, what is the stable identifier we are
talking about? Is it specific to
On 10/2/10 11:13 PM, Michael Deutschmann wrote:
On Tue, 28 Sep 2010, Steve Atkins wrote:
Putting it in the List-Unsubscribe header that's not displayed
to recipients is pretty much equivalent to putting it in the X-Bamboozle
header that's not displayed to recipients when it comes to
On 10/3/10 8:15 AM, Hector Santos wrote:
John R. Levine wrote:
I'm really having trouble understanding what problem you're trying to
solve here. Could you describe it in under 100 words?
Provide a restrictive acceptance policy for Author Domains so they are
able to allow domain specific
On 10/1/10 1:19 PM, Jeff Macdonald wrote:
On Fri, Oct 1, 2010 at 1:05 PM, Dave CROCKERd...@dcrocker.net wrote:
Oh. Sorry. I didn't get that. It's an interesting idea but I'd want to
hear
it explored quite a lot, since the idea of value is pretty broad. For
example,
if 3rd party
On 9/30/10 2:31 PM, Rolf E. Sonneveld wrote:
On 09/30/2010 11:16 PM, Murray S. Kucherawy wrote:
One of the things our stats project is picking up is the names of
header fields that are modified or removed in transit causing
verification failures.
The current leader is
On 9/30/10 8:15 AM, Steve Atkins wrote:
On Sep 30, 2010, at 4:05 AM, Charles Lindsey wrote:
On Wed, 29 Sep 2010 18:52:01 +0100, John Levine jo...@iecc.com
wrote:
I was thinking of the various proposals to rewrite From:
addresses, to outlaw subject tags and message footers, and
On 9/29/10 11:15 AM, Murray S. Kucherawy wrote:
On Tuesday, September 28, 2010 7:01 PM, Douglas Otis wrote:
On 9/28/10 3:27 PM, Murray S. Kucherawy wrote:
The TPA-Label draft offers additional ADSP assertions having
semantics intended to support _existing_ mailing-list and
third
On 9/27/10 9:47 PM, Murray S. Kucherawy wrote:
On Monday, September 27, 2010 4:19 PM, Douglas Otis wrote:
TPA-Label involves ADSP being discussed on the dkim list.
Agreed, but not having a defense against trivial exploitation of
an authorization is not better. When a defensive
1 - 100 of 1332 matches
Mail list logo
