Bug 6896 - URL parser collects also invalid domain names, resulting in warnings from a DNS resolver
Summary: URL parser collects also invalid domain names, resulting in warnings from a D...
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Libraries (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: All All
: P2 minor
Target Milestone: 3.4.0
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-23 18:15 UTC by Mark Martinec
Modified: 2013-02-04 20:52 UTC (History)
1 user (show)


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Martinec 2013-01-23 18:15:46 UTC 
Now that the DNS resolver is a bit more picky and chatty about
DNS errors, we can see occasional warnings like these in the log:

dns: new_dns_packet (host=patch-media-webrtc-trunk-src-modules-audio
  _device-main-source-linux-latebindingsymboltable_linux.cc.
  type=ANY class=IN)
  failed: a label in a domain name is longer than 63 bytes

dns: new_dns_packet (domain=sintef..no. type=ANY class=IN) failed:
  a domain name contains a null label

dns: new_dns_packet (domain=scientificadvances..co.in. type=A class=IN)
  failed: a domain name contains a null label

dns: new_dns_packet (host=.appriver.com. type=A class=IN)
  failed: a domain name contains a null label

dns: new_dns_packet (host=Www.masa\276E.COm. type=ANY class=IN)
  failed: invalid name
  at /usr/local/lib/perl5/site_perl/5.17.7/mach/Net/DNS/Question.pm
  line 87.

dns: new_dns_packet (host=www.theasian.asia\303\243\302\200\302
  \200\303\243\302\200\302\200\303\243\302\200\302\200ar.theasian.asia.
  type=ANY class=IN) failed: invalid name
  at /usr/local/lib/perl5/site_perl/5.17.7/mach/Net/DNS/Question.pm
  line 80.

The following are similar, but they come from a SPF plugin,
or rather, from its underlying perl module:

dns: new_dns_packet (host=. type=SPF class=IN)
  failed: a domain name contains a null label

dns: new_dns_packet (host=. type=TXT class=IN)
  failed: a domain name contains a null label

dns: new_dns_packet (domain=. type=SPF class=IN)
  failed: a domain name contains a null label

dns: new_dns_packet (domain=. type=TXT class=IN)
  failed: a domain name contains a null label


Choices:

- demote the resolver warning into an 'info' debug level message
  and not to bother with the cause;

- let the URL parser ignore such invalid domain names,
  (or perhaps attempt to sanitize them???)

- those coming from the SPF plugin seem to find such invalid
  domain names either in a HELO, or in some published
  SPF record, and apparently do not bother checking for
  valid syntax
Comment 1 AXB 2013-01-23 18:24:40 UTC 
+1 for
- demote the resolver warning into an 'info' debug level message
  and not to bother with the cause;
Comment 2 Mark Martinec 2013-01-25 20:01:56 UTC 
(In reply to comment #1)
> +1 for
> - demote the resolver warning into an 'info' debug level message
>   and not to bother with the cause;

Ok, done.

Also dealt with encoding/decoding backslashes as expected by Net::DNS,
and decoding queries for sensible and consistent display purposes.

Domain names as considered invalid by Net::DNS are still broken,
along with the new gratuitous idea of Net::DNS to IDN-encode (or not
to encode) such domains based solely on a presence of an IDN module,
without giving a caller of choice of explicitly requesting one or
the other behavior. Oh well. But that's a subject for some other
problem report.

trunk:
  Bug 6896: encode/decode a DNS query according to
    RFC 1035 zone file format as expected by Net::DNS API
   (what a terrible idea!), turn warning into info()
   for unmatching DNS responses
  Sending lib/Mail/SpamAssassin/AsyncLoop.pm
  Sending lib/Mail/SpamAssassin/DnsResolver.pm
  Sending lib/Mail/SpamAssassin/Plugin/AskDNS.pm
  Sending lib/Mail/SpamAssassin/Util.pm
Committed revision 1438670.
Comment 3 Mark Martinec 2013-01-26 01:16:28 UTC 
trunk:
  More informative diagnostics in case of a DNS response
  with no query section
    Sending lib/Mail/SpamAssassin/DnsResolver.pm
  Committed revision 1438806.
(stated a wrong bug number in the SVN log, sorry)
Comment 4 Mark Martinec 2013-01-28 18:27:04 UTC 
This should also fix cases like:

  dns: new_dns_packet (domain=ev\335ndeYAp.coM. type=ANY class=IN) failed:
    invalid name
    at /usr/local/lib/perl5/site_perl/5.17.7/mach/Net/DNS/Question.pm
    line 80.

...with newer versions of Net::DNS when a module Net::LibIDN happens
to be installed on the host.

trunk:
  DnsResolver.pm: encode characters above 0200 to prevent Net::DNS 0.68 from
  interpreting these as an IDN domain name' lib/Mail/SpamAssassin/DnsResolver.pm
Sending lib/Mail/SpamAssassin/DnsResolver.pm
Committed revision 1439552.
Comment 5 Mark Martinec 2013-01-28 18:31:55 UTC 
Closing.

In summary:
- URI and SPF parsers can still produce syntactically invalid domain names,
  but a warn has been demoted to an info message;
- a backslash and high-code characters are now encoded according to RFC 1035
  as expected by Net::DNS;
- improved logging in case of receiving a DNS reply with no question section.
Comment 6 Mark Martinec 2013-01-29 13:16:54 UTC 
encode also nonprintables, just in case (Net::DNS feature-proofing)
  Sending lib/Mail/SpamAssassin/DnsResolver.pm
Committed revision 1439884.
Comment 7 Mark Martinec 2013-02-01 16:24:57 UTC 
Just in case someone decides to tackle the URI parser some day in the
indefinite future, here are two more cases of invalid domain names
ending up in a DNS query, resulting in the following info() log entries:

dns: new_dns_packet (domain=
kluba-------------------------------------------------------------www.last-minute.si.
 type=ANY class=IN) failed: a label in a domain name is longer than 63 bytes

dns: new_dns_packet (domain=
\134documents and settings\134shenette\134desktop\1342012\134april emailing\134environment\134www.oxfordroundtable.co.uk.
 type=A class=IN) failed: a label in a domain name is longer than 63 bytes
Comment 8 Mark Martinec 2013-02-04 19:30:07 UTC 
Here is another case, this time I was able to collect the source text too:

dns: new_dns_packet (domain=
  \134documents and settings\134shenette\134desktop\1342012\134april emailing\134environment\134www.oxfordroundtable.co.uk.
 type=A class=IN) failed: a label in a domain name is longer than 63 bytes

which comes from an QP-encoded HTML:

<P style=3D"MARGIN: 0in 0in 0pt" class=3DMsoNormal><SPAN style=3D"FONT-FAMI=
LY: 'Times New Roman','serif'; mso-fareast-font-family: 'Times New Roman'; =
mso-no-proof: yes; mso-fareast-theme-font: minor-fareast">Web Site:<SPAN st=
yle=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN></SPAN><A href=3D"C:\Do=
cuments and Settings\Shenette\Desktop\2012\April Emailing\Environment\www.o=
xfordroundtable.co.uk"><SPAN style=3D"FONT-FAMILY: 'Times New Roman','serif=
'; mso-fareast-font-family: 'Times New Roman'; mso-no-proof: yes; mso-farea=
st-theme-font: minor-fareast">www.oxfordroundtable.co.uk</SPAN></A><SPAN st=
yle=3D"FONT-FAMILY: 'Times New Roman','serif'; mso-fareast-font-family: 'Ti=
mes New Roman'; mso-no-proof: yes; mso-fareast-theme-font: minor-fareast"> =
<o:p></o:p></SPAN></P>


I wonder what a browser is supposed to do with the link:

<A href="C:\Documents and Settings\Shenette\Desktop\2012\April Emailing\Environment\www.oxfordroundtable.co.uk">
Comment 9 John Hardin 2013-02-04 20:52:01 UTC 
(In reply to comment #8)
> I wonder what a browser is supposed to do with the link:
> 
> <A href="C:\Documents and Settings\Shenette\Desktop\2012\April
> Emailing\Environment\www.oxfordroundtable.co.uk">

That works _great_... on the desktop of the person who is composing the email message...

I feel a rule coming on... :)