Re: [sitefinder-tech-discuss] A technical question

[Kee Hinckley <nazgul@somewhere.com>]

At 1:16 AM -0400 10/8/03, Andrew Newton wrote:
> Kee Hinckley wrote:
> > First of all, in this particular case my primary concern is whether 
> > or not the domain in question can conceivably receive email 
> > (insofar as one can tell short of trying to connect to a mail 
> > server).
> >
> > Previously the query would be pretty straightforward.
> > 1. If NXDOMAIN, the answer is no, bail.
> > 2. If A record exists, answer is yes, bail.
> > 3. If MX record exists, answer is yes, bail.
> > 4. No.
> >
> > Now we have a more complex situation.
> > 1. If any of the A records for this domain are different from any 
> > of the A records for *.tld, then the answer is yes, bail.
> > 2. If any of the MX records for this domain are different from any 
> > of the MX records for *.tld, then the answer is yes, bail.
> > 3. No.
>
> It is my understanding that the MX query should become before the A query.

If you were looking to see who to deliver it too yes.

> We have talked about deploying a wildcard MX record with a target 
> pointing to a non-existant name (e.g. does-not-exist.verisign.com). 
> This should cause an NXDOMAIN.

Ah, I see why you care about order.  RFC974 doesn't seem to state 
what action to take on  particular types of failures.  Is there 
another that does?  My guess is that most mail programs will be 
conservative and fall back to the A record, but perhaps not.


> > > The service may cause a problem for a small number of spam filters 
> > > that check to see if inbound e-mail is coming from a legitimate 
> > > Web address, said Matt Larson, principle engineer with VeriSign's 
> > > Naming and Directory Services. But the domain name check isn't 
> > > used by most popular spam filters, and it's just one of many 
> > > checks a spam filter vendor should use to check for spam, Larson 
> > > said.
> >
> >
> > It's not used by many spam filters because it's a standard feature 
> > in all major mail servers.  Furthermore, it is on by default in 
> > Sendmail, CommuniGate and probably many others.  It's a first line 
> > of defense that (unlike almost all other anti-spam mechanisms) has 
> > no risk of false positives.
>
> Matt used the term "web address"?

Well, that was the CNET quote.

> To clarify the point:  VeriSign talked to major providers of spam 
> filtering services and was informed that they do not use a forward 
> domain check.

I'm afraid you asked the wrong people.  The majority of internet 
users are not protected by any of the major anti-spam vendors (as 
much as we'd rather otherwise :-).  Ask the MTA vendors and the ISPs.

250 rly-xg02.mx.aol.com OK
mail from:<asdfdsf@asdfsdfjjdfjfj.com>
550 REQUESTED ACTION NOT TAKEN: DNS FAILURE

> On the point of forward domain checks and false positives, I believe 
> BCP 30 advices against this assumption.

The MTA SHOULD be able to perform a simple "sanity check" of the
   "MAIL From:" domain and refuse to receive mail if that domain is
   nonexistent (i.e. does not resolve to having an MX or an A record).
   If the DNS error is temporary, TempFail, the MTA MUST return a 4xx
   Return Code (Temporary Error). If the DNS error is an Authoritative
   NXdomain (host/domain unknown) the MTA SHOULD still return a 4xx
   Return Code (since this may just be primary and secondary DNS not
   being in sync) but it MAY allow for an 5xx Return Code (as configured
   by the sysadmin).
--
Kee Hinckley
http://www.messagefire.com/         Next Generation Spam Defense
http://commons.somewhere.com/buzz/  Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.