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
...
# 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
