On Sun, Apr 28, 2013 at 11:10:10PM -0500, Stan Hoeppner wrote:
> > There is an important difference, which is why the defer variant
> > is used as a safety net, and the use-case is precisely when the
> > client is an MTA.
>
> Apparently I didn't make my point clear, which is that a hard fail isn't
> necessary here, and that a temp fail is preferable to cover all client
> types. I think Reindl was advocating a hard fail. I was countering his
> argument.
Well, the hard fail is typically a good idea once one is sure the
restrictions contain all the required permits. Some sites may
depend on check_client_access or check_recipient_access table
lookups to handle cases more complex than permit_mynetworks or
permit_auth_destination.
The point of the safety net is to give the site some time to notice
before lots of mail bounces.
If you're advocating leaving the defer safety net on all the time,
in the case of relay permissions this is arguably not entirely
unreasonable. One could argue that legitimate MTAs that queue and
retry mail deliveries are not easily fooled into using some other
MTA as an unauthorized relay, and that the relay restrictions should
not reject mail for which the receiving MTA is an MX host.
So in that sense, this particular safety net may also be usable on
a long-term basis. The main problem case is with ISP MTAs that
support relaying by authorized clients, when a client is misconfigured
to continue to use the original MTA after switching ISPs or after
a password reset... Then the client may keep trying to send
repeatedly.
A soft fail is in this case a feature from the perspective of the
misconfigured client, but may increase load at the ISP if the client
generates enough traffic. All in all, perhaps a rather small risk,
since clients liable to be misconfigured this way are unlikely to
constitude a substantial fraction of the ISPs mail load.
--
Viktor.
