Our mail provider provides the MXs for our domains, performs some screening on the mails (spam checks etc.) and then delivers the mails to our internal mail server. (They use Cisco Ironport.)

They have configured recipient verification/callout/call-ahead using a static MAIL FROM address (test@isp.com). This poses problems for internal email accounts which have a restricted set of external domains from which they can receive mail. (The ISP thinks the account does not exist, and bounces the mails, while the account does indeed exist but accepts only mail from certain domains of which the static mail from address used for the callout is not a part.)

Do you think they are doing this correctly? I did not find a best practice or an RFC on that subject... Any idea why they would not use the empty envelope sender to perform the check? (i.e. MAIL FROM:<>)

It seems there are three possibilites to perform the callout:

  • Use the (from,to) tuple from the original mail (since the Ironport apparently caches the result, it probably can't do this, or the cache would be very ineffective). However, this is what e.g. the Exim manual suggests.
  • Use the empty envelope sender as outlined above. Unless the recipient would refuse bounces or delivery notifications or the like, this would probably work.
  • Use a static FROM address. This appears to be the most stupid choice.

They have agreed to set an empty envelope sender for the callouts and everything is perfect. :)

  • 1
    An empty envelope sender is intended to be used only for bounces. Misusing it for other purposes is likely to cause you problems at some point. – kasperd Jul 20 '16 at 22:38
  • I agree it's not a perfect solution. But 1) their appliance can't do differently 2) it works well for us because even our restricted accounts accept bounces, obviously. – Marki Jul 21 '16 at 6:48

Your mail provider is idiotic. The correct way to do "call-ahead" verification is to use the same envelope sender as was presented to them, because that's how relaying works. To use a static (bogus) envelope sender, or always using a null envelope sender, is amazingly ill-advised.

  • Apparently their Cisco appliance can't do that. – Marki Jul 21 '16 at 6:45
  • Apparently it's time to find a new provider who can choose devices which operate correctly. – womble Jul 21 '16 at 8:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.