Could not complete sender verify callout

[zero@]

I have one user who is having their mail rejected from one of their clients. Here is the redacted error message from the recipient:

2006-10-05 15:22:40 H=(my.hostname.com) [ip.add.re.ss] F=<[email protected]> temporarily rejected RCPT <[email protected]>: Could not complete sender verify callout

the sender's mail server does not confirm that [email protected] is a valid email address with them. this is why they are being rejected.

NO other mail is being rejected on the server, except to this recipient domain. I tried from my address with another domain on that box, and I got the same result.

Does anyone have an idea of why this is happening? Is there a way that I can login via telnet to test it?

Thanks for the help.

 

[jwdick]

Sounds like the recipient domain is blocking emails that do not match SPF records. Do you have SPF txt records set on your domains?

Read all about it here: http://new.openspf.org/

 

[zero@]

Hi Jack,

Thanks - I think you pointed me in the right direction.

I handle my DNS on another box, and Plesk runs through a subdomain from my primary domain. So it looks like there's some things I need to figure out.

 

[Jllynch]

Did you get a solution for this one? One of our clients can't email to another server as they keep getting;
451 Could not complete sender verify callout.

So it looks like our servers aren't replying.

This happens when testing from 2 email addresses on 2 different plesk servers (7.5.4 and 8.1).

 

[servertune]

Originally posted by Jllynch Did you get a solution for this one? One of our clients can't email to another server as they keep getting;
451 Could not complete sender verify callout.

Sender callouts or callbacks is a mechanism that is offered by some MTAs, such as Exim and to validate the "local part" of a remote sender address.

In theory sender callouts or callbacks should help with spam. Since sender verify callout is enabled on your server, when email comes, your server calls back, and checks to see if the address used as the envelope sender in the e-mail accepts email.

This is a case where sender callbacks will interfere with regular mail delivery is if a mail server is not accepting mail from the null sender as per RFC 1123. Exim uses the null sender as part of the sender verifying process. A lot of mail servers will just blindly reject any mail stating to be from the null sender. Whether or not this is warranted is left up for another discussion, but the fact remains that if a mail server is rejecting mail from the null sender then it is breaking RFC 1123. I am of the thinking that one should follow RFC standards as best as you can, just because there has to be some form of standardization with communication or else you run the risk of some communications working and some not if no standard is followed. Never-the-less, since sender callouts is enabled on your server, then mail from domains whose mail server rejects the null sender, those messages will not be accepted by your server.

Unfortunately, there are many companies who will send out messages from or use a nonexistant address because they do not want to receive any reply backs.

Now you get to make a decision. Do you enable sender callouts or not? If you disable sender callouts, then you will likely receive more spam and your users may inquire about the amount of spam that they receive. If you disable sender callouts, your mail queue will also likely grow larger or email will be rejected because your mail server will be accepting more faked spam messages. In my opinion, all the "cons" for enabling sender verify are elements that point back to poor administration on the sender's server. However in practice, end users usually care less about defining standards and they just want to receive their messages. So there's not really a win-win situation.

Andy Reed