"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.