Kris Deugau wrote:
> 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 .
>
> ?
I thought of that too. :-)
I previously tried that a while back and found that Postfix won't
accept mail in my own configuration in that case.
<b...@proulx.com>: host mail.proulx.com[96.88.95.61] said: 550 5.7.27
<r...@example.org>: Sender address rejected: Domain
example.org does not accept mail (nullMX) (in reply to RCPT TO
command)
Where example.org is the replacement for this other domain I was
twiddling that I set up with a Null MX record for as a test case. And
then found that Postfix, perhaps due to my own unique configuration
here, won't accept mail from it in that case. I presume due to:
reject_unknown_sender_domain
Reject the request when Postfix is not final destination for the
sender address, and the MAIL FROM domain has 1) no DNS MX and no
DNS A record, or 2) a malformed MX record such as a record with
a zero-length MX hostname (Postfix version 2.3 and later).
The reply is specified with the unknown_address_reject_code
parameter (default: 450), unknown_address_tempfail_action
(default: defer_if_permit), or 550 (nullmx, Postfix 3.0 and
later). See the respective parameter descriptions for details.
But this is such a useful feature that it is often used and I would
not want to do without it. I don't know how many sites have this or
equivalent set but I think it would be a very high percentage.
Therefore adding a Null MX would actually make the problem worse.
I think it is all or nothing.
> 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).
That's basically the situation now. And sites that do callbacks for
sender address verification then refuse to accept the mail because the
sending site is a send only site.
I initially never thought that Sender Address Verification was a
problematic. On a first look it seemed cool. But now I think it is
really a tangled mess! Mostly I see in conjuction with exim sites.
For those reading along but don't know what this is:
https://en.wikipedia.org/wiki/Callback_verification
http://www.postfix.org/ADDRESS_VERIFICATION_README.html
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-access_control_lists.html#SECTcallver
But I am avoiding it.
> 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.
Mostly I was trying to get a feel for how much of a problem other
people have been seeing with this issue. The feeling I get from
reading so far is that it while there may be some problems it hasn't
been an overwhelmingly huge problem such that everyone knows the
answer except for me.
> 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.
I think you are right.
It's not a problem for 99.44% of sites. I am just trying to smooth
out the 0.56% that are having problems. (Obviously numbers I just
guessed out on the spot.)
I think my plan is to continue without an MX record and without the
ability to verify sender address verification for those sites that do
it. And those sites will either adapt or their customers will keep
complaining that they are not getting mail.
For the 99% of everyone else things will just keep working.
Bob
