Re: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-00.txt

[Ned Freed <[e-mail]>]

> ----- Original Message -----
> > From: "Ned Freed" <[e-mail]>
> > To: "Franck Martin" <[e-mail]>
> > Cc: [e-mail]
> > Sent: Wednesday, February 19, 2014 1:51:32 PM
> > Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-00.txt
> >
> > > This draft requires current filtering solutions to change behavior. The
> > > presence of an MX will indicate the domain is emailable (cf spamassassin
> > > rules)
> > > until the software is changed to recognize the 0. We will have different
> > > behavior while this is getting implemented.
> >
> > The domain validity check is extremely weak to begin with. And given the
> > speed
> > at which such rules have to evolve for other reasons, even if you think this
> > deserves consideration - which I don't - it's a miniscule  factor in the
> > overall scheme of AS/AV solutions.

> It is in spamassassin and others,

Along with hundreds of other tests, rules, criteria, etc. etc.

> not sure the word miniscule "apply" here.

You're right - I was being overly generous by calling it minescule. Of no
real consequence would be a lot closer to the mark.

> Furthermore anything that weakens anti-spam measure should not be encouraged by
> a body like IETF, which wants to increase the security of the Internet.

Sorry, that's nothing short of absurd. There are a myriad of antispam 
mechanisms in play - so many that pretty much every action we take in regards
to email is going to have some impact somewhere.

Just to point out the elephant in the corner here, it's obvious that increased
use of end-to-end security is likely to have a seriously detrimental impact on
various antispam measures. Does this translate to such work being off the table
for the IETF. Clearly not.

> >
> > > The same functionality can be achieved with
> >
> > > example.com "v=SPF1 -all"
> > > *.example.com "v=SPF1 -all"
> >
> > It's not even remotely the same functionality. The point of the nullmx
> > mechanism is to inform agents *sending* messages to the domain that there's
> > no point in even bothering making a connection. To the best of my knowlege
> > nobody looks at SPF records for domain before attempting to send mail to
> > them.

> Well, in another RFC, every domain should have an abuse@ and postmaster@ this
> domain. This seems in conflict.

Others have pointed out that those other RFCs only apply to domains that
actually run mail servers.

> >
> > > Which would cover also any subdomain and will not have different
> > > interpretation while being deployed.
> >
> > If you're seriously proposing that SMTP clients start looking at SPF records,
> > that a MAJOR change that would be a major PITA to get deployed.
> >
> same as implementing this, it is a NS record lookup and special processing.

Incorrect. This is an added check of the result from the MX lookup that's
already being performed by every SMTP client out there. No additional lookups
are required.

				Ned