Yes, I did not advertise AUTH in my port 25 smtpd too. when telnet to my mail server, it produce like:
telnet 108.61.110.110 25 Trying 108.61.110.110... Connected to example.com. Escape character is '^]'. 220 example ESMTP Postfix ehlo 501 Syntax: EHLO hostname ehlo mail 250-mail.example 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250 SMTPUTF8 AUTH PLAIN 503 5.5.1 Error: authentication not enabled I am going to add some iptables rules to ban some ip now. ---- On 星期四, 20 十月 2016 14:13:26 -0700Bill Cole <postfixlists-070...@billmail.scconsult.com> wrote ---- On 20 Oct 2016, at 16:39, Keith Williams wrote: > No wait... What? > > This is no attack. Attack is when you try to break or enforce.. This > is a probe, and from the probe we can deduce from the reported > disconnect that 1. helo was tried, 2. no auth was attempted and 3, > quit was used. > > So a test for helo and quit? and no auth. No. The "auth=0/1" in the disconnect line means that Postfix received 1 authentication attempt but it failed. This was a "probe" to see if a particular user exists and has a particular password. > Someone is testing your IP and mail capibility.. perhaps>> Not stipulating that unauthorized "probes" are not also block-worthy, but this is a bit more. > On 20/10/2016 22:20, Bill Cole wrote: >> On 18 Oct 2016, at 20:45, Sebastian Nielsen wrote: >> >>> Its clear from the log, the attacker isn't even attemping to >>> authenticate (0 attempts). The attacker hasn't propably not even >>> realized he is connecting to a mail server. >> >> >> No. There's a jumble there, but at least one is a lame "attack" of a >> sort. The only *Postfix* messages were: >> >>> Oct 19 07:55:27 mail postfix/smtpd[9929]: connect from >>> unknown[216.15.186.126] >>> Oct 19 07:55:28 mail postfix/smtpd[9929]: disconnect from >>> unknown[216.15.186.126] helo=1 auth=0/1 quit=1 commands=2/3 >> >> *THAT* client tried to authenticate and failed. It's a CBL-listed IP >> on a chronically abuse-friendly network. >> >> The rest were all messages from Dovecot components, about failed SSL >> connections from a mix of IPs. Impossible to know what the reasons >> for those were without tracking down the person running the computer. >> >
