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
