IP addresses in helo

IP addresses in helo

Is it safe (or mostly safe) to simply block attempts to deliver mail with a helo that is only an IP address? (I am talking about only on postfix/stmpd and obviously not on postfix/submit or related).

I have about 50,000 NOQUEUE reject from "helo=<[193.32.160.151]>" over the last week, for example. I see very few otherwise, and all are obviously spam with return addresses like [hidden email] or [hidden email].

Re: IP addresses in helo

Hi,

>
> Is it safe (or mostly safe) to simply block attempts to deliver mail
> with a helo that is only an IP address? (I am talking about only on
> postfix/stmpd and obviously not on postfix/submit or related).
>

No it is not, it's a RFC violation. The string that follows HELO/EHLO is
purely informational, it should not be used for any filtering purpose.
If you use it for this, you'll end up rejecting legitimate emails.

Re: IP addresses in helo

Is it safe (or mostly safe) to simply block attempts to deliver mail with a helo that is only an IP address? (I am talking about only on postfix/stmpd and obviously not on postfix/submit or related).

I have about 50,000 NOQUEUE reject from "helo=<[193.32.160.151]>" over the last week, for example. I see very few otherwise, and all are obviously spam with return addresses like [hidden email] or [hidden email].

Interesting idea. But I checked my records and - although YMMV - for us it would have a lot of false positives. (BTW I couldn't do this through mail logs because mine don't record the helo except when an incoming email is rejected.)

Re: IP addresses in helo

On 18 Nov 2019, at 05:22, Gregory Heytings <[hidden email]> wrote:
>> Is it safe (or mostly safe) to simply block attempts to deliver mail with a helo that is only an IP address? (I am talking about only on postfix/stmpd and obviously not on postfix/submit or related).
>>
>
> No it is not, it's a RFC violation.

I know it’s an RFC violation, but I see no email that is delivered with a bare IP helo that is legitimate. And I reject TFC compliant mails all the time. In fact, the vast majority of mail that is attempted on my server is RFC compliant and rejected.

> The string that follows HELO/EHLO is purely informational, it should not be used for any filtering purpose. If you use it for this, you'll end up rejecting legitimate emails.

How much legitimate mail do you get with an IP helo?

--
"Love is the triumph of imagination over intelligence." - H. L. Mencken

Re: IP addresses in helo

>>Is it safe (or mostly safe) to simply block attempts to deliver mail
>>with a helo that is only an IP address? (I am talking about only on
>>postfix/stmpd and obviously not on postfix/submit or related).

On 18.11.19 13:22, Gregory Heytings wrote:
>No it is not, it's a RFC violation. The string that follows HELO/EHLO
>is purely informational, it should not be used for any filtering
>purpose.

can you provide RFC and section?

AFAIK the only violation is if you reject based on HELO string not
equivalent to reverse resolution of connecting client and other helo string
rejections are fine from RFC point of view.

Re: IP addresses in helo

>
> I know it’s an RFC violation, but I see no email that is delivered with
> a bare IP helo that is legitimate.
>

That might be your experience, but RFC 2821 (3.6) and RFC 5321 (2.3.5 and
4.1.4) explicitly state that an address literal can be used after
HELO/EHLO. So it's a RFC violation to reject mail for that sole reason.

>
> How much legitimate mail do you get with an IP helo?
>

Two other users replied to your question. For real-world mail servers, my
experience is that the only safe restriction (safe = no false positives)
is "reject_unknown_reverse_client_hostname". With other restrictions,
your users will never receive emails from administrations, schools,
hospitals, etc., not even in their spam box. Rejecting mail is an extreme
measure, see RFC 5321 (7.9): "considerable care should be taken and
balance maintained if a site decides to be selective about the traffic it
will accept and process."

Re: IP addresses in helo

> Is it safe (or mostly safe) to simply block attempts to deliver mail
> with a helo that is only an IP address? (I am talking about only on
> postfix/stmpd and obviously not on postfix/submit or related).

Yes.

There are cases of Special Needs Nodes (printers, antique Cisco gear,
random IoT devices) which may not be able to do port 587 or 465 and
can't contain the concept of their very own real hostname. Generally
these are rare enough these days that it is feasible to handle them as
exceptions.

Re: IP addresses in helo

> Hi,
>
>>
>> Is it safe (or mostly safe) to simply block attempts to deliver mail
>> with a helo that is only an IP address? (I am talking about only on
>> postfix/stmpd and obviously not on postfix/submit or related).
>>
>
> No it is not, it's a RFC violation.

So what?

RFCs are not laws. There are no RFC police.

> The string that follows HELO/EHLO is purely informational, it should
> not be used for any filtering purpose. If you use it for this, you'll
> end up rejecting legitimate emails.

Hasn't happened for me in over a decade. I use a variety of patterns to
match against the HELO argument and reject on that basis, of which a few
(e.g. /.*\.local$/) have needed special exemptions for specific
persistently stupid systems. I haven't needed to add to the special
cases since 2008.

e.g.:

# Patterns used only by bad actors.
/^local$/ REJECT I don't know you
/localhost$/ REJECT you are not me
/[REDACTED: INTERNAL RFC1918 RANGE PATTERN]/ REJECT you are not me
/[REDACTED: EXTERNAL ADDRESS RANGE PATTERN]/ REJECT you are not me
/127\.0\.0\.[0-9]/ REJECT you are not me

# My public MX names, which are not used internally
/^toaster.scconsult.com$/ REJECT you are not me
/^sc1.scconsult.com$/ REJECT you are not me

# My public mail domains, which are not the names of any actual hosts
/^scconsult.com$/ REJECT you are not me
/^billmail.scconsult.com$/ REJECT you are not me

# Spamming botnets
/^friend$/ REJECT You're not my friend
/^DM$/ REJECT You are not the DM
/^mail.com$/ REJECT Suresh says no one is mail.com
/^-/ REJECT Try an imaginary number instead of a negative one.

# Various commonly-seen bad patterns that may need exemptions (above)
/.*\.local$/ REJECT You can't call yourself local when introducing
yourself to the world.
/.*\.localdomain$/ REJECT You can't call yourself local when
introducing yourself to the world.
/^[^.]*$/ REJECT Care to qualify that claim?
/^[^a-z]*$/ REJECT USE YOUR WORDS LIKE A GROWN-UP!
#
# Places I absolutely do not want any mail from.
[REDACTED: VALID-ISH NAMES IN NOMINALLY LEGIT DOMAINS THAT ONLY SEND
SPAM]

Re: IP addresses in helo

> Hi,
>
>>
>> I know it’s an RFC violation, but I see no email that is delivered
>> with a bare IP helo that is legitimate.
>>
>
> That might be your experience, but RFC 2821 (3.6) and RFC 5321 (2.3.5
> and 4.1.4) explicitly state that an address literal can be used after
> HELO/EHLO. So it's a RFC violation to reject mail for that sole
> reason.
>
>>
>> How much legitimate mail do you get with an IP helo?
>>
>
> Two other users replied to your question. For real-world mail
> servers, my experience is that the only safe restriction (safe = no
> false positives) is "reject_unknown_reverse_client_hostname".

Irrelevant to HELO argument filtering.

> With other restrictions, your users will never receive emails from
> administrations, schools, hospitals, etc., not even in their spam box.

Rejecting mail is a far better choice than delivering to a 'spam box'
since most users never bother looking there for anything. Rejections at
least stand some chance of making enough noise on the sender side to get
misconfigurations fixed.

FWIW, across multiple mail systems and decades, I have never needed to
exempt external sources from a requirement that a HELO/EHLO argument
must contain letters and do not recall ever seeing a legitimate mail
source using an IP literal or bare IP in HELO/EHLO in cases where such a
restriction was impossible. Obviously your mail stream may differ,
particularly if you accommodate submission on port 25.

Re: IP addresses in helo

Bill Cole wrote:

> Rejecting mail is a far better choice than delivering to a 'spam box'
> since most users never bother looking there for anything. Rejections at
> least stand some chance of making enough noise on the sender side to get
> misconfigurations fixed.

IME exactly the opposite is true, because all too many automated notices
are fire-and-forget - the senders don't even have the infrastructure to
handle bounce messages, never mind bring them up to the attention of
someone who can fix things. Or the notices are sent entirely by hand,
but some "helpful" IT support monkey has gone and blacklisted all
postmaster notices (or worse, sent them to /dev/null automatically).

At least if the message gets misfiled in the recipient's spam folder
they've got some chance of finding the actual message, and a better
chance of then informing someone who can fix the misfiring filter.

We had a case recently where a customer's one-man-band IT "support
provider" couldn't seem to understand the idea that if our server tries
to pass on a message and gets:

550 Rejected for spammy content

back in a postmaster notice, any further investigation MUST be started
by the recipient, because it's the recipient's mail system doing the
rejecting.

They had a couple of examples of rejected messages sent through other
outbound servers to the same recipients, too, so it really was something
to do with the content of their mail, not some property of our mail
cluster. I have a feeling there will be Words Spoken when (almost
certainly not "if") their move to Office 365 doesn't fix the problem.

Relevant to rejecting emails. Perhaps I should have written "the only
safe reject restriction at that stage of the SMTP session". Once again,
the string that follows HELO/EHLO is purely informational, it should not
be used for filtering purpose.

The OP asked "is it safe", without explaining what "safe" means for him.
For me it means "safe in general", in particular for servers handling
large amounts of email.

>
> Rejecting mail is a far better choice than delivering to a 'spam box'
> since most users never bother looking there for anything. Rejections at
> least stand some chance of making enough noise on the sender side to get
> misconfigurations fixed.
>

IMO this is naive. As Kris Deugau wrote in most cases nobody ever looks
at that noise, your users will just not receive their email.

And for the particular question of the OP ("HELO <ip address>") there is
not even a reason to consider that it is a "misconfiguration", given that
what you call a "misconfiguration" is explicitly permitted by the
standards. I agree with you that "there are no RFC police". But the
purpose of RFCs is cooperation.

It is true indeed that most users do not look at their spam folder, but
they can (and should) be educated to do so, given that every spam
filtering system I know of has false positives.

On 18.11.19 18:10, Gregory Heytings wrote:
>Relevant to rejecting emails. Perhaps I should have written "the only
>safe reject restriction at that stage of the SMTP session". Once
>again, the string that follows HELO/EHLO is purely informational, it
>should not be used for filtering purpose.

Incorrect, content of helo might be safely used for filtering purposes.
hosts pretending to be you are safe to be rejected.

>The OP asked "is it safe", without explaining what "safe" means for
>him. For me it means "safe in general", in particular for servers
>handling large amounts of email.

Care must be taken about what is being rejected.

Examples are bogus or invalid helo (reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname), helo pointing to nonexistent hostname
(reject_unknown_helo_hostname) helo pretending to be the destination
domain/server (put your server name and IP here) and some others
("hotmail.com" hlo was common for spambots some time ago).

>>Rejecting mail is a far better choice than delivering to a 'spam
>>box' since most users never bother looking there for anything.
>>Rejections at least stand some chance of making enough noise on the
>>sender side to get misconfigurations fixed.

>IMO this is naive. As Kris Deugau wrote in most cases nobody ever
>looks at that noise, your users will just not receive their email.

A common answer to this is that the sender was supposed to get
error message. Since the message might be rejected anywhere between sender
and recipient, it's usually a must.

>And for the particular question of the OP ("HELO <ip address>") there
>is not even a reason to consider that it is a "misconfiguration",
>given that what you call a "misconfiguration" is explicitly permitted
>by the standards. I agree with you that "there are no RFC police".
>But the purpose of RFCs is cooperation.
>
>It is true indeed that most users do not look at their spam folder,
>but they can (and should) be educated to do so, given that every spam
>filtering system I know of has false positives.

If you want to receive any possible spam and send them to spam folder, it's
completely up to you. Just note that people with too many spams in spam folder
may start ignoring it and complain...

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
On the other hand, you have different fingers.

Re: IP addresses in helo

Is it safe (or mostly safe) to simply block attempts to deliver mail with a helo that is only an IP address? (I am talking about only on postfix/stmpd and obviously not on postfix/submit or related).

I have about 50,000 NOQUEUE reject from "helo=<[193.32.160.151]>" over the last week, for example. I see very few otherwise, and all are obviously spam with return addresses like [hidden email] or [hidden email].

Interesting idea. But I checked my records and - although YMMV - for us it would have a lot of false positives. (BTW I couldn't do this through mail logs because mine don't record the helo except when an incoming email is rejected.)

Correction: actually I can't find any false-positives in my records (after I eliminated the false-false-positives...)

Re: IP addresses in helo

>
> Hi,
>
>>
>> I know it’s an RFC violation, but I see no email that is delivered
>> with a bare IP helo that is legitimate.
>>
>
> That might be your experience, but RFC 2821 (3.6) and RFC 5321 (2.3.5
> and 4.1.4) explicitly state that an address literal can be used after
> HELO/EHLO. So it's a RFC violation to reject mail for that sole reason.

I don't believe the RFC has any MUST about the receiver having to accept
any specific message of this kind, thus it isn't an RFC violation to
reject it. (See your next comment quoting the RFC which admit that it is
allowed (if discouraged) for a site to be selective on what mail it accepts.

>
>>
>> How much legitimate mail do you get with an IP helo?
>>
>
> Two other users replied to your question. For real-world mail
> servers, my experience is that the only safe restriction (safe = no
> false positives) is "reject_unknown_reverse_client_hostname". With
> other restrictions, your users will never receive emails from
> administrations, schools, hospitals, etc., not even in their spam
> box. Rejecting mail is an extreme measure, see RFC 5321 (7.9):
> "considerable care should be taken and balance maintained if a site
> decides to be selective about the traffic it will accept and process."
>
> Gregory

Re: IP addresses in helo

> On 18.11.19 18:10, Gregory Heytings wrote:
>> Bill Cole wrote:
>>> Rejecting mail is a far better choice than delivering to a 'spam box'
>>> since most users never bother looking there for anything. Rejections
>>> at least stand some chance of making enough noise on the sender side
>>> to get misconfigurations fixed.
>
>> IMO this is naive. As Kris Deugau wrote in most cases nobody ever
>> looks at that noise, your users will just not receive their email.
>
> A common answer to this is that the sender was supposed to get
> error message. Since the message might be rejected anywhere between sender
> and recipient, it's usually a must.

Yes, they're *supposed to* get an error. But some end users have
blackholed postmaster notices, and many end users have trouble making
sense of even the best postmaster notices (assuming they don't just
treat the error as a reply, and continue their conversation like nothing
went wrong - yes, I see this at least a couple times a month). If a
message is rejected with an error message that reads, more or less
literally:

550 Rejected for spammy content

how is the sender supposed to make any kind of sense of what, exactly,
they need to do to get their message through?

At least with most of the DNSBL rejections, there's usually a link to
the list's website with some reference information the sender can take
to their provider, and ask "Hey, why are you on this blacklist? It's
preventing me from sending mail!". (Not that that helps all the time,
due to shared hosting and the unavoidable mystery meat so many
desktop/mobile clients stuff into their HTML formatting.)

> If you want to receive any possible spam and send them to spam folder, it's
> completely up to you.

*nod* "Your system, your rules."

> Just note that people with too many spams in spam folder
> may start ignoring it and complain...

*sigh* All too true, although not just with "many" spams. I've lost
count of the number of customers who have complained about maybe 5-10
messages in the Spam folder over the course of a week:

"Why is this spam in the Spam folder?!?"
"Er... because... it's not in your Inbox?"