I took a look at my postfix logs and I've noticed an odd occurrence lately: SMTP sessions that seem to end right after the RCPT TO, as such:postfix/smtpd[11333]: > unknown[XXX.XXX.238.86]: 220 [mydomain.com] ESMTP (Ubuntu)postfix/smtpd[11333]: < unknown[XXX.XXX.238.86]: EHLO LMSPC.[otherdomain.com]postfix/smtpd[11333]: > unknown[XXX.XXX.238.86]: 250-[mydomain.com]postfix/smtpd[11333]: > unknown[XXX.XXX.238.86]: 250-PIPELININGpostfix/smtpd[11333]: > unknown[XXX.XXX.238.86]: 250-SIZE 10240000postfix/smtpd[11333]: > unknown[XXX.XXX.238.86]: 250-ETRNpostfix/smtpd[11333]: > unknown[XXX.XXX.238.86]: 250-STARTTLSpostfix/smtpd[11333]: > unknown[XXX.XXX.238.86]: 250-ENHANCEDSTATUSCODESpostfix/smtpd[11333]: > unknown[XXX.XXX.238.86]: 250-8BITMIMEpostfix/smtpd[11333]: > unknown[XXX.XXX.238.86]: 250 DSNpostfix/smtpd[11333]: < unknown[XXX.XXX.238.86]: MAIL From:<tobyami@LMSPC.[otherdomain.com]>postfix/smtpd[11333]: > unknown[XXX.XXX.238.86]: 250 2.1.0 Okpostfix/smtpd[11333]: < unknown[XXX.XXX.238.86]: RCPT To:<[myusername]@[mydomain.com]>For comparison, this is what a normal session looks like in my logs:postfix/smtpd[31674]: > mail-wg0-f52.google.com[74.125.82.52]: 220 [mydomain.com] ESMTP (Ubuntu)postfix/smtpd[31674]: < mail-wg0-f52.google.com[74.125.82.52]: EHLO mail-wg0-f52.google.compostfix/smtpd[31674]: > mail-wg0-f52.google.com[74.125.82.52]: 250-[mydomain.com]postfix/smtpd[31674]: > mail-wg0-f52.google.com[74.125.82.52]: 250-PIPELININGpostfix/smtpd[31674]: > mail-wg0-f52.google.com[74.125.82.52]: 250-SIZE 10240000postfix/smtpd[31674]: > mail-wg0-f52.google.com[74.125.82.52]: 250-ETRNpostfix/smtpd[31674]: > mail-wg0-f52.google.com[74.125.82.52]: 250-ENHANCEDSTATUSCODESpostfix/smtpd[31674]: > mail-wg0-f52.google.com[74.125.82.52]: 250-8BITMIMEpostfix/smtpd[31674]: > mail-wg0-f52.google.com[74.125.82.52]: 250 DSNpostfix/smtpd[31674]: < mail-wg0-f52.google.com[74.125.82.52]: MAIL FROM:<[whatever]@gmail.com> SIZE=1774postfix/smtpd[31674]: > mail-wg0-f52.google.com[74.125.82.52]: 250 2.1.0 Okpostfix/smtpd[31674]: < mail-wg0-f52.google.com[74.125.82.52]: RCPT TO:<[my username]@[mydomain.com]>postfix/smtpd[31674]: > mail-wg0-f52.google.com[74.125.82.52]: 250 2.1.5 Okpostfix/smtpd[31674]: < mail-wg0-f52.google.com[74.125.82.52]: DATApostfix/smtpd[31674]: > mail-wg0-f52.google.com[74.125.82.52]: 354 End data with <CR><LF>.<CR><LF>postfix/smtpd[31674]: > mail-wg0-f52.google.com[74.125.82.52]: 250 2.0.0 Ok: queued as 6346912215Cpostfix/smtpd[31674]: < mail-wg0-f52.google.com[74.125.82.52]: QUITpostfix/smtpd[31674]: > mail-wg0-f52.google.com[74.125.82.52]: 221 2.0.0 ByeIt seems my server doesn't answer with an Ok once it gets a RCPT TO in the first case. Things just seem to...stop.It doesn't bother me too much since I still get mails, and occurrences like the former example seem to all come from IPs either without a reverse DNS or from weird domains; as such, I'm assuming they must be spam attempts.Still, I'm wondering what's happening here. I can't tell who's dropping the connection first, my server or the remote, nor can I tell why the connection would be dropped. If it's on my end, why is it dropped at this point, after the RCPT TO, and not before? If it's on the remote end, why drop it before sending anything, or even before letting my server respond?EDIT: It seems because smtpd was in verbose mode, it wasn't logging everything, ironically. After disabling verbose mode, I see it's actually rejecting those right after the RCPT TO. Why it wasn't logging that when it was told to be verbose is beyond me, though.
postfix logs: SMTP sessions stopping after RCPT TO
logs;email;postfix;smtp
It can be for a number of different reasons.I used to run these tests to see whether a mail server was configured properly (was it setup to accept mail for that particular domain. I had occurences when new mail servers weren't setup properly and then people complained that they hadn't received mail only to realise that they had misconfigured their won systems so I decided to do these tests from then on) prior to cutover on a mail server change.From a SPAM perspective it can be used to test whether the system is setup as an open relay (misconfigured) allowing for anyone to send email to anyone out on the Internet.http://en.wikipedia.org/wiki/Open_mail_relayFrom a security/intelligence perspective it can be used to determine whether a particular person still works with a firm by determining whether the email address is still present at a firm.The only other time when I've seen this type of anomaly is with improperly setup security devices, bugs within devices/software, bizarre DoS attacks, and also hardware failure.