On 12/4/2015 12:57 PM, sb wrote: > On 12/4/15 7:08 PM, Noel Jones wrote: > >> The sender domain must have either an MX or an A record. >> You can reply to a domain with only an A record. > > If I send mail to the above address, there is no server that can > receive it: > >> telnet 78.134.2.123 25 > Trying 78.134.2.123... > > No response given. There is nothing there!
This is a separate issue, a server with no SMTP listener. Nothing to do with MX or no MX. Is this even the IP the sender domain pointed to? That isn't clear in your posting. There is certainly no requirement for an IP that sends mail also accept mail, many domains large and small use separate IPs for these two tasks. > >> Postfix has no code to distinguish sender domains with no MX only > an A record, >> and not likely that feature will ever be added. >> Sender domains with neither MX nor A record -- domains you can't > reply to -- >> can be rejected with reject_unknown_sender_domain. > > I had eject_unknown_sender_domain in smtpd_sender_restrictions, and > it did not work. It works as documented and intended. The domain has an A record and does not meet the definition of "unknown". > It is now in smtpd_client_restrictions. Where it will never work due to your unrecommended setting of smtpd_delay_reject=no. > > > The documentation says: > >> 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 A or MX record, or >> 2) a malformed MX record such as a record with a zero-length MX > hostname. >> The unknown_address_reject_code parameter specifies the > numerical response >> code for rejected requests (default: 450). The response is > always 450 in >> case of a temporary DNS error. The > unknown_address_tempfail_action parameter >> specifies the action after a temporary DNS error (default: > defer_if_permit). > > In this case Postfix was final destination for the sender, if I > understand that > sentence correctly. This means if the sender domain is your own domain, a job for SPF. > > >> The client mentioned is currently listed on several blacklists. > Maybe the client wasn't listed >> at the time you received their spam, but consider using some > dnsbl's in your setup. > > I would rather use local filters than remote black lists, for at > least two reasons: > - they do not use DNSSEC, True, but this scraping the bottom of the "possible threat" barrel. > - they learn about your incoming addresses. You send the dnsbl service the connecting client IP address, or sender domain name for an rhsbl. This can't be sensitive information for any internet-connected mail server. > >>> smtp inet n - - - - smtpd >>> -v >> verbose logging is almost always a mistake. The important messages >> get drowned in the flood of irrelevant information. > > Verbose logging is not a mistake when debugging, which is what I am > doing at this time. Everything you need is in the normal logs. > >>> -o syslog_name=postfix/port-25 >>> -o smtpd_tls_security_level=may >>> -o smtpd_sasl_auth_enable=no >>> -o smtpd_delay_reject=no >> generally unwise to disable smtpd_delay_reject, except maybe as a >> $stress mitigation during an overload/attack. > > I am running a sensitive site, and need it to be responsive and > resilient. > Rapid rejection is necessary, albeit not sufficient. Unless you're using a severely limited server you're losing the benefit of delayed rejects for no substantial return. You're working too hard. Enable postscreen and a couple blacklists. Run it in test mode for a while to see what it does. -- Noel Jones
