On 06/May/11 20:37, Murray S. Kucherawy wrote:
Verifiers SHOULD ignore those signatures that produce a PERMFAIL
result (see Section 7.1), acting as though they were not present
in the message. ...
s/Verifiers SHOULD ignore/Identity assessors SHOULD ignore/
(and probably in other
It would have been nice to get this *before* working group last call
ended, or even before it started.
Murray, use your judgment on how to handle these, and we can get other
input on any that aren't straighforward.
Barry, as chair
On Sat, May 7, 2011 at 12:31 AM, Franck Martin
So if we wish to discourage l= useful, some of these text needs to
be reworded, like this one in section 3.5 [...]
I don't think the proposed text adds or clarifies anything that isn't already
there.
The semantics and use of l= are pretty well defined already.
I agree.
Barry, as
Barry Leiba wrote:
So if we wish to discourage l= useful, some of these text needs to
be reworded, like this one in section 3.5 [...]
I don't think the proposed text adds or clarifies anything
that isn't already there. �The semantics and use of l= are
pretty well defined already.
I
On 06/May/11 21:09, John R. Levine wrote:
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.
We are spending an awful amount of time on this l= issue, whether it should
be pulled, keep it and explaining how bad it is and discourage usage.
Agreed. I would like to deprecate it. But we don't have consensus
for going that far, and I think we're too late in the process to get
ourselves
Alessandro Vesely wrote:
On 06/May/11 21:09, John R. Levine wrote:
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
Volume tends to hide many important data points at the domain level.
Many times its just 1-2 domains (and their implementation) that are
showing how specs are being read/used.
My view in reading this complex document, many parts has become
sparse with its technical information. For the
On May 6, 2011, at 12:09 PM, John R. Levine wrote:
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
Issued in behalf of myself, Doug Otis and Rolf Sonneveld
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 appear once in fact appears twice. DKIM is
Charles sent this message without noting that Doug had already done
it. Please ignore this thread, and reply over on the other one.
Barry, as chair
On Sat, May 7, 2011 at 12:07 PM, Charles Lindsey c...@clerew.man.ac.uk wrote:
Issued in behalf of myself, Doug Otis and Rolf Sonneveld
We were
Barry Leiba wrote:
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
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 to the Applications
area EAI WG.
I thought that
13 matches
Mail list logo
