Grown up?
Stephen,
I don't think the whatever the STRAWPOLL was based on, it was VERY clear.
Going back, I can now see that it appears this was for the REQUIREMENTS
not for a SSP proposal itself.
The issue came about MUST NOT REQUIRE THAT SSP LOOKUP BE FIRST.
We debated this back and forth as well and it was made clear that
requirement does not MEAN proposals can not include such logic.
It does not SAY that a "SSP" proposal MUST NOT include a NOMAIL provision.
You are making it sound that it MUST NOT include a NOMAIL provision
which is 100% uncategorily wrong.
And now it is clear the issue was not poised correctly. Based on your
footnotes below, the question was brought up because some one felt
(incorrectly) that it was a specific form of "strict."
5.3 (2): IIRC we've identified "never send mail" as a special
case of "strict", and then just not sending mail, let
alone signing it. IMO you can delete this point.
if this is basis of the issue, it was INCORRECTLY though out.
There is no relationship with STRICT and NOMAIL. STRICT is related to
exclusive SIGNING or NO SIGNING which is different than NO MAIL.
The point is simple:
It doesn't make sense to REMOVE a NOMAIL policy. If a domain is based
forged with fake signatures, why should a VERIFIER be left with the
overhead of processing FAILED signature without any recourse of simply
DELETING this MAIL?
If the DOMAIN says, there SHOULD BE NO MAIL based on this DOMAIN, then
that is a CLEAR indicator of abuse which the verifier should delete. It
protects the verifier and it protects the domain.
We can't say NO SIGNATURE is equivalent to NO MAIL, but that is not
enough to handle this type of abusive mail.
If I receive an email with an domain such as:
secured.cs.tcd.de
and it is NOT signed, the DOMAIN can clearly TELL me whether this is
expected or not:
1 - This message MUST NEVER be signed
2 - This message MUST ALWAYS be signed
3 - This message MAY be signed
4 - This messages MUST never have secure.cs.tcd.de because
we DON'T send mail with this this domain.
With 1 and 3, the message is acceptable, with 2 and 4, I can mark this
message is bad or maybe get rid of this junk.
The #4 is important because this is a HIGH POTENTIAL transaction once
domains begin to turn on there DKIM system. There will be many currently
exploited domains that will come in with no signatures and unless they
all do #2, #4 is the only way to cleanly with NO FALSE positives, to get
rid of this abuse.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Stephen Farrell wrote:
Stephen Farrell wrote:
Hector,
Tomorrow I'll dig through the archive and find the reference
for where we agreed that the "nomail" requirement text that was
previously in the ssp-reqs draft would be excised.
If someone in an earlier TZ wants to do that in the meantime,
you'll have my thanks,
No volunteers eh;-)
So I went back in time and found:
Issue 1365 [1] included a mention that we could/shoud
delete the "never send mail" item.
That was raised by Eric on the list [2] in February and
dicussed at length.
Following that discussion I started a strawpoll [3] that
resulted in a 2:1 ratio [4] in favour of deprecating the
feature in SSP.
That's all nice and clear so "nomail" is out of scope, as
the WG agreed, even if not overwhelmingly. It seems like
all of the people who wanted to keep the feature then still
do, and I've not noticed anyone changing their mind. So,
there's no reason to reopen this that I can see.
So let's be grown-ups and move on,
Stephen.
[1] https://rt.psg.com/Ticket/Display.html?id=1365
[2] http://mipassoc.org/pipermail/ietf-dkim/2007q1/007139.html
[3] http://mipassoc.org/pipermail/ietf-dkim/2007q1/007185.html
[4] http://mipassoc.org/pipermail/ietf-dkim/2007q1/007254.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html