Some BOTNETs connect with seemingly randomized HELO addresses. I
wonder if there's a means by which to deal with this (perhaps via a
Milter).


Thanks.

In article <3760ae82-7ee8-42d4-ba59-9a5f2fa53d85@m44g2000hsc.googlegroups.com>,
forrie@gmail.com <forrie@gmail.com> wrote:
>Some BOTNETs connect with seemingly randomized HELO addresses. I
>wonder if there's a means by which to deal with this (perhaps via a
>Milter).

milters can do _anything_. <grin>

The only question is how much time you want to spend developing it.

Machines _should_ HELO with a FQDN for that machine. and it "should" match
the rDNS for the connecting address`

Insisting on an rDNS match will drop significant amounts of 'legitimate' mail.

Doing some basic 'sanity checks' on the HELO string -- e.g. rejecting any
outside machine that HELOs as _your_ network, disallowing anything that
starts with an '-', is all-numeric, looks like a dotted quad {with or without
surrounding brackets}, an unqualified 'localhost' or 'localhost@localdomain',
requiring at least 1 dot in the string, and that there be a valid TLD _after_
the last dot -- =will= trap a lot of bad stuff, with only a _very_rare_ impact
on legitimate mail.

"Robert Bonomi" <bonomi@host122.r-bonomi.com> wrote in message
news:13tg4kq4kaic6d0@corp.supernews.com...
> In article
<3760ae82-7ee8-42d4-ba59-9a5f2fa53d85@m44g2000hsc.googlegroups.com>,
> forrie@gmail.com <forrie@gmail.com> wrote:
> >Some BOTNETs connect with seemingly randomized HELO addresses. I
> >wonder if there's a means by which to deal with this (perhaps via a
> >Milter).
>
> milters can do _anything_. <grin>
>
> The only question is how much time you want to spend developing it.
>
> Machines _should_ HELO with a FQDN for that machine. and it "should" match
> the rDNS for the connecting address`

However, note that a multi-homed mail server is still supposed to use its
preferred name on the HELO (EHLO) command and that name may differ from the
name assigned to the interface it is using. The RFCs forbid checking the
HELO name and rejecting it based on any reason other than a syntax error.

I personally believe that there is one case that the RFCs don't address
where it is acceptable to reject: If the HELO name is (one of) your own
server's names and it is not from your own server, then one may reject that
as a forgery.

> Insisting on an rDNS match will drop significant amounts of 'legitimate'
mail.

See above for why.

> Doing some basic 'sanity checks' on the HELO string -- e.g. rejecting any
> outside machine that HELOs as _your_ network, disallowing anything that
> starts with an '-', is all-numeric, looks like a dotted quad {with or
without
> surrounding brackets}, an unqualified 'localhost' or
'localhost@localdomain',
> requiring at least 1 dot in the string, and that there be a valid TLD
_after_
> the last dot -- =will= trap a lot of bad stuff, with only a _very_rare_
impact
> on legitimate mail.

Why should a "dotted-quad inside brackets" be rejected? That's what the
RFCs say is supposed to be issued if no hosthame is assigned. A dotted-quad
not enclosed by brackets is a syntax error and should be rejected.
"Localhost" by itself is also permitted, but only if it's truly one's self.

Robert Bonomi wrote:
> In article <3760ae82-7ee8-42d4-ba59-9a5f2fa53d85@m44g2000hsc.googlegroups.com>,
> forrie@gmail.com <forrie@gmail.com> wrote:
>> Some BOTNETs connect with seemingly randomized HELO addresses. I
>> wonder if there's a means by which to deal with this (perhaps via a
>> Milter).
>
> milters can do _anything_. <grin>
>
> The only question is how much time you want to spend developing it.

it's already available:
http://www.benzedrine.cx/milter-regex.html


>
> Machines _should_ HELO with a FQDN for that machine. and it "should" match
> the rDNS for the connecting address`
>
> Insisting on an rDNS match will drop significant amounts of 'legitimate' mail.
>
> Doing some basic 'sanity checks' on the HELO string -- e.g. rejecting any
> outside machine that HELOs as _your_ network, disallowing anything that
> starts with an '-', is all-numeric, looks like a dotted quad {with or without
> surrounding brackets}, an unqualified 'localhost' or 'localhost@localdomain',
> requiring at least 1 dot in the string, and that there be a valid TLD _after_
> the last dot -- =will= trap a lot of bad stuff, with only a _very_rare_ impact
> on legitimate mail.
>
>

snarfit.net
admin@snarfit.net

In article <fr9bfc$mv4$1@snarked.org>,
D. Stussy <replies@newsgroups.kd6lvw.ampr.org> wrote:
>"Robert Bonomi" <bonomi@host122.r-bonomi.com> wrote in message
>news:13tg4kq4kaic6d0@corp.supernews.com...
>
>> Doing some basic 'sanity checks' on the HELO string -- e.g. rejecting any
>> outside machine that HELOs as _your_ network, disallowing anything that
>> starts with an '-', is all-numeric, looks like a dotted quad {with or
>without
>> surrounding brackets}, an unqualified 'localhost' or
>'localhost@localdomain',
>> requiring at least 1 dot in the string, and that there be a valid TLD
>_after_
>> the last dot -- =will= trap a lot of bad stuff, with only a _very_rare_
>impact
>> on legitimate mail.
>
>Why should a "dotted-quad inside brackets" be rejected?

I see no need to repeat myself. Read the words after "the last dot --',
and see if you can figure it out.

> That's what the
>RFCs say is supposed to be issued if no hosthame is assigned.

So?

If the admin of the box in question has not set up a hostname, what are the
odds that he _intends_ to be using it for outgoing mail?

If the admin *didn't* intend to use it for outgoing mail, what are the odds
that the mail from that box is unwelcome?
> A dotted-quad
>not enclosed by brackets is a syntax error and should be rejected.


Not necessarily. it could be 'pseudo-random garbage' that just happens to
look like a dotted quad. If the originator _intends_ it to be taken as
'naming' a machine without an assigned name, then yes, the dotted-quad
representation of the IP address must be enclosed in the specified symbols.
If the machine IS named, and has a 'name' with just numeric parts, then
no bracketing symbols are appropriate.

If one requires a dot, and a _valid_ TLD suffix, an un-bracketed dotted-quad
will fail that test, as will unqualified 'localhost', '@localdomain', and
'@local.domain'.


>"Localhost" by itself is also permitted, but only if it's truly one's self.

Since the originating machine is purportedly using its "preferred"/"primary"
name as the HELO id, a 'legitimate' use of that name would imply no
network connections other than 127.0.0.1, and thus there would -never- be
any point to, nor benefit from, checking the HELO string. <grin>

"Robert Bonomi" <bonomi@host122.r-bonomi.com> wrote in message
news:13tgph9vvhmi67@corp.supernews.com...
> In article <fr9bfc$mv4$1@snarked.org>,
> D. Stussy <replies@newsgroups.kd6lvw.ampr.org> wrote:
> >"Robert Bonomi" <bonomi@host122.r-bonomi.com> wrote in message
> >news:13tg4kq4kaic6d0@corp.supernews.com...
> >
> >> Doing some basic 'sanity checks' on the HELO string -- e.g. rejecting
any
> >> outside machine that HELOs as _your_ network, disallowing anything that
> >> starts with an '-', is all-numeric, looks like a dotted quad {with or
> >without
> >> surrounding brackets}, an unqualified 'localhost' or
> >'localhost@localdomain',
> >> requiring at least 1 dot in the string, and that there be a valid TLD
> >_after_
> >> the last dot -- =will= trap a lot of bad stuff, with only a _very_rare_
> >impact
> >> on legitimate mail.
> >
> >Why should a "dotted-quad inside brackets" be rejected?
>
> I see no need to repeat myself. Read the words after "the last dot --',
> and see if you can figure it out.

"localhost" with NO dots is valid.

The check that I think you're suggesting should not be done on the HELO name
but instead on the hostname retrieved based on a reverse lookup of the IP
obtained from the incoming IP socket.

> > That's what the
> >RFCs say is supposed to be issued if no hosthame is assigned.
>
> So?
>
> If the admin of the box in question has not set up a hostname, what are
the
> odds that he _intends_ to be using it for outgoing mail?

Low but not zero.

> If the admin *didn't* intend to use it for outgoing mail, what are the
odds
> that the mail from that box is unwelcome?

Non-sequtur. Certain versions of Linux have an auto-reporting feature (e.g.
"the Linux Counter") when they're installed (or an option). A system might
not yet be configured when that mail is issued back to the distributor's
counter site. There's a valid example for you that breaks your assumption.

> > A
dotted-quad
> >not enclosed by brackets is a syntax error and should be rejected.
>
>
> Not necessarily. it could be 'pseudo-random garbage' that just happens to
> look like a dotted quad. If the originator _intends_ it to be taken as
> 'naming' a machine without an assigned name, then yes, the dotted-quad
> representation of the IP address must be enclosed in the specified
symbols.
> If the machine IS named, and has a 'name' with just numeric parts, then
> no bracketing symbols are appropriate.

If it's not bracketed, then it's a hostname. A hostname containing no
alphabetics is invalid.

> If one requires a dot, and a _valid_ TLD suffix, an un-bracketed
dotted-quad
> will fail that test, as will unqualified 'localhost', '@localdomain', and
> '@local.domain'.

So will a bracketed IP address unless you test for it. Furthermore, IPv6
addresses may not have any periods.

> >"Localhost" by itself is also permitted, but only if it's truly one's
self.
>
> Since the originating machine is purportedly using its
"preferred"/"primary"
> name as the HELO id, a 'legitimate' use of that name would imply no
> network connections other than 127.0.0.1, and thus there would -never- be
> any point to, nor benefit from, checking the HELO string. <grin>

"localhost" could be presented on a connection coming from ANY of the
machine's interfaces, but I agree that such should only occur on the
loopback interface.

In article <fra6e9$v1i$1@snarked.org>,
D. Stussy <replies@newsgroups.kd6lvw.ampr.org> wrote:
>"Robert Bonomi" <bonomi@host122.r-bonomi.com> wrote in message
>news:13tgph9vvhmi67@corp.supernews.com...
>> In article <fr9bfc$mv4$1@snarked.org>,
>> D. Stussy <replies@newsgroups.kd6lvw.ampr.org> wrote:
>> >"Robert Bonomi" <bonomi@host122.r-bonomi.com> wrote in message
>> >news:13tg4kq4kaic6d0@corp.supernews.com...
>> >
>> >> Doing some basic 'sanity checks' on the HELO string -- e.g. rejecting
>any
>> >> outside machine that HELOs as _your_ network, disallowing anything that
>> >> starts with an '-', is all-numeric, looks like a dotted quad {with or
>> >without
>> >> surrounding brackets}, an unqualified 'localhost' or
>> >'localhost@localdomain',
>> >> requiring at least 1 dot in the string, and that there be a valid TLD
>> >_after_
>> >> the last dot -- =will= trap a lot of bad stuff, with only a _very_rare_
>> >impact
>> >> on legitimate mail.
>> >
>> >Why should a "dotted-quad inside brackets" be rejected?
>>
>> I see no need to repeat myself. Read the words after "the last dot --',
>> and see if you can figure it out.
>
>"localhost" with NO dots is valid.

So?

The 'object of the game' is to identify things the bad guys regularly do
that the 'good guys' ALMOST NEVER do. "Perfection" is not a pre-requisite.

BTW, whatinthe hell does the fact that '"localhost" with NO dots is valid'
have to do with your challenge 'why should a "dotted-quad inside brackets" be
rejected?'

Or did you get distracted by the language in the 'marker' that I suggested
you should read AFTER?

>The check that I think you're suggesting should not be done ...

You're making value judgements; I simply described some things that _are_
EFFECTIVE.

> ..on the HELO name
>but instead on the hostname retrieved based on a reverse lookup of the IP
>obtained from the incoming IP socket.

Feel free to do things your way on your machines. You'll get a humongous
number of false-positives when you apply them to the reverse lookup of a
connection from 127.1 <grin>

>> > That's what the
>> >RFCs say is supposed to be issued if no hosthame is assigned.
>>
>> So?
>>
>> If the admin of the box in question has not set up a hostname, what are
>the
>> odds that he _intends_ to be using it for outgoing mail?
>
>Low but not zero.

BINGO! That _is_ why one uses it. 'Perfection' is not a requirement,

Except in a few extraordinary situations, it is "for practical purposes,
equivalent to zero". And, in those "special cases" the mail admins are
fully aware of the circumstances involved, and can tailor *their* filter
rules accordingly.

>> If the admin *didn't* intend to use it for outgoing mail, what are the
>odds
>> that the mail from that box is unwelcome?
>
>Non-sequtur. Certain versions of Linux have an auto-reporting feature (e.g.
>"the Linux Counter") when they're installed (or an option). A system might
>not yet be configured when that mail is issued back to the distributor's
>counter site. There's a valid example for you that breaks your assumption.

"Male bovine excretement".

First, for your hypothetical to happen, that admin must have placed the box
'on-line' with open external connectivity *BEFORE* it was configured.


Second, I make no 'assumption' that _all_ mail from 'localhost' (or similar) is
unwanted at EVERY site. You will note that I expressly noted the "possibility"
of legitimate mail getting trapped. The fact remains that if one considers
_all_ the special-case mail you describe above (which goes to a _very_ small
number of sites) vs the number of messages received from 'apparently
unconfigured' machines at -all- locations, the 'valid' ones are an infinitesimal
portion of the whole. If one eliminates from consideration those few sites
that _know_ to expect such traffic, then the share of legitimate messages with
the stigmata in question is probably in the femto-percent range.


Admittedly, someone _expecting_ mail from such 'incompletely configured'
systems would need to run configurations _specific_to_their_needs_. Of
course, that applies to anyone with known 'unique' incoming mail
characteristics -- e.g. a sex therapist would lose an awful lot of 'valid'
email by using any standard anti-pornography filter.

The rarity of such special cases proves the 'general use' validity of the
rule.


>dotted-quad
>> >not enclosed by brackets is a syntax error and should be rejected.
>>
>> Not necessarily. it could be 'pseudo-random garbage' that just happens to
>> look like a dotted quad. If the originator _intends_ it to be taken as
>> 'naming' a machine without an assigned name, then yes, the dotted-quad
>> representation of the IP address must be enclosed in the specified
>symbols.
>> If the machine IS named, and has a 'name' with just numeric parts, then
>> no bracketing symbols are appropriate.
>
>If it's not bracketed, then it's a hostname. A hostname containing no
>alphabetics is invalid.

Wrong. Invalid in DNS, yes. but only there.
>
>> If one requires a dot, and a _valid_ TLD suffix, an un-bracketed
>dotted-quad
>> will fail that test, as will unqualified 'localhost', '@localdomain', and
>> '@local.domain'.
>
>So will a bracketed IP address unless you test for it. Furthermore, IPv6
>addresses may not have any periods.

Yup. and *all* are symptomatic -- to the =VAST= majority of mail-receiving
systems -- of a sending system that the admin does not intend to be sending
mail to arbitrary addresses.

>> >"Localhost" by itself is also permitted, but only if it's truly one's
>self.
>>
>> Since the originating machine is purportedly using its
>"preferred"/"primary"
>> name as the HELO id, a 'legitimate' use of that name would imply no
>> network connections other than 127.0.0.1, and thus there would -never- be
>> any point to, nor benefit from, checking the HELO string. <grin>
>
>"localhost" could be presented on a connection coming from ANY of the
>machine's interfaces, but I agree that such should only occur on the
>loopback interface.

By _YOUR_ interpretation of the 'rules', the HELO name must be the 'preferred'
name of the machine, regardless of the interface. Therefore, if 'localhost'
_is_ the 'offered' name, that machine -- since it's _preferred_ name is
meaningful _only_ to itself -- had better _not_ have any other interface
names, interfaces, or connectivity. <grin>

If a machine with a 'preferred' name of "localhost" _does_ have other
connectivity, then either the admin explicitly intends for that machine
_not_ to communicate with the outside world, *or* the box is so incompetently
configured that it is likely many of: 'owned', 'an open relay', 'a backscatter
source', part of a 'botnet', spreading viruses, etc.,etc., ad nauseum and
I don't want *anything* to do with it. _Either_way_, rejecting 'localhost'
is entirely sensible.

"Robert Bonomi" <bonomi@host122.r-bonomi.com> wrote in message
news:13tj3qjrb5cp661@corp.supernews.com...
> In article <fra6e9$v1i$1@snarked.org>,
> D. Stussy <replies@newsgroups.kd6lvw.ampr.org> wrote:
> >"Robert Bonomi" <bonomi@host122.r-bonomi.com> wrote in message
> >news:13tgph9vvhmi67@corp.supernews.com...
> >> In article <fr9bfc$mv4$1@snarked.org>,
> >> D. Stussy <replies@newsgroups.kd6lvw.ampr.org> wrote:
> >> >"Robert Bonomi" <bonomi@host122.r-bonomi.com> wrote in message
> >> >news:13tg4kq4kaic6d0@corp.supernews.com...
> >> >
> >> >> Doing some basic 'sanity checks' on the HELO string -- e.g.
rejecting
> >any
> >> >> outside machine that HELOs as _your_ network, disallowing anything
that
> >> >> starts with an '-', is all-numeric, looks like a dotted quad {with
or
> >> >without
> >> >> surrounding brackets}, an unqualified 'localhost' or
> >> >'localhost@localdomain',
> >> >> requiring at least 1 dot in the string, and that there be a valid
TLD
> >> >_after_
> >> >> the last dot -- =will= trap a lot of bad stuff, with only a
_very_rare_
> >> >impact
> >> >> on legitimate mail.
> >> >
> >> >Why should a "dotted-quad inside brackets" be rejected?
> >>
> >> I see no need to repeat myself. Read the words after "the last
dot --',
> >> and see if you can figure it out.
> >
> >"localhost" with NO dots is valid.
>
> So?
>
> The 'object of the game' is to identify things the bad guys regularly do
> that the 'good guys' ALMOST NEVER do. "Perfection" is not a
pre-requisite.

However, standards compliance is also a requirement. If you want to break
the rules, be prepared for the consequences....

> BTW, whatinthe hell does the fact that '"localhost" with NO dots is valid'
> have to do with your challenge 'why should a "dotted-quad inside brackets"
be
> rejected?'

You kept stating that there must be at least one period and that there be a
valid TLD. Both of those ("localhost" and a bracketed IP address) are cases
that FAIL your check yet are valid, and may be common.

> Or did you get distracted by the language in the 'marker' that I suggested
> you should read AFTER?
>
> >The check that I think you're suggesting should not be done ...
>
> You're making value judgements; I simply described some things that _are_
> EFFECTIVE.

But are also in contradiction of the accepted standards.

> > ..on the HELO
name
> >but instead on the hostname retrieved based on a reverse lookup of the IP
> >obtained from the incoming IP socket.
>
> Feel free to do things your way on your machines. You'll get a humongous
> number of false-positives when you apply them to the reverse lookup of a
> connection from 127.1 <grin>
>
> >> > That's what
the
> >> >RFCs say is supposed to be issued if no hosthame is assigned.
> >>
> >> So?
> >>
> >> If the admin of the box in question has not set up a hostname, what are
> >the
> >> odds that he _intends_ to be using it for outgoing mail?
> >
> >Low but not zero.
>
> BINGO! That _is_ why one uses it. 'Perfection' is not a requirement,
>
> Except in a few extraordinary situations, it is "for practical purposes,
> equivalent to zero". And, in those "special cases" the mail admins are
> fully aware of the circumstances involved, and can tailor *their* filter
> rules accordingly.
>
> >> If the admin *didn't* intend to use it for outgoing mail, what are the
> >odds
> >> that the mail from that box is unwelcome?
> >
> >Non-sequtur. Certain versions of Linux have an auto-reporting feature
(e.g.
> >"the Linux Counter") when they're installed (or an option). A system
might
> >not yet be configured when that mail is issued back to the distributor's
> >counter site. There's a valid example for you that breaks your
assumption.
>
> "Male bovine excretement".

Real world example that occurs. It's not hypothetical. The Slackware
distribution of Linux does it.

> First, for your hypothetical to happen, that admin must have placed the
box
> 'on-line' with open external connectivity *BEFORE* it was configured.
>
> Second, I make no 'assumption' that _all_ mail from 'localhost' (or
similar) is
> unwanted at EVERY site. You will note that I expressly noted the
"possibility"
> of legitimate mail getting trapped. The fact remains that if one
considers
> _all_ the special-case mail you describe above (which goes to a _very_
small
> number of sites) vs the number of messages received from 'apparently
> unconfigured' machines at -all- locations, the 'valid' ones are an
infinitesimal
> portion of the whole. If one eliminates from consideration those few
sites
> that _know_ to expect such traffic, then the share of legitimate messages
with
> the stigmata in question is probably in the femto-percent range.
>
>
> Admittedly, someone _expecting_ mail from such 'incompletely configured'
> systems would need to run configurations _specific_to_their_needs_. Of
> course, that applies to anyone with known 'unique' incoming mail
> characteristics -- e.g. a sex therapist would lose an awful lot of 'valid'
> email by using any standard anti-pornography filter.
>
> The rarity of such special cases proves the 'general use' validity of the
> rule.
>
>
> >dotted-quad
> >> >not enclosed by brackets is a syntax error and should be rejected.
> >>
> >> Not necessarily. it could be 'pseudo-random garbage' that just happens
to
> >> look like a dotted quad. If the originator _intends_ it to be taken as
> >> 'naming' a machine without an assigned name, then yes, the dotted-quad
> >> representation of the IP address must be enclosed in the specified
> >symbols.
> >> If the machine IS named, and has a 'name' with just numeric parts, then
> >> no bracketing symbols are appropriate.
> >
> >If it's not bracketed, then it's a hostname. A hostname containing no
> >alphabetics is invalid.
>
> Wrong. Invalid in DNS, yes. but only there.

Invalid under RFC 2822 as well.

> >> If one requires a dot, and a _valid_ TLD suffix, an un-bracketed
> >dotted-quad
> >> will fail that test, as will unqualified 'localhost', '@localdomain',
and
> >> '@local.domain'.
> >
> >So will a bracketed IP address unless you test for it. Furthermore, IPv6
> >addresses may not have any periods.
>
> Yup. and *all* are symptomatic -- to the =VAST= majority of
mail-receiving
> systems -- of a sending system that the admin does not intend to be
sending
> mail to arbitrary addresses.
>
> >> >"Localhost" by itself is also permitted, but only if it's truly one's
> >self.
> >>
> >> Since the originating machine is purportedly using its
> >"preferred"/"primary"
> >> name as the HELO id, a 'legitimate' use of that name would imply no
> >> network connections other than 127.0.0.1, and thus there would -never-
be
> >> any point to, nor benefit from, checking the HELO string. <grin>
> >
> >"localhost" could be presented on a connection coming from ANY of the
> >machine's interfaces, but I agree that such should only occur on the
> >loopback interface.
>
> By _YOUR_ interpretation of the 'rules', the HELO name must be the
'preferred'
> name of the machine, regardless of the interface. Therefore, if
'localhost'
> _is_ the 'offered' name, that machine -- since it's _preferred_ name is
> meaningful _only_ to itself -- had better _not_ have any other interface
> names, interfaces, or connectivity. <grin>

True, but note that sendmail does include "localhost" in its class "w" of
local machine names by default. It's there because it can happen.

> If a machine with a 'preferred' name of "localhost" _does_ have other
> connectivity, then either the admin explicitly intends for that machine
> _not_ to communicate with the outside world, *or* the box is so
incompetently
> configured that it is likely many of: 'owned', 'an open relay', 'a
backscatter
> source', part of a 'botnet', spreading viruses, etc.,etc., ad nauseum and
> I don't want *anything* to do with it. _Either_way_, rejecting
'localhost'
> is entirely sensible.

It certainly is - in that you seem so lame, your server SHOULD reject your
own mail.