[ietf-dkim] RE: I think we can punt the hard stuff as out of
hsantos at santronics.com
Wed Jun 6 07:18:45 PDT 2007
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:
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.
Hector Santos, CTO
Stephen Farrell wrote:
> Stephen Farrell wrote:
>> 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  included a mention that we could/shoud
> delete the "never send mail" item.
> That was raised by Eric on the list  in February and
> dicussed at length.
> Following that discussion I started a strawpoll  that
> resulted in a 2:1 ratio  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,
>  https://rt.psg.com/Ticket/Display.html?id=1365
>  http://mipassoc.org/pipermail/ietf-dkim/2007q1/007139.html
>  http://mipassoc.org/pipermail/ietf-dkim/2007q1/007185.html
>  http://mipassoc.org/pipermail/ietf-dkim/2007q1/007254.html
More information about the ietf-dkim