Stephen has almost captured my issues here. My point here is that since NOMAIL is not a MUST requirement we do not require the same level of design for deployment as for a feature that is a core requirement. In particular it is acceptable for us to specify a scheme which requires deployment of new DNS infrastructure for NOMAIL, this seems obvious to me as there are existing schemes which address this requirement.
I do want to solve NOMAIL, in fact I think that it is essential that we do so to close all possible avenues of attack, including the unsigned mail from nonexistent domain attack. However I am quite happy for expression of NOMAIL to require deployment of an XPTR capable DNS server. I am proposing a scheme here which allows for a transition to a principled infrastructure in which NOMAIL like DKIM is supported as a first class entity. All I don't want to do is to discuss the details of NOMAIL implementation at this point. If we get the structure right they take about half an hour. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Farrell > Sent: Wednesday, June 06, 2007 10:45 AM > To: Hector Santos > Cc: ietf-dkim@mipassoc.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 > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
