550 Outgoing SMTP is not allowed Error

Question asked by Todd Graf - 6/16/2015 at 12:25 PM

Unanswered

I have a client who is sending a relatively large amount of e-mail through one of their accounts. The volume of email exceeds our Abuse Detection settings so we added their IP to the whitelist in an attempt to bypass the restrictions we put on the rest of our users.

In spite of our best efforts they continue to get bounce backs when sending messages out with an error that reads as follows:

Could not deliver message to the following recipient(s):

Failed Recipient: recipient@domain.com

Reason: Remote host said: 550 Outgoing SMTP is not allowed

These errors are occurring for a variety of recipients on different domains so I have to imagine the issue is on our Smartermail server. I just can't figure out what it is! Below is an example SMTP log file showing that the message went out (unless I'm reading it incorrectly)

[2015.06.16] 13:00:54 [50.77.179.140][23350619] rsp: 220 mail.server.com
[2015.06.16] 13:00:54 [50.77.179.140][23350619] connected at 6/16/2015 1:00:54 PM
[2015.06.16] 13:00:54 [50.77.179.140][23350619] IP in whitelist
[2015.06.16] 13:00:54 [50.77.179.140][23350619] cmd: EHLO Menix
[2015.06.16] 13:00:54 [50.77.179.140][23350619] rsp: 250-mail.server.com Hello [50.77.179.140]250-SIZE 31457280250-AUTH LOGIN CRAM-MD5250-8BITMIME250 OK
[2015.06.16] 13:00:54 [50.77.179.140][23350619] cmd: AUTH LOGIN
[2015.06.16] 13:00:54 [50.77.179.140][23350619] rsp: 334 VXNlcm5hbWU6
[2015.06.16] 13:00:54 [50.77.179.140][23350619] Authenticating as sender@domain.com
[2015.06.16] 13:00:54 [50.77.179.140][23350619] rsp: 334 UGFzc3dvcmQ6
[2015.06.16] 13:00:54 [50.77.179.140][23350619] rsp: 235 Authentication successful
[2015.06.16] 13:00:54 [50.77.179.140][23350619] Authenticated as sender@domain.com
[2015.06.16] 13:00:54 [50.77.179.140][23350619] cmd: MAIL FROM:<sender@domain.com>
[2015.06.16] 13:00:54 [50.77.179.140][23350619] rsp: 250 OK <sender@domain.com> Sender ok
[2015.06.16] 13:00:54 [50.77.179.140][23350619] cmd: RCPT TO:<recipient@domain.com>
[2015.06.16] 13:00:54 [50.77.179.140][23350619] rsp: 250 OK <recipient@domain.com> Recipient ok
[2015.06.16] 13:00:54 [50.77.179.140][23350619] cmd: DATA
[2015.06.16] 13:00:54 [50.77.179.140][23350619] rsp: 354 Start mail input; end with <CRLF>.<CRLF>
[2015.06.16] 13:02:05 [50.77.179.140][23350619] rsp: 250 OK
[2015.06.16] 13:02:05 [50.77.179.140][23350619] Data transfer succeeded, writing mail to 78563200.eml
[2015.06.16] 13:02:05 [50.77.179.140][23350619] cmd: QUIT
[2015.06.16] 13:02:05 [50.77.179.140][23350619] rsp: 221 Service closing transmission channel
[2015.06.16] 13:02:05 [50.77.179.140][23350619] disconnected at 6/16/2015 1:02:05 PM

11 Replies

Reply to Thread

Todd Graf Replied

6/17/2015 at 1:37 PM

As it turns out IP whitelisting does not work for outbound mail, only for inbound. So whitelisting this particular user's IP address has no affect on their ability to bypass (or more accurately not bypass) the Abuse Detection - Internal Spammer limits.

The final outcome of this scenario is to either A. increase the limits of the Internal Spammer rule or B. Tell the customer they can no longer send large quantities of e-mails. Unfortunately both of those scenarios aren't ideal but we'll have to make them work.

Ronald Raley Replied

7/13/2015 at 8:53 AM

We are running into the same issue, but we just upgraded to SmarterMail 14. Do you think it is a SmarterMail 14 issue?

Bruce Barnes Replied

7/13/2015 at 11:55 AM

Anyone who sends large quantities of outbound messages to multiple users will want to do several things to make certain they are not blocked by receivers:

Ensure that you have all of your rDNS, SPF, DomainKey, DKIM, and DMARC records in place
Make certain that you have FEEDBACK LOOPS in place
Make certain that you have ABUSE and POSTMASTER e-mail addresses (or aliases) in place for EVERY hosted domain and you RESPOND to them when something is sent to them. These will also be used to communicate with you when setting up the FEEDBACK loops.
Make certain you DO NOT use CNAMES for any MAIL HOST. CNAMES are now prohibited for MX host records, and, if found in DNS records, some providers will no longer accept your e-mail. CNAMEs are prohibited in MX records according to RFC974, RFC1034 3.6.2, RFC1912 2.4, and RFC2181 10.3
Make certain that you have advance, written, permission to send to all of the recipients. While this is not, as of yet, a direct requirement of the US Can Spam Act, it is a requirement of the Canadian Can Spam Act, and, because so Blackberry uses SMTP servers in Vancouver BC, you should consider the fact that any message sent might be routed through Canada and go by the more restrictive Canadian Can Spam Act regulations.
Make certain you have both PRIVACY and ACCEPTABLE USE policies which are publicly visible on the website associated with the FQDN of your SmarterMail (or other) MX server (they will be checked by a human for your YAHOO! feedback loop and, if you don't have them, you won't be allowed a feedback loop!).
Make certain that the SENDER of the message is in full compliance of the business identification requirements of the CAN SPAM acts and has their complete contact information at the bottom of every outgoing message. This includes
- business name,
- business address,
- business telephone,
- e-mail, and
- website information.
Make certain you have a WORKING, OPT-OUT link in every bulk message you send. Bulk messages are considered to be any message sent to as few as 10 or more recipients by some countries.

For more information, see:

https://portal.chicagonettech.com/kb/a116/why-am-i-having-problems-getting-my-e-mail-delivered.aspx

and

https://portal.chicagonettech.com/kb/a151/smtp-sending-limit-and-email-rate-limits-for-isps.aspx

and

https://portal.chicagonettech.com/kb/a171/smartermail-antispam-settings-document.aspx

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

Ronald Raley Replied

7/13/2015 at 12:11 PM

Interestingly, I found that this issue was narrowed to a single user account. Other user accounts would send just fine. But if this particular user account tried to send anything, they received the undeliverable "550 Outgoing SMTP is not allowed".

Re-creating the user fixed this problem. A little scary, but it works for him now.

Scarab Replied

7/13/2015 at 2:03 PM

This seems to happen on some accounts after the USER STATUS field was added to the USERS screen. As you can choose between "Enabled", "Disabled and allow email" and "Disabled and don't allow email" it appears that post-upgrade occasionally some pre-existing users have the wrong selection enabled despite it displaying "Enabled". When you recreated the account it went to the default "Enabled". To avoid having to delete the account and recreate it, you should be able to select any other setting in USER STATUS and click on the [SAVE] button and then change the USER STATUS back to "Enabled" and click on [SAVE].

Ronald Raley Replied

7/14/2015 at 11:09 AM

Thank you so much! This is very valuable information. Do you happen to have any advice for us to be proactive and find these accounts? I would like to perform a text search through the XML files, but just don't know what I would search for.

Jairo Marques Replied

3/15/2016 at 2:44 PM

Try in <UserSettings>?

<isEnabled>True</isEnabled>
<canReceiveMail>True</canReceiveMail>

Scot Desort Replied

8/25/2016 at 9:23 AM

I am on 15.2 and have ONE user in a domain getting 550 OUTGOING SMTP NOT ALLOWED when sending through webmail. Only local email goes through.

I have edited the user and changed the status from ENABLED to DISABLED and back to ENABLED (saving after each change). No effect

I have edited the user and DISABLED OUTGOING SMTP on the SERVICE ACCESS tab. Save, Re-enable, Save again. No effect.

We did nothing recently to the server. no upgrades or anything. She just suddenly cannot send email. Other users on same domain are fine.

She can also receive just fine.

Checked under SECURITY and can't seem to find any kind of block by email address.

Can anyone help?

Employee Replied

8/25/2016 at 1:20 PM

Employee Post

Hi Scott. Are you sure there's not an SMTP Blocking rule setup at Security >> Advanced Settings >> SMTP Blocking. This would produce the exact message you're seeing.

Another possibility is Security >> Advanced Settings >> Abuse Detection. She may have triggered the 'Bounces Indicate Spammer' rule. If this is the case, stopping and restarting the SmarterMail service would clear this block out.

Scot Desort Replied

8/26/2016 at 8:45 AM

Rod

Thanks for the reply.

I have checked SMTP blocking and there are zero items on that list.

I have also checked for a BOUNCES INDICATE SPAMMER rule and none exist.

I even created a new user and that user can send fine. I am baffled by this. I even stopped and started SMTP under Manage>Services. How do I restart Smartermail in it's entirety (if that's what you mean)? I am on a VPS and don't have direct access to Windows Services. I can certainly open a ticket to have it down (or even reboot the server if necessary).

It's been going on for 5 days now and she is getting frustrated.

Scot Desort Replied

8/31/2016 at 8:30 PM

Anyone else able to assist with this???

Back to Community Threads

Please leave this box unchecked

11 Replies

Reply to Thread

Tags

Related Knowledge Base Articles