2
Suddenly SmarterMail reports too many bad commands
Question asked by Batric Batric - 1/28/2015 at 3:30 PM
Unanswered
2 days ago, SmarterMail reported 845 bad commands in "SMTP In Errors" section.
Yesterday the number increased to 2.861 and today it's already on 9.089.
 
I suppose this wastes server resources, and would like to know if there is anything I should and I can do about it.
 
Is there anything I can do with the number of "Bad Commands" that were logged in "SMTP In Errors" section? Does SmarterMail block them automatically? Can this impose a security or DDOS risk?
 
Thanks!
 

13 Replies

Reply to Thread
0
Batric Batric Replied
Any ideas about this? Can't believe that on official SmarterMail forums noone can answer this.
2
Steve Reid Replied
If you need help right away then open a support ticket.
0
Batric Batric Replied
Thanks for the message, but I don't need help - rather an explanation on what does it mean. Online KB doesn't really have it explained.
0
Steve Reid Replied
Check your logs?
0
Nathalie V Replied
agreed
0
Bruce Barnes Replied
Are you under a DDoS or BRUTE PASSWORD ATTACK?
Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting
0
Nathalie V Replied
What logs even show if this was the case (if it happened earlier and not in real time). There are "Abuse Detection Rules" but there doesn't seem to be anywhere where it is logged when an IP is temporarily blocked for hitting an abuse detection rule.

In our case, a user is doing a mail merge sending to about 70 recipients. Smartermail is configured to allow up to 250 recipients. After 18 recipients the connection was terminated with this error (too many bad commands). This isn't hitting a quota and there is no way it seems to get more info about this problem.
0
Bruce Barnes Replied
Natalie:
 
If you have your SMTP LOTS set to DETAILED, you should be able to see a string of connect/disconnect, with no other activity, something similar to the following:
 
[2015.08.21] 05:40:34 [74.87.35.154][33754200] rsp: 220 fifi.chicagonettech.com  Fri, 21 Aug 2015 10:40:34 +0000 UTC | SmarterMail Enterprise 14.2.5710.19326
[2015.08.21] 05:40:34 [74.87.35.154][33754200] connected at 8/21/2015 5:40:34 AM
[2015.08.21] 05:40:36 [74.87.35.154][33754200] cmd: EHLO X5J& ??
[2015.08.21] 05:40:36 [74.87.35.154][33754200] rsp: 250-fifi.chicagonettech.com Hello [74.87.35.154]250-SIZE 52428800250-AUTH CRAM-MD5250-STARTTLS250-8BITMIME250 OK
[2015.08.21] 05:40:36 [74.87.35.154][33754200] cmd: MAIL FROM:<<html>
[2015.08.21] 05:40:36 [74.87.35.154][33754200] cmd: <head><title>403 Forbidden</title></head>
[2015.08.21] 05:40:36 [74.87.35.154][33754200] rsp: 500 command unrecognized
[2015.08.21] 05:40:36 [74.87.35.154][33754200] cmd: <body bgcolor="white">
[2015.08.21] 05:40:36 [74.87.35.154][33754200] rsp: 500 command unrecognized
[2015.08.21] 05:40:36 [74.87.35.154][33754200] cmd: <center><h1>403 Forbidden</h1></center>
[2015.08.21] 05:40:36 [74.87.35.154][33754200] rsp: 500 command unrecognized
[2015.08.21] 05:40:36 [74.87.35.154][33754200] cmd: <hr><center>nginx/1.2.1</center>
[2015.08.21] 05:40:36 [74.87.35.154][33754200] Closing transmission channel: too many bad commands
[2015.08.21] 05:40:36 [74.87.35.154][33754200] rsp: 421 Too many bad commands, closing transmission channel
[2015.08.21] 05:40:36 [74.87.35.154][33754200] disconnected at 8/21/2015 5:40:36 AM
[2015.08.21] 05:40:38 [74.87.35.154][33754200] rsp: 554 Sending address not accepted due to spam filter
[2015.08.21] 05:40:38 [74.87.35.154][33754200] Mail rejected due to SMTP Spam Blocking: _SPF (Fail), Barracuda - BRBL, CBL - Abuse Seat - DO NOT USE FOR OUTGOING!, HostKarma - Blacklist, SPAMHAUS - XBL 1
 
Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting
0
Nathalie V Replied
Everything appeared normal in our log up until the "421 Too many bad commands, closing transmission channel"

This as a mail-merge to over 70 recipients (Smartermail is configured to allow 250 recipients so this isn't hitting a quota)

This is just a snippet, but after around 18 recipients is when the error occurs:

Line 382400: 16:47:03 [73.44.183.227][31907419] cmd: MAIL FROM: <sender@email.com>
Line 382401: 16:47:03 [73.44.183.227][31907419] rsp: 250 OK <sender@email.com> Sender ok
Line 382402: 16:47:03 [73.44.183.227][31907419] cmd: RCPT TO: <xxxxx@xxx1.net>
Line 382403: 16:47:03 [73.44.183.227][31907419] rsp: 250 OK <xxxxx@xxx1.net> Recipient ok
Line 382404: 16:47:03 [73.44.183.227][31907419] cmd: RSET
Line 382405: 16:47:03 [73.44.183.227][31907419] rsp: 250 OK
Line 382406: 16:47:03 [73.44.183.227][31907419] cmd: MAIL FROM: <sender@email.com>
Line 382407: 16:47:03 [73.44.183.227][31907419] rsp: 250 OK <sender@email.com> Sender ok
Line 382408: 16:47:03 [73.44.183.227][31907419] cmd: RCPT TO: <xxxxx@xxx2.net>
Line 382409: 16:47:03 [73.44.183.227][31907419] rsp: 250 OK <xxxxx@xxx2.net> Recipient ok
Line 382410: 16:47:03 [73.44.183.227][31907419] cmd: RSET
Line 382411: 16:47:03 [73.44.183.227][31907419] rsp: 250 OK
Line 382412: 16:47:04 [73.44.183.227][31907419] cmd: MAIL FROM: <sender@email.com>
Line 382413: 16:47:04 [73.44.183.227][31907419] rsp: 250 OK <sender@email.com> Sender ok
Line 382414: 16:47:04 [73.44.183.227][31907419] cmd: RCPT TO: <xxxxx@xxx3.net>
Line 382415: 16:47:04 [73.44.183.227][31907419] rsp: 250 OK <xxxxx@xxx3.net> Recipient ok
Line 382416: 16:47:04 [73.44.183.227][31907419] cmd: RSET
Line 382417: 16:47:04 [73.44.183.227][31907419] rsp: 250 OK
Line 382418: 16:47:04 [73.44.183.227][31907419] cmd: MAIL FROM: <sender@email.com>
Line 382419: 16:47:04 [73.44.183.227][31907419] rsp: 250 OK <sender@email.com> Sender ok
Line 382422: 16:47:04 [73.44.183.227][31907419] cmd: RCPT TO: <xxxxx@xxx4.net>
Line 382423: 16:47:04 [73.44.183.227][31907419] rsp: 250 OK <xxxxx@xxx4.net> Recipient ok
Line 382427: 16:47:05 [73.44.183.227][31907419] cmd: RSET
Line 382428: 16:47:05 [73.44.183.227][31907419] rsp: 250 OK
Line 382444: 16:47:05 [73.44.183.227][31907419] cmd: MAIL FROM: <sender@email.com>
Line 382445: 16:47:05 [73.44.183.227][31907419] rsp: 250 OK <sender@email.com> Sender ok
Line 382446: 16:47:05 [73.44.183.227][31907419] cmd: RCPT TO: <xxxxx@xxx5.net>
Line 382447: 16:47:05 [73.44.183.227][31907419] rsp: 250 OK <xxxxx@xxx5.net> Recipient ok
Line 382453: 16:47:05 [73.44.183.227][31907419] cmd: RSET
Line 382454: 16:47:05 [73.44.183.227][31907419] rsp: 421 Too many bad commands, closing transmission channel
Line 382455: 16:47:05 [73.44.183.227][31907419] disconnected at 8/12/2015 4:47:05 PM

0
Bruce Barnes Replied

Line 382453: 16:47:05 [73.44.183.227][31907419] cmd: RSET
Line 382454: 16:47:05 [73.44.183.227][31907419] rsp: 421 Too many bad commands, closing transmission channel
is coming from the RECIPIENT'S MAIL SERVER and is not a SmarterMail issue.
 
The receiving mail server has decided to throttle how many messages you can send in a given day.
 
If you do not have DomainKeys, DKIM, SPF, rDNS and DMARC setup, along with proper FEEDBACK LOOPS., you WILL be throttled now.
 
This is very clearly stated in YAHOO!, GMAIL. OUTLOOK.COM (which now handles all of the Microsoft e-mail services), and about 15 other ISPs.
 
Make certain your customers have both ACCEPTABLE USE and PRIVACY POLICY pages,for EVERY HOSTED DOMAIN, on their WEBSITES - YAHOO will manually check for these: on your CUSTOMER'S WEBSITES, not on yours.

They will also need POSTMASTER and ABUSE aliases or accounts setup:  These should point to a valid, WORKING e-mail address that YOU, as the SmarterMail server operator, respond to, and will be used to setup your FEEDBACK LOOPS.

Finally, setup DMARC and USE IT.  It will prevent you from being JOE-JOBBED and that will prevent you from becoming listed on BACKSCATTER.ORG
 
 
E-Mail is no longer set it and forget it.  It requires a lot of work to setup each domain (and control panels do not do a good job of setting it up) and also requires a lot of day-to-day maintenance work.
 
SmarterMail makes the job a lot easier, but only if you take the time to properly setup the hosted domains, all of the associated records, and make certain they are all in compliance and STAY in compliance.
 
Remember, all records in a list MUST now be DOUBLE OPT-IN CONFIRMED and, if they bounce, or request removal, must be removed in THREE OR FEWER BUSINESS DAYS.  
 
Remember, too, that when someone requests removal you MUST remove them and are not allowed to ask why.
Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting
0
Nathalie V Replied
Thanks Bruce, but the thing is these recipients were all from different domains (it wasn't going to just one recipient mail server).

From the recipients before the connection ended there was only one going to a free email address. Two were to different cities .rr.com and the rest were just differnet ISPs (att.net, or company domains)

The sending stopped after 18 recipients out of approx 70.
0
Employee Replied
Employee Post
Nathalie, how do you have your email harvesting abuse detection rule(s) set up?  If too many MAIL FROM: and RCPT TO: commands are issued and a RSET issued without sending any DATA, it could be "flagged" as harvesting and a 421 given and transmission closed.  This is actually a technic that many spammers use: issue a MAIL FROM: and RCPT TO: to see if they receive a 250 OK.  If not, they scratch the name off their lists; if so, they now know a god email.  They'll do the RCPT TO: and issue a RSET without send any DATA.
0
Nathalie V Replied
Hi Robert, we have the "Bad SMTP Sessions (Harvesting)" set to a count of 20.

Isn't this supposed to be counting unauthenticated requests though? Our user authenticated against the server to send these mails.

How do we allow a large number of recipients then without triggering the harvesting block?

Reply to Thread