[ietf-dkim] RE: I think we can punt the hard stuff as out of scope.

[Hector Santos]

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
> 
>