/ by Oliver Egginger or perhaps someone else > It's advisable to do sender callouts with a null-reverse-path. > At the moment we do sender callouts and reject every message which can't > be verified by a callout. But by reading this thread I arrive at the > conclusion that I'll better disable all denies which are based on sender > callouts.
I would continue to reject all mail for callouts that used <>. They send mail so they should be able to accept bounces/<>. The main argument here is that a valid reason to reject all <> is for mailboxes/domains that don't send mail -- so when your callout fails and you reject the message its all good. For Recipient callouts, if they don't accept <> then that would be a problem. Meanwhile, if the senders do have a broken configuration and indiscrimently reject all <>, then it's ok to reject them as they're probably idiots and you don't want to accept responsibility for mail that could potentially bounce and that you don't want to be stuck with. I feel all callouts should use <> and that responses should be deciphered finding "User unknown" etc, as hard as that may be. Wait, I suppose recipient callouts could use the sender address, and the error messages could be proxied back to the initiating session. I'm not sure how sophisticated callouts are as I've never examined them closely. I would have thought someone would have mentioned callouts sooner. They seem to be an excellent example of how <> senders can be used (to avoid loops and such) and why rejecting <> could be detrimental. Actually, I suppose if blocking <> is implemented in moderation for accounts that don't send mail, alias etc, then that could help re-enforce callouts. -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
