-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Stephen
Farrell
Sent: Wednesday, June 06, 2007 10:45 AM
To: Hector Santos
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] RE: I think we can punt the hard
stuff as out ofscope.
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