On 2015-06-22 11:55, Alessio Cecchi via spamdyke-users wrote:
one sender (and only this one) is unable to send email to my users,
this is the error in spamdyke log:

Jun 22 05:47:37 mx01 spamdyke[1066]: DENIED_OTHER from:
i...@domain.net to: j...@domain.com origin_ip: origin_rdns:
static-98-18-75-3.optusnet.com.au auth: (unknown) encryption: TLS
reason: 503_MAIL_first_(#5.5.1)

The sender said that "is unable to send email only to me" so the
problem is mine ...

How can I solve this problem or how can I demonstrate that is a sender problem?

My understanding is that 503 MAIL first occurs when the other side is using badly implemented software that sends SMTP commands out of order.

Normally, the SMTP transaction should go something like (with Spamdyke's responses indented for clarity):

   HELO bar.com
     220 baz.com
   MAIL FROM: u...@bar.com
     250 OK
   RCPT TO: u...@baz.com
     250 OK

and so on.

If the other side starts with:

   RCPT TO: u...@baz.com

Then Spamdyke will respond:

   503 MAIL first (#5.5.1)

In other words, Spamdyke is saying "You should have sent the command MAIL first."

I believe that this is what's happening in your case.

From my reading of:


Spamdyke is actually right to do this. A client that leads off with an out-of-order command is not following the SMTP protocol. Because SMTP is a stateful protocol, sending out-of-order commands could lead an MTA to end up in an inconsistent state, and mail could be lost.

I don't know exactly what the other user's client is sending, but from my experimentation it looks most likely that it's sending RCPT before anything else. If it sent another command, such as DATA, or an unrecognized command such as QUUX, Spamdyke would give a different error.

Because this is a fairly fundamental error on the part of the remote client, I would not expect it to be possible to configure Spamdyke to handle this case.

Obviously, if he's able to deliver mail to other destinations, then other MTAs must be more forgiving. Nevertheless, it looks to me as if Spamdyke is following RFC821, and his software is not.

Sam Clippinger can probably confirm whether or not this is the case, and whether there's anything you can do about it. But it looks to me as if the other guy's software is broken, and it's his problem, not yours.


spamdyke-users mailing list

Reply via email to