> On 30 Dec 2019, at 23:46, Viktor Dukhovni <postfix-us...@dukhovni.org > <mailto:postfix-us...@dukhovni.org>> wrote: > > On Mon, Dec 30, 2019 at 11:32:11PM +0100, Gerben Wierda wrote: > >> Now that Finally have a postfix back with actual logging, I noticed this in >> my log: >> >> Dec 30 23:26:09 mail postfix/postscreen[16020]: CONNECT from >> [182.99.42.88]:49546 to [192.168.2.66]:25 >> Dec 30 23:26:10 mail postfix/postscreen[16020]: PREGREET 14 after 0.26 from >> [182.99.42.88]:49546: EHLO ylmf-pc\r\n >> Dec 30 23:26:10 mail postfix/smtpd[16048]: connect from unknown[182.99.42.88] >> Dec 30 23:26:10 mail postfix/smtpd[16048]: lost connection after EHLO from >> unknown[182.99.42.88] >> Dec 30 23:26:10 mail postfix/smtpd[16048]: disconnect from >> unknown[182.99.42.88] ehlo=1 commands=1 > > Are the smtpd(8) connections on a different port? One might expect > postscreen to block clients that send EHLO before the greeting is > received. >
# SMTP on port 25, handled by postscreen before passing it on to # smtpd smtp inet n - n - 1 postscreen # smtpd, which listens on /opt/local/var/spool/postfix/smtpd smtpd pass - - n - - smtpd # -o receive_override_options=no_address_mappings # dnsblog, which listens on /opt/local/var/spool/postfix/dnsblog dnsblog unix - - n - 0 dnsblog # tlsproxy, which listens on /opt/local/var/spool/postfix/tlsproxy tlsproxy unix - - n - 0 tlsproxy # submission which listens on port 587: # TLS and authentication are required on this port submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_tls_auth_only=yes -o syslog_name=submission So, postscreen gets the smtp connection (port 25). smtpd listens directly on the submission port. (I have been wondering to use 465 again, since IANA has reassigned it for secure SMTP). >> And then lots of this. It goes on and on and on. > > Welcome to the Internet… Since 1990-1991 ;-) I know. > >> I was wondering (just curious) what these (Chinese) types are actually >> trying to do. It looks like polling based on the expectation that some >> other payload has corrupted my postfix. But I’m curious to what it >> really is (if known). > > It doesn't matter. > >> (Time to set a pf rule set on geolocation, I guess) > > I wouldn't bother, but since the host has no PTR record you can, > just in case, add: > > reject_unknown_reverse_client_hostname > > to your smtpd_client_restrictions. Yes. Hmm, does that come with a big risk for stopping legitimate mail? Probably yes given the amount of poorly written smtp clients on web sites. > > -- > Viktor.