This is correct, with one small addition -- the MAIL first message is not
coming from spamdyke. That message is being generated by qmail, which is why
spamdyke logs it with DENIED_OTHER.
If you want to figure out exactly what's going on, you could turn on spamdyke's
full logging to capture the entire session. It will generate a log file for
every connection, so you'll have to search to find the one you want, but it'll
show every byte that goes through and exactly what spamdyke does with it (along
with plenty of other debugging data). There is a remote possibility this
sender's software is sending the MAIL FROM command in a way spamdyke can't
parse, causing it to eat the input and never send it to qmail, but the full log
would show it either way. The option to enable that feature is full-log-dir.
-- Sam Clippinger
On Jun 22, 2015, at 11:32 AM, Angus McIntyre via spamdyke-users
spamdyke-users@spamdyke.org wrote:
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
___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
