Re: IETF Policy on dogfood consumption or avoidance - SMTP version

[Viktor Dukhovni <[e-mail]>]

On Mon, Dec 16, 2019 at 08:11:11AM -0800, Glen wrote:

> On Mon, Dec 16, 2019 at 7:43 AM Randy Bush <[e-mail]> wrote:
> >   o would it be technically easy for the smtp servers to accept ip
> >     literals in a conforming manner?  yes, this is a question for my
> >     esteemed friend glen
> 
> Extremely easy.  The statements already made about Postfix are
> correct.  There is a configuration file, with two lines in it:
> 
> /^[0-9.]+$/             550 RFC2821 violation
> /^\[[0-9.]+\]$/         550 RFC2821 violation

While the patterns look similar, the first one rejects non-compliant
"EHLO 192.0.2.1" and similar dotted quads (or more generally some
mixture of digits and dots), the second rejects RFC-compliant address
literals.  So at least the second message should probably be different,
if the rule is retained.

> Changing the messages may have a positive or negative security
> exposure in that it might either (a) send the message that we (the
> IETF) are watching and know what we're doing and scare attackers off,
> or (b) might cause attackers to abandon this channel (which at the
> moment could be a honeypot-esque bit bucket) and focus on other
> methods of attack.  But I think both of those things are extremely
> small side-effects.

In this case, Postfix already augments the message with sufficient
context to make the custom message text immaterial to everyone other
than RFC subject-matter experts.  The sender can determine that it is
the EHLO name that is being rejected.

    550 5.7.1 <[192.0.2.1]>: Helo command rejected: RFC2821 violation

But this being a community of RFC subject-matter experts, the text is
subject to further scrutiny.  It can be changed with no impact other
than addressing its correctness viz. the RFC.

> >   o what would the technical and/or security exposure or other
> >     downside(s) be of doing so?
> 
> These rules have been in place for roughly 10-ish years, as has
> already been explained by John.  They are in essence gateway checks,
> which occur before other measures like Postconfirm or Spamassassin see
> the messages.  On a given day, there are between 700 and 1000 incoming
> messages rejected by this rule.

The name "postconfirm" suggests a component that asks (purported)
senders of borderline messages to confirm their existence/intent to send
the message.  One should indeed strive to use that sparingly.

Or is this just Postfix sender address verification (SAV), which merely
checks that the MX hosts of the sender domain don't reject the sender
address?

> Removing the rules would increase the load on Spamassassin and - for
> that subset of those 1000 messages per day that pass through
> Spamassassin's upper threshhold - cause us to send out challenge
> emails to the (potentially forged) senders of all of those emails.

Here we get to the question of whether the second rule should be kept or
dropped.  Do you know which of the two accounts for the bulk of the
rejected traffic?  The rules could be moved below any RBL or other IP
reputation checks, below any RHSBL or other sender domain reputation
checks, but still above rules that would trigger "challenge messages".
Then their marginal utility would be more easily discerned.

If the challenge messages are generated after a message is accepted,
(with the message sitting in a quarantine queue waiting for the
verdict), then the HELO checks can be used quite late, at any point
before the message is accepted, which would again help to determine
whether other measures already in place largely obviate their need.

If you don't have SAV, you could even have:

    smtpd_data_restrictions =
        check_helo_access pcre:${config_directory}/helo.pcre

and defer the HELO checks to DATA, by which point all the RBL checks
have run, invalid recipients have been turned away, ...

Anyway, perhaps more than you wanted to know, or this list wants to
read.  But if you do want to explore your options further, you could ask
on the postfix-users list.

-- 
    Viktor.