Alessandro Vesely wrote:
On 08/May/11 19:13, Dave CROCKER wrote:
In practical terms for the current world, what is the likelihood that
a signer has any information about the 'type' of an email address?
How can a signer possibly know that an addressee is a mailing list???
Currently, it
On May 9, 2011, at 5:14 PM, John Levine wrote:
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.
Agreed (which is a -1 to removal.)
I would also really like to have a better idea of how people are
using it,
On May 8, 2011, at 11:16 PM, Murray S. Kucherawy wrote:
-Original Message-
From: Franck Martin [mailto:fmar...@linkedin.com]
Sent: Sunday, May 08, 2011 9:12 PM
To: Murray S. Kucherawy; ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] I-D ACTION:draft-ietf-dkim-mailinglists-08.txt
On May 6, 2011, at 11:21 AM, Murray S. Kucherawy wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of John Levine
Sent: Friday, May 06, 2011 11:15 AM
To: ietf-dkim@mipassoc.org
Cc: barryle...@computer.org
Subject: Re:
On Tue, 10 May 2011 00:02:36 +0100, Barry Leiba barryle...@computer.org
wrote:
That was quick. I believe we already have enough objections to say
that we do NOT have rough consensus for deprecating l= at this time.
I'll close the issue in the tracker (issue #26), and we will leave it
as it
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Keys Identified Mail Working Group of
the IETF.
Title : DKIM And Mailing Lists
Author(s) : Murray S. Kucherawy
Filename:
The DKIM Working Group requests the publication of
draft-ietf-dkim-mailinglists-10 as a BCP. Alternatively, this document
might be suitable for Pete's Applicability Statement experiment, at
the Proposed Standard level.
Please see the attached PROTO writeup.
Barry, DKIM working group chair
PROTO
To be concise, here are the proposed changes. The group's preferred
change, #1, is this:
1. Add:
---
6.1.n. Validate Multiple Header Field Occurrences
Through inadvertence or malice, a message may be received having
multiple occurrences of single only header fields per [RFC5322]. To
We've had a bit of discussion in this thread (and elsewhere) about
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
Murray, will you please finish folding in last-call comments, and
submit the draft for 4871bis-10 ?
I will do my final review on Wednesday, and send it to the ADs.
Barry, as chair
___
NOTE WELL: This list operates according to
10 matches
Mail list logo
