On 12/5/2015 1:36 PM, sb wrote: > On 12/4/15 9:39 PM, Noel Jones wrote: > >> Is this even the IP the sender domain pointed to? >> That isn't clear in your posting. > > Answered 4h earlier, althoughthe particular case of > 78-134-2-123.v4.ngi.it was just a conversation starter. > > On 12/4/15 6:28 PM, sb wrote: > >> This is the spamming host: >> >> > unbound-host -rvD 78-134-2-123.v4.ngi.it >> 78-134-2-123.v4.ngi.it has address 78.134.2.123 (insecure) >> 78-134-2-123.v4.ngi.it has no IPv6 address (insecure) >> 78-134-2-123.v4.ngi.it has no mail handler record (insecure) >> >> This is Postfix: >> >> # postfix/port-25/smtpd[35013]: connect from >> 78-134-2-123.v4.ngi.it[78.134.2.123]:3431
It's now obvious that you're talking about the client hostname, not the sender domain. The idea that a client's hostname must have an MX record and/or run an SMTP listener service in order to send mail is not compatible with current RFCs, and such a check will not be added to postfix in the foreseeable future. Best wishes. -- Noel Jones >> ... >> # postfix/port-25/smtpd[35013]: generic_checks: >> name=reject_unauth_pipelining status=0 >> # postfix/port-25/smtpd[35013]: generic_checks: >> name=reject_unknown_client_hostname status=0 >> # postfix/port-25/smtpd[35013]: generic_checks: >> name=check_client_access status=0 >> # postfix/port-25/smtpd[35013]: generic_checks: >> name=check_reverse_client_hostname_access status=0 >> # postfix/port-25/smtpd[35013]: >>> END Client host RESTRICTIONS <<< >> ... > > This is a domain that sends mail without a mail server. In fact, > >> 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! > >> nmap 78-134-2-123.v4.ngi.it > > Starting Nmap 7.00 ( https://nmap.org ) at 2015-12-05 17:58 CET > Nmap scan report for 78-134-2-123.v4.ngi.it (78.134.2.123) > Host is up (0.073s latency). > Not shown: 995 filtered ports > PORT STATE SERVICE > 22/tcp open ssh > 80/tcp open http > 81/tcp open hosts2-ns > 8080/tcp open http-proxy > > > On 12/4/15 9:39 PM, Noel Jones wrote: > >> This is a separate issue, a server with no SMTP listener. >> Nothing to do with MX or no MX. > > No, this is a domain that sends e-mail without an e-mail server of > any kind. > >> 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. > > Yes, google mail works like that, but they also have resources to > improve, > starting from the DNSSEC that they still do not have... > > Furthermore, size is no excuse for an RFC-mandated security loophole. > The RFC allows you to send e-mail using telnet from a dynamic domain, > possibly including spam/uce and any type of malware/spyware. At the > same > time, the RFC leaves the recipient without a shred of forensic > evidence, > apart from the dynamic IP and the ISP legal mess that goes with it. > (For example, A abused B using C's open wifi. By default, C's ISP > does not protectits wifi routerswith a password, and therefore C is > legallyclear ofresponsibilityfrom what A did. This case happened > to me as an expert witness.) > >> It works as documented and intended. The domain has an A record and >> does not meet the definition of "unknown". > > For all relevant intents and purposes, the sender'sdomain is an > "unknown" > domain, because the recipient cannot reply to it. I want my server > to reject such junk, firstly because I cannot reply to it. > > I do not care about the MX record of the sender's top level domain. > I can send mail to their ISP, but is not the same subject that sent > me spam. > One is the ISP the other is the ISP's client: two legally different > subjects. > The ISP rents the IP to a client who then sends spam from it, either > knowingly or by causeof malware or hacking or war-driving. The IP > is blacklisted, the clientmay not even know about the problem,and > its ISP does not care. I want my automated systemto work for me, > not against me. I want my system to reject such junk upfront. > >>> It is now in smtpd_client_restrictions. > >> Where it will never work due to your unrecommended setting of >> smtpd_delay_reject=no. > > In fact, it is back where it was, because smtpd_delay_reject=no > must stay in place. Yes, I want to reject that type of client > *before* it sends the HELO. No, I do not want to wait for a > FROM header, and I do not want to query a spoofable third party > black list either. > >>>> 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. > > I think that reject_unknown_sender_domain and SPF are not related. > > SPF is a bit of a problem on its own terms: spammers learned to use > it well, > while most legit e-mail providers do not even bother. > >>> 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. > > What good is using a spoofable black list? > It is a waste of time in exchange for a false sense of protection. > >>> - 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. > > Sometimes, the IP address is good enough... > > If the list is reliable, > if it is delivered by DNSSEC, > if I really trust the vendor, then > I would still prefer to download the list and use it locally. > > >> 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 > > Postscreen may be useful, but I really want to solve the root of the > problem, > without the need to query a black list. Black lists cannot possibly > include > dynamic addresses, for example. > > SB >
