[Top] [All Lists]

Re: Mail, not to be confused with spam...

2011-12-28 20:41:58

On 12/21/11 6:15 AM, Dave CROCKER wrote:
 On 12/1/2011 9:53 AM, John Levine wrote:
> It was an IRTF draft. Then some people in the IESG asked why it
> wasn't standards track. Fine, I said, let's make it standards
> track. Then in IESG review, people (not the same ones) in the IESG
> offered a variety of comments that revealed that their
> understanding of spam management was stuck in the 1990s, and there
> was no way they were going to approve this draft without a lot of
> changes that would make it useless. So I said, never mind, and
> flipped it back to IRTF, which is how it was published.
 The particular example involved re-purposing DNS RRs for anti-spam,
 since that's the most common way to publish blacklist information.
 And as John noted, the document did not come from an IETF working

 DNS work in the IETF is dominated by a collection of folk who demand
 quite a bit of purity in proposed standards and BCPs. Repurposing A
 records is a long way from pure.

 The fact that this is a well-established mechanism and is essential
 to the operation of Internet Mail is irrelevant to these folk.

 The fact that they and others don't know anything about modern
 anti-spam work was, IMO, secondary to the purity concern.

 Also, folks should note that DKIM was an anti-spam effort and had no
 process problems getting on the standards track.

IMHO, few within the DNS community consider reverse DNS suitable for blacklisting IPv6 addresses. A reasonable estimate of near term prefix announcements will soon approach an equivalent of a quadrillion /64s. Reverse DNS will soon fail in a blacklisting role. Some providers, such as ThreatStop, now offer APL RRs as a forward looking approach.

DKIM was never part of an anti-spam effort. It started out as an anti-phishing effort that did not require MUA modification for safe deployment. DKIM does not verify the entity transmitting the message, nor intended recipients. Spammers are normally defined as those transmitting messages unwanted by recipients. DKIM is unable to confirm either transmitters or intended recipients. Hardly a suitable tool for dealing with spam. Even with statistics applied, domains will be unable to defend their reputation when DKIM is used as a basis for assessing spammers. Except of course those already considered too big to block.

With DKIM signature validation ignoring prepended headers, DKIM even fails to meet the intended purpose as an anti-phishing tool since it now requires modified MUAs to detect pre-pended header fields. A check lacking any type of confirmation likely to give users a false sense of security making them more prone to deception. :^(

 That is, an IETF working group that was able to produce a consensus
 document got through the IESG with no major problems. A document
 that did not come from a working group /did/ have problems.

Agreed, there are problems.