Hector,
You are correct that there is no MUST NOT. But the fact
that we excised the MUST is significant. I interpret that
as follows:
- Its ok for someone to develop a proposal for how nomail
could be included, so long as it doesn't get in the way
of the meeting the MUST & SHOULD requirements, which we
do first (that's sort-of what PHB suggested yesterday, I
think);
- its not ok to hold up work on the basis that nomail
isn't included.
Later in your mail you seem to say that there was some
ambiguity when we decided the above. I totally disagree
with that - the mail archive is very clear.
Regards,
Stephen.
Hector Santos wrote:
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.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html