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: 98.18.75.3 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:
https://tools.ietf.org/html/rfc821#page-37
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.
Angus
___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
