You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ruleqa@spamassassin.apache.org by Marc Andre Selig <a2...@sedacon.com> on 2013/03/09 14:55:13 UTC
Errors during --net masscheck
Hi all,
here are some DNS related error messages reported by auto-mass-check in
--net mode that should probably be caught?
(domain=0u_e3czdty8udzyvx98_ox97tdy97utd3aut09ultcdaumtd3unqnrrntw3utwv8utweut80u.jp.dob.sibl.suppor
t-intelligence.net. type=A class=IN) failed: a label in a domain name is longer than 63 bytes
dns: new_dns_packet
(domain=0u_e3czdty8udzyvx98_ox97tdy97utd3aut09ultcdaumtd3unqnrrntw3utwv8utweut80u.jp.dbl.spamhaus.or
g. type=A class=IN) failed: a label in a domain name is longer than 63 bytes
dns: new_dns_packet
(domain=0u_e3czdty8udzyvx98_ox97tdy97utd3aut09ultcdaumtd3unqnrrntw3utwv8utweut80u.jp. type=A
class=IN) failed: a label in a domain name is longer than 63 bytes
dns: new_dns_packet (domain=podify-merchants..com. type=A class=IN) failed: a domain name contains a
null label
For future reference, would you prefer me to report things like this
directly using Bugzilla, or is it ok to post here?
Regards,
Marc
Re: Errors during --net masscheck
Posted by Marc Andre Selig <a2...@sedacon.com>.
On Sun, Mar 10, 2013 at 10:48:59AM +0100, Axb wrote:
> On 03/09/2013 06:25 PM, John Hardin wrote:
> >It actually appears that way in the email?
>
> nope! - haven't take the time to try to find the messages causing
> it, either.
This is the relevant part of a spam message that caused the problem here:
----- cut here -----
<a href="http://podify-merchants.
.
com/?dWlkPTI4OTA4NzEwMSZjaWQ9MjczODUmbGlkPTEmcm49Y2l0">
----- cut here -----
Regards,
Marc
Re: Errors during --net masscheck
Posted by Axb <ax...@gmail.com>.
On 03/09/2013 06:25 PM, John Hardin wrote:
> On Sat, 9 Mar 2013, Axb wrote:
>
>> On 03/09/2013 02:55 PM, Marc Andre Selig wrote:
>>
>>> dns: new_dns_packet (domain=podify-merchants..com. type=A class=IN)
>>> failed: a domain name contains a
>>> null label
>>
>> I see these often but haven't been able to reproduce the two periods
>> before the tld. I'm sure someone here will be able to explain this in
>> detail.
>
> It actually appears that way in the email?
nope! - haven't take the time to try to find the messages causing it,
either.
Re: Errors during --net masscheck
Posted by John Hardin <jh...@impsec.org>.
On Sat, 9 Mar 2013, Axb wrote:
> On 03/09/2013 02:55 PM, Marc Andre Selig wrote:
>
>> dns: new_dns_packet (domain=podify-merchants..com. type=A class=IN)
>> failed: a domain name contains a
>> null label
>
> I see these often but haven't been able to reproduce the two periods before
> the tld. I'm sure someone here will be able to explain this in detail.
It actually appears that way in the email?
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Failure to plan ahead on someone else's part does not constitute
an emergency on my part. -- David W. Barts in a.s.r
-----------------------------------------------------------------------
Tomorrow: Daylight Saving Time begins in U.S. - Spring Forward
Re: Errors during --net masscheck
Posted by John Hardin <jh...@impsec.org>.
On Sat, 9 Mar 2013, Marc Andre Selig wrote:
> Again, I think SpamAssassin should be able to handle this without
> flagging an error message.
Agreed. In fact, errors of that nature should be exposed so that a score
can be attached to them.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Failure to plan ahead on someone else's part does not constitute
an emergency on my part. -- David W. Barts in a.s.r
-----------------------------------------------------------------------
Tomorrow: Daylight Saving Time begins in U.S. - Spring Forward
Re: Errors during --net masscheck
Posted by Marc Andre Selig <a2...@sedacon.com>.
On Sat, Mar 09, 2013 at 04:18:40PM +0100, Axb wrote:
> For stuff like that we need to rely on hashers, bayes and other
> content rules.
Don't get me wrong: spamd, running on the mail server, handles these
just fine. It's only the mass-check code that produces these superfluous
messages.
If it's difficult to fix, by all means leave it as it is.
> On 03/09/2013 03:57 PM, Marc Andre Selig wrote:
> >Whitespace within the URL is removed in line with RFC 1738/2396/3986,
> >and we end up with "http://podify-merchants..com/?...", which is of
> >course invalid.
> One good way to test these cases is open such a spam msg with
> Thunderbird and maybe some Outlook flavour.
No Windows around here. ;) However, a quick check with what I've got
yields these results (for my own domain):
- SpamAssassin on its own, outside of auto-mass-check, triggers
URI_OBFU_WWW (for a null label) and is otherwise happy.
- urlview on Debian GNU/Linux, Apple's Mail.app, and Symbian's Mail
all take the full URL and pass it on to the configured web client.
urlview could actually be told that these are not valid URLs by editing
/etc/urlview/system.urlview or ~/.urlview.
- K-9 Mail on Android actually knows that these URLs are invalid. It does
not show the one with the null label as an URL at all. For the other
case, it shortens the overlong label to its last 63 characters and
passes the resulting URL to the browser.
None of the MUAs I tested allow line breaks within URLs, treating the
line break as an URL delimiter instead.
- Firefox (both on Linux and on OS X) just says "Server not found".
- Safari has a localized message for "Server not found".
- Chrome (on OS X) has the same message for the overlong name, but
recognizes the null label as invalid and passes that one on to the
configured search engine instead of trying to resolve it.
- Web on Symbian (an ancient Webkit engine) tries to resolve both and
shows the standard message for unresolveable domains.
- lynx says "Can't access startfile".
- curl says "Couldn't resolve host".
- wget says "Name or service not known", "unable to resolve host address".
None of these trigger an additional error message. All behave in a
somewhat defensible way, either showing some variation on the theme of
"server not found" to the user or trying to "improve" the request in some
way. There are no warnings written to syslog or mailed to postmaster.
Except for Chrome on OS X and K-9 Mail on Android, all of these
consistently show the same behaviour for overlong and null labels in
domain names and for non-existent but syntactically valid domain names.
> If they can't handle the URL, then we can't really expect SA easily
> to do it either.
As they all handle the invalid URL just fine, including stock SpamAssassin
while running in daemon mode, I still believe the mass-check code should
be able to do it as well. But of course, I would never insist on it. ;)
Regards,
Marc
Re: Errors during --net masscheck
Posted by Axb <ax...@gmail.com>.
On 03/09/2013 03:57 PM, Marc Andre Selig wrote:
>
> I believe that, just as the label in the first example is too long, the
> label in this example is simply too short (i.e. null).
>
> In this case, the domain name has been split across three lines, probably
> in an attempt to foil simple URIBL scanners. This is the relevant part
> of the original message body:
>
> ----- cut here -----
> <a href="http://podify-merchants.
> .
> com/?dWlkPTI4OTA4NzEwMSZjaWQ9MjczODUmbGlkPTEmcm49Y2l0">
> ----- cut here -----
>
> Whitespace within the URL is removed in line with RFC 1738/2396/3986,
> and we end up with "http://podify-merchants..com/?...", which is of
> course invalid.
>
> It seems to be an error on the part of the spammer, as this domain name
> is written correctly (without the duplicate dot, but still split across
> three lines) elsewhere in the same message. Again, I think SpamAssassin
> should be able to handle this without flagging an error message.
One good way to test these cases is open such a spam msg with
Thunderbird and maybe some Outlook flavour.
If they can't handle the URL, then we can't really expect SA easily to
do it either.
You could use the ASK plugin intensely and walk the fine line of parsing
errors and FPs (been there!). There are so many cases where CICO
(crap-in-crap-out), it's hardly possible to foresee what template borks
a spammer might deliver.
For stuff like that we need to rely on hashers, bayes and other content
rules.
Re: Errors during --net masscheck
Posted by Marc Andre Selig <a2...@sedacon.com>.
On Sat, Mar 09, 2013 at 03:05:30PM +0100, Axb wrote:
> On 03/09/2013 02:55 PM, Marc Andre Selig wrote:
> >(domain=0u_e3czdty8udzyvx98_ox97tdy97utd3aut09ultcdaumtd3unqnrrntw3utwv8utweut80u.jp.dob.sibl.suppor
> >t-intelligence.net. type=A class=IN) failed: a label in a domain name is longer than 63 bytes
> try with dig & you'll get
>
> dig A 0u_e3czdty8udzyvx98_ox97tdy97utd3aut09ultcdaumtd3unqnrrntw3utwv8utweut80u.jp
> +short
> dig: '0u_e3czdty8udzyvx98_ox97tdy97utd3aut09ultcdaumtd3unqnrrntw3utwv8utweut80u.jp'
> is not a legal name (label too long)
> iirc, max label size is 63 chars. so this is hardly SA but a DNS "feature"
You are perfectly right that this is an invalid label.
I still think displaying this error message should be regarded as a bug
in SpamAssassin because it's not the user's fault, but the spammer's, who
the user does not have any influence over. In my opinion, SpamAssassin
should be able to handle any kind of spam (including invalid domain names)
without error messages. It should display error messages when the user
has done something wrong, or when there's a condition that it cannot be
expected to handle on its own.
> >dns: new_dns_packet (domain=podify-merchants..com. type=A class=IN) failed: a domain name contains a
> >null label
>
> I see these often but haven't been able to reproduce the two periods
> before the tld. I'm sure someone here will be able to explain this
> in detail.
I believe that, just as the label in the first example is too long, the
label in this example is simply too short (i.e. null).
In this case, the domain name has been split across three lines, probably
in an attempt to foil simple URIBL scanners. This is the relevant part
of the original message body:
----- cut here -----
<a href="http://podify-merchants.
.
com/?dWlkPTI4OTA4NzEwMSZjaWQ9MjczODUmbGlkPTEmcm49Y2l0">
----- cut here -----
Whitespace within the URL is removed in line with RFC 1738/2396/3986,
and we end up with "http://podify-merchants..com/?...", which is of
course invalid.
It seems to be an error on the part of the spammer, as this domain name
is written correctly (without the duplicate dot, but still split across
three lines) elsewhere in the same message. Again, I think SpamAssassin
should be able to handle this without flagging an error message.
Regards,
Marc
Re: Errors during --net masscheck
Posted by Axb <ax...@gmail.com>.
On 03/09/2013 02:55 PM, Marc Andre Selig wrote:
> Hi all,
>
> here are some DNS related error messages reported by auto-mass-check in
> --net mode that should probably be caught?
>
> (domain=0u_e3czdty8udzyvx98_ox97tdy97utd3aut09ultcdaumtd3unqnrrntw3utwv8utweut80u.jp.dob.sibl.suppor
> t-intelligence.net. type=A class=IN) failed: a label in a domain name is longer than 63 bytes
> dns: new_dns_packet
> (domain=0u_e3czdty8udzyvx98_ox97tdy97utd3aut09ultcdaumtd3unqnrrntw3utwv8utweut80u.jp.dbl.spamhaus.or
> g. type=A class=IN) failed: a label in a domain name is longer than 63 bytes
> dns: new_dns_packet
> (domain=0u_e3czdty8udzyvx98_ox97tdy97utd3aut09ultcdaumtd3unqnrrntw3utwv8utweut80u.jp. type=A
> class=IN) failed: a label in a domain name is longer than 63 bytes
try with dig & you'll get
dig A
0u_e3czdty8udzyvx98_ox97tdy97utd3aut09ultcdaumtd3unqnrrntw3utwv8utweut80u.jp
+short
dig:
'0u_e3czdty8udzyvx98_ox97tdy97utd3aut09ultcdaumtd3unqnrrntw3utwv8utweut80u.jp'
is not a legal name (label too long)
iirc, max label size is 63 chars. so this is hardly SA but a DNS "feature"
> dns: new_dns_packet (domain=podify-merchants..com. type=A class=IN) failed: a domain name contains a
> null label
I see these often but haven't been able to reproduce the two periods
before the tld. I'm sure someone here will be able to explain this in
detail.
> For future reference, would you prefer me to report things like this
> directly using Bugzilla, or is it ok to post here?
Here is fine so others can check before we open bugs which aren't.