Improving / fixing my helo_access restriction matches?

[jas...@mail-central.com]

I want to add a helo_access block entry for literal matches of "User". Because "user" is uesd all over the place, I want to make sure I don't screw this up.

Here are three instances that I'd like to match,

Jan 17 19:21:13 mail01 postfix/psint/smtpd[24295]: NOQUEUE: reject: EHLO from 75-145-96-164-Memphis.hfc.comcastbusiness.net[75.145.96.164]: 504 5.5.2 <User>: Helo command rejected: need fully-qualified hostname; proto=SMTP helo=<User>

Feb 04 12:07:27 mail01 postfix/postscreen[19582]: PREGREET 11 after 0.17 from [155.133.82.19]:49382: EHLO User\r\n

Mar 03 03:19:14 mail01 postfix/postscreen[3305]: NOQUEUE: reject: RCPT from [123.237.129.33]:49583: 550 5.7.1 Service unavailable; client [123.237.129.33] blocked using zen.spamhaus.org; from=<hindm...@votelori.com>, to=<exam...@example.com>, proto=ESMTP, helo=<User-PC>

In

postfix/helo_access

where I have

main.cf
smtpd_helo_restrictions =
check_helo_access lmdb:${config_directory}/helo_access
reject_non_fqdn_helo_hostname
reject_invalid_helo_hostname
...

is a match on

/^.*User.*$/ REJECT

incorrect or too-broad to match these, and not others?

I know those^ were already blocked, but some are sneaking through -- and I"m not yet entirely sure why or how.

Jason

[/dev/rob0]

On Fri, Apr 08, 2016 at 08:04:12AM -0700, jas...@mail-central.com wrote:
> I want to add a helo_access block entry for literal matches of
> "User". Because "user" is uesd all over the place, I want to make
> sure I don't screw this up.
>
> Here are three instances that I'd like to match,
>
> Jan 17 19:21:13 mail01 postfix/psint/smtpd[24295]: NOQUEUE:
> reject: EHLO from
> 75-145-96-164-Memphis.hfc.comcastbusiness.net[75.145.96.164]:
> 504 5.5.2 <User>: Helo command rejected: need fully-qualified
> hostname; proto=SMTP helo=<User>

Rejected by your smtpd's reject_non_fqdn_helo_hostname restriction.

> Feb 04 12:07:27 mail01 postfix/postscreen[19582]: PREGREET 11
> after 0.17 from [155.133.82.19]:49382: EHLO User\r\n

Rejected by postscreen as a pre-banner talker.

> Mar 03 03:19:14 mail01 postfix/postscreen[3305]: NOQUEUE:
> reject: RCPT from [123.237.129.33]:49583: 550 5.7.1 Service
> unavailable; client [123.237.129.33] blocked using
> zen.spamhaus.org; from=<hindm...@votelori.com>,
> to=<exam...@example.com>, proto=ESMTP, helo=<User-PC>

And that's the postscreen_dnsbl_threshold having been met. Also, a
different non-FQDN EHLO string.

> In
>
> postfix/helo_access
>
> where I have
>
> main.cf
> smtpd_helo_restrictions =
> check_helo_access lmdb:${config_directory}/helo_access
> reject_non_fqdn_helo_hostname
> reject_invalid_helo_hostname
> ...
>
> is a match on
>
> /^.*User.*$/ REJECT

"Some people, when confronted with a problem, think, 'I know, I'll
use regular expressions.'" Now they have two problems."
--atributed to Jamie Zawinski

> incorrect or too-broad to match these, and not others?

EHLO outbound-42.compuserv.com

Yes, compuserv is gone, but it's a nice illustration of how the
string, "user", can appear in a legitimate EHLO.

> I know those^ were already blocked, but some are sneaking
> through -- and I"m not yet entirely sure why or how.

I'm not either. Perhaps you should focus on the problem, and post
examples of it?
--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

[jas...@mail-central.com]

On Fri, Apr 8, 2016, at 08:22 AM, /dev/rob0 wrote:
...

> Rejected by your smtpd's reject_non_fqdn_helo_hostname restriction.

...

> Rejected by postscreen as a pre-banner talker.

...

> And that's the postscreen_dnsbl_threshold having been met. Also, a
> different non-FQDN EHLO string.

Yes, as I already said "I know those^ were already blocked"

That's not my question.

> Yes, compuserv is gone, but it's a nice illustration of how the
> string, "user", can appear in a legitimate EHLO.

This is a good example of my match being too broad, and exactly what I'm trying to avoid.

> I'm not either. Perhaps you should focus on the problem, and post
> examples of it?

My focus atm is strictly and only on what I asked about ... crafting the right HELO match for those three examples.

Jason

[/dev/rob0]

On Fri, Apr 08, 2016 at 08:55:13AM -0700,
jas...@mail-central.com wrote:
> My focus atm is strictly and only on what I asked about ...
> crafting the right HELO match for those three examples.

/^User[^\.]*/i REJECT your message here

A case-sensitive string that begins with "User" followed by zero or
more characters which are NOT a period. If this lookup follows the
reject_non_fqdn_helo_hostname restriction, it will never be used.

[jas...@mail-central.com]

On Fri, Apr 8, 2016, at 11:05 AM, /dev/rob0 wrote:
> /^User[^\.]*/i REJECT your message here

So it *is* true that that *starts* at the beginning of the line (and so the "^U"). That makes it easier to not fubar it.

> A case-sensitive string that begins with "User" followed by zero or
> more characters which are NOT a period.

I'm never sure whether that^ goes in an lmdb: table or a pcre: table. Looks like a regex to me ...

> If this lookup follows the
> reject_non_fqdn_helo_hostname restriction, it will never be used.

That's what I thought.

Now that I've 'discovered' the "xzegrep" util, searching logs & archives for multiple patterns just got easier.

TBH, the 'leaks' I've been seeing seem to be all old ... and a few in the last couple of weeks. But those are clustered around my other monkeying. Afaict, when I just site and watch, "reject_non_fqdn_helo_hostname" does what it's supposed to.

Thanks

Jason

[Bill Cole]

On 8 Apr 2016, at 11:22, /dev/rob0 wrote:

> EHLO outbound-42.compuserv.com

>
> Yes, compuserv is gone, but it's a nice illustration of how the
> string, "user", can appear in a legitimate EHLO.

Tangent: CompuServe was indeed bought by AOL via WorldCom and eventually
(just a few years ago... ) all their distinct services were killed off,
but AOL maintains the registration and DNS for compuserve.com and there
are in fact operational (ish) *.compuserve.com hosts.

On the other hand, compuserv.com is a different story, in that it is
registered to a domain broker and seems to be available for sale. I
expect it is massively overpriced.