Relaying disallowed error

[Adrian]

Hi everybody,

Since yesterday, we've been experiencing an unusuall amount of rejected sent emails.
From exising and valid email accounts on our AMS, we write to (or reply) accounts on external servers, and many come back with "'530 Account is not local, relaying disallowed."
We know this error well, but the sender (this happend to myself today) is correctly logged in.

No error on DNS on the server, double ckecked that. Logs tell the same 530 error, as if the sending accounts were not being able to identify themselves on the AMS.

Any ideas? What additional info could I post to let you know better?
Thanks!

[Adrian]

Adding some additional info:

I suspect that AMS somehow is skipping the login proceess. And in the troubled transaction I see a whitelist check that is not present in the good one.
Here are 2 examples. The first is a normal trnasaction, the second one with this error.
Both sendings were from the same computer, and the same sending account:

Code: Select all

Fri, 24 Feb 2012 10:18:32 -> 999.999.999.999 -> Success: Action=[Accept Connection], Details=[Port 25]
Fri, 24 Feb 2012 10:18:32 -> 999.999.999.999 -> Success: Action=[Received Hello], Details=[Host=SENDERPC]
Fri, 24 Feb 2012 10:18:33 -> 999.999.999.999 -> Success: Action=[Starting Login], Details=[LOGIN authentication.]
Fri, 24 Feb 2012 10:18:33 -> 999.999.999.999 -> Success: Action=[Login], Details=[senderr@domain.com]
Fri, 24 Feb 2012 10:18:33 -> 999.999.999.999 -> Success: Action=[Received Sender], Details=[senderr@domain.com]
Fri, 24 Feb 2012 10:18:33 -> 999.999.999.999 -> Success: Action=[Received Recipient], Details=[xxx@yyy.com]
Fri, 24 Feb 2012 10:18:33 -> 999.999.999.999 -> Success: Action=[Received Recipient], Details=[zzz@yyy.com]
Fri, 24 Feb 2012 10:18:33 -> 999.999.999.999 -> Success: Action=[Start Mail Transaction]
Fri, 24 Feb 2012 10:18:35 -> 999.999.999.999 -> Success: Action=[Complete Mail Transaction], Details=[From Host=SENDERPC, Size=49 KB, From=senderr@domain.com, To=xxx@yyy.com;zzz@yyy.com]

Fri, 24 Feb 2012 10:49:17 -> 999.999.999.999 -> Success: Action=[Accept Connection], Details=[Port 25]
Fri, 24 Feb 2012 10:49:17 -> 999.999.999.999 -> Success: Action=[Received Hello], Details=[Host=SENDERPC]
Fri, 24 Feb 2012 10:49:17 -> 999.999.999.999 -> Success: Action=[SPAM White List Check], Details=[Sender is white listed.]
Fri, 24 Feb 2012 10:49:17 -> 999.999.999.999 -> Success: Action=[Received Sender], Details=[senderr@domain.com]
Fri, 24 Feb 2012 10:49:17 -> 999.999.999.999 -> Failed: Action=[Received Recipient], Details=[aaa@nnn.com: Relaying not permitted.]
Fri, 24 Feb 2012 10:49:20 -> 999.999.999.999 -> Success: Action=[Close Connection]


What should I do?

[rob]

Looking at the logs there is no clear attempt by the client to attempt to login, hence the failure message... so your suspicions are correct. Now the only reason I can think that the login stage would be skipped if is the client didn't receive a proper welcome message. In the past this as been a result of infleuences on the SMTP service, most notably Cisco routers which include a SMTP security feature. I would recommend checking any router/firewall/SPAM/antivirus product that may be possibly processing the SMTP transactions and 'breaking' ESMTP support (basically some security options cause SMTP to be simplified and remove the extensions which enable authentication).

[Adrian]

Hi Rob,

I've checked what you say, and the router is not Cisco, and it has no security filters enabled. This is still happening, and everyone is getting very upset about this.
You can be in the middle of a conversation with someone, and on the 5th or 6th email, you get the error.
I tryied restarting AMS, but still happens the same thing.

Please help me. Thanks again.

[rob]

The only last remaining obvious to check would be to ensure you haven't enabled the SMTP security option 'Disable AUTH Reporting'. This is option exists simply for specific implementations but effectively breaks normal transactions.

FAiling this, I would hazard guess that something else may be intercepting the SMTP transaction but the only way to determine this would be if you enabled debug logging on the SMTP. Unfortunatly this will generate alot of log data but will effectivelly detail the true transaction. Perhaps enable this option and then attempt to trigger the issue by sending out some emails in a short space of time, hopefully one will fail. Of course due to the sensative nature of what the logs may contain, please feel free to send it to me at rob@code-crafters.com.

[Adrian]

Hi Rob,

Disable AUTH Reporting isn´t enabled.
I'll try right now what you're suggesting, and then I'll send the logs to your email.

Thanks.-