Bob Proulx wrote:
The problem is *other* sites. I am starting to get a trickle of
complaints from people who are not receiving password reset emails.
And the problem seems to be other sites that are requiring that
senders have MX records, and the rest of the associated incoming mail
server set up for it. Which I am well equipment to deal with but
would rather not since not is simpler.
webservice.example.org. IN MX 0 .
?
Or just publish the server as a normal MX record, and just don't set up
any actual handling for inbound mail (ie, configure Postfix to not
listen on the public IP, and/or block port 25 inbound in the firewall).
Sites insisting on having an MX record for the sending FQDN (or worse,
the rDNS name) are likely to reject this too, but if they're that
insistent on having a return channel you're likely going to end up in
their separate local blocklist sooner or later anyway.
If the server is a subdomain, point the MX record to the primary
domain's MX, and configure it or not for the subdomain.
The problem with sites that take a strict line like this is that they
WILL reject a certain amount of legitimate mail, and in the long run the
only fix is to convince them that they need to relax their restrictions.
Over time this will happen naturally; either they bend to pressure
from their users to let in mail that their users want to receive, or
they lose the users whose mail they refused to let through.
-kgd
