On 2025-04-17 at 21:05:50 UTC-0400 (Thu, 17 Apr 2025 21:05:50 -0400)
Greg Klanderman via Postfix-users <g...@klanderman.net>
is rumored to have said:
> Hi Bill
>
> Thanks for your reply..
Always happy to be of help.
[...]
> OK:
>
> % postconf | grep 'postscreen_.*_\(enable\|action\)'
> [output order rearranged]
> # pre-greet parameters:
> postscreen_blacklist_action = enforce
> postscreen_dnsbl_action = ignore
> postscreen_greet_action = enforce
> # post-greet parameters:
> postscreen_bare_newline_action = ignore
> postscreen_bare_newline_enable = no
> postscreen_non_smtp_command_action = drop
> postscreen_non_smtp_command_enable = no
> postscreen_pipelining_action = enforce
> postscreen_pipelining_enable = no
>
> I have a hash: access list in postscreen_access_list, no dnsbls.
I believe that "postscreen_greet_action=enforce" is causing postscreen to do as
described in the documentation: proceeding to the stub SMTP engine so as to be
able to log the arguments to EHLO, MAIL, and RCPT.
> Here are two example log snippets:
>
> Apr 17 07:20:50 smtp2 postfix/postscreen[12005]: CONNECT from
> [3.139.99.213]:32858 to [10.10.0.5]:25
> Apr 17 07:20:50 smtp2 postfix/postscreen[12005]: PREGREET 128 after 0 from
> [3.139.99.213]:32858:
> \026\003\001\000{\001\000\000w\003\003\321\t\237\327G\336\205\220t\\\261!\351\237P\323\020Lh\
> 330\237
Cute. That looks like an attempt at immediate TLS. Not the work of a pro
spambot author...
> Apr 17 07:20:50 smtp2 postfix/postscreen[12005]: BARE NEWLINE from
> [3.139.99.213]:32858 after
> \026\003\001\000{\001\000\000w\003\003\321\t\237\327G\336\205\220t\\\261!\351\237P\323\020Lh\330
> \237\376\332\373T\035\310o\217\233k6\000\000\032\300/\300+\300\021\300\a\300\023\300\t\300\024\300
> Apr 17 07:20:50 smtp2 postfix/postscreen[12005]: COMMAND PIPELINING from
> [3.139.99.213]:32858 after ???:
> \000\005\000/\0005\300\022\000\n\001\000\0004\000\005\000\005\001\000\000\000\000\000\n\000\b\000\006\000\027\000\030\000\031\000\v\000\002\001\000\000\r\000\020\000\016\004\001\004\003\002\001\002\003\004\001\005\001\006\001\377\001\000\001\000
> Apr 17 07:20:50 smtp2 postfix/postscreen[12005]: HANGUP after 0.02 from
> [3.139.99.213]:32858 in tests after SMTP handshake
Basically, the client spewed garbage that happened to fit the newline and
pipelining tests, which were done because postscreen_greet_action is set to
'enforce' which allows progression to the (fake) SMTP chat, were the client
actually trying to do SMTP. In this case nothing will get logged for SMTP
parameters because the client is so poorly designed.
> and
>
> Apr 17 07:13:08 smtp2 postfix/postscreen[11985]: CONNECT from
> [3.139.99.213]:60458 to [10.10.0.5]:25
> Apr 17 07:13:08 smtp2 postfix/postscreen[11985]: PREGREET 170 after 0 from
> [3.139.99.213]:60458: GET / HTTP/1.1\r\nHost: 161.35.254.93:25\r\nUser-Agent:
> Mozilla/5.0 (Macintosh; Intel Mac OS
> X 10_15
> Apr 17 07:13:08 smtp2 postfix/postscreen[11985]: NON-SMTP COMMAND from
> [3.139.99.213]:60458 after CONNECT: GET / HTTP/1.1
> Apr 17 07:13:08 smtp2 postfix/postscreen[11985]: DISCONNECT
> [3.139.99.213]:60458
Another case of PREGREET catching a bot that's using the wrong protocol, in
this case plaintext HTTP. Bot authors generally aren't very sharp, but in this
instance there may still be a few cases where a proxy in front of postscreen is
misconfigured to also implement HTTP. It's a VERY old known misconfig that I
doubt any modern proxy software can do.
>>> I guess that is because of pre-greet commands that have been sent, and
>>> postscreen is trying to parse?
>
>> I can attest to the fact that this does not happen if you set
>> "postscreen_greet_action=drop." Looking at the docs to refresh my recall, it
>> appears that it may happen if you have 'enforce' or 'ignore' set for either
>> "before 220" test action, to allow postscreen to log the offered SMTP args.
>
> OK, I do have postscreen_greet_action = enforce.
>
> Is drop preferred? The README didn't seem to suggest a preference..
I think it's a very individual decision. I prefer drop for
postscreen_greet_action because I really don't care about cases like those
above where there's no hope of obtaining useful info and even for the bots that
do try to speak SMTP, I have no interest in using the data they would provide
in any way.
However, once upon a time before postscreen existed I managed a mail server for
the North America divisions of a large mature company. "Management" wanted
stats on who specifically was being targeted by spam, even spam which was not
accepted and quarantined (as that management preferred for 'suspect' mail) but
rejected before data because it was unequivocally unwanted. It was helpful for
me to know (because I had no choice) who was being targeted (and by which
purported senders) because they wanted to know. But even then I had a lot of
those garbage connections that spoke pure junk immediately, so I had to include
a "garbage session" stat to make everything add up.
>> I don't recall it ever coming up here, which seems odd.
>
>>> The POSTSCREEN_README states:
>>>
>>> | This test is opportunistically enabled when postscreen(8) has to use
>>> | the built-in SMTP engine anyway. This is to make postscreen(8) logging
>>> | more informative.
>>>
>>> for these settings, but it is not entirely clear what 'has to use'
>>> means here.
>
>> Usually it means that one of the "after 220" tests is enabled,
>
> That's how I'd originally read it, before noticing that I thought I
> had all the post- greet tests turned off but was seeing logging to the
> contrary.
>
>> but as I say
>> above, a careful re-reading of the docs makes me believe that unless you drop
>> the connection in postscreen, it continues into the stub SMTP engine and
>> eventually says '550' to avoid actually accepting mail.
>
> OK, do you read it to mean it always proceeds to the SMTP engine, even
> if all post-greet tests are disabled? Or would you think only if the
> client spoke before its turn?
Only if the client speaks too fast. If there's no violation of the "before 220"
tests, and no "after 220" tests are enabled, postscreen should pass the
connection on to a smtpd process rather than it's own internal accept-nothing
fake SMTP engine.
> I expected it to return 550 after the pre- greet phase if no post-
> greet tests are enabled.
Well, yes, but not all clients pay attention to SMTP responses. One trying TLS
or HTTP certainly will not. They just spew their data and leave.
> It is interesting, that under the heading 'When tests fail before the
> 220 SMTP server greeting', for the action 'enforce', it states 'and
> log the helo/sender/recipient information', which isn't expected to be
> available if the 550 response is sent before proceeding to post- greet
> tests when no post- greet tests are enabled.
And also is not available if the clients (as above) are not even trying to have
any sort of SMTP 'chat' but are doing something else that looks like disallowed
pipelining and/or bad commands.
>>> Are the action variables for these tests still applicable in the
>>> case where the tests are 'turned on opportunistically'?
>
>> That's what the docs say. Not explicitly, but logically.
>
> I could imagine that when turning on those tests 'opportunistically' for
> 'logging purposes', that you would use an action of ignore. It would
> seem highly unexpected to apply
>
> postscreen_non_smtp_command_action = drop
>
> when that test is not even enabled.
Hmmm... I disagree. I expect that any 'drop' action would take effect
immediately in any case, regardless of whether the test is being run
intentionally or opportunistically.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
