On 27/Jun/11 23:38, Michael Deutschmann wrote:
* Put it in its own RFC *
I think there's room for a Minimum Quality of Forgery Supression BCP.
Such an RFC would outline a number of faults a message can have, and
declare that any of those faults mean the message MUST NOT be delivered
to
One final note from me, as I want to state my current position regarding
4871bis, with respect to Last Call.
As the receiving verifier has all the information to _reliably_ [0]
determine which combination(s) [1] of From [2] and DKIM-Signature
verifies correctly, it has the means to provide any
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Alessandro Vesely
Sent: Tuesday, June 28, 2011 12:13 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] spam filtering 101
+1, revising RFC 2505, whose date is in last
Folks,
I've been reviewing 4871bis for the IESG review on Thursday. I've got a
huge number of comments. Some of them (e.g., the first two below) are
quite trivial or simple issues that I expect you'd either have no issue
with or that I'm happy to ignore; some of them are clearly not trivial
