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. <[email protected]>: host mail.proulx.com[96.88.95.61] said: 550 5.7.27 <[email protected]>: 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
