On 6 Dec 2015, at 10:01, sb wrote:
On 12/5/15 11:28 PM, Noel Jones 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.
It is the machine that first hit my server.
In my church, that's the sending machine.
Whatever articles of faith you may believe in, Postfix has a very
precisely applied jargon vocabulary that cannot be evangelized to align
with your dogma because it is bound to the actual SMTP protocol as it
exists in specification and operation. The "client hostname," "helo
hostname," and "sender domain" are independent values which sometimes
are related but very often are not. Declaring that you believe them to
be the same thing because it's your "church" is not useful. Your faith
cannot change reality.
Of those 3 independent domain name values, ONLY the sender domain has
any operational reason to have a MX record, and even it can be entirely
valid without a MX if it has an A. That's not a "loophole," it's an
artifact of how email evolved from being host-centric to being
domain-centric, while the usefulness of historical host-centric email
has never gone away. You may find that untidy but your opinion cannot
change what is, no matter how sincere your faith.
It is also *in principle* required that a helo hostname be fully
qualified and have an A record OR (by some interpretations of historical
SMTP specs) a MX record. However, it is also a direct contravention of
the latest RFC specifying SMTP for a server to require that a helo
hostname be resolvable and in practice it is very hazardous to do so.
There is absolutely no operational use or protocol requirement or
rational reason for a client hostname to have a MX record. Had such a
requirement been placed on your mail to this list, it would be rejected
by the mailing list server (aibo.runbox.com has no MX) and by the
servers handling delivery to list members (english-breakfast.cloud9.net
has no MX.)
No, I won't wait for the FROM header:
The email address in the 'From:' header may or may not have any
relationship to the SMTP envelope sender address, which is the value to
which Postfix 'sender' restrictions and parameters refer. The "wait"
from knowing the client hostname of a connection and the sender domain
is ~4x the RTT between you and the client, typically less than 150ms
with the exchange of ~100 octets between server and client (greeting
banner, helo, helo reply, mail command). To get the sender domain, you
DO NOT need to wait for the "From:" header because the sender domain is
not defined by the "From:" header *OR ANY OTHER HEADER*.
Postfix proper only filters mail based on message data (which includes
the message headers) when configured to use header_checks or
body_checks. Mostly, late ('end-of-data') rejection is done by Postfix
passing message data to external filters.
such junk must be rejected upfront.
For someone without much SMTP operational experience, it might seem that
ideally rejection of junk should always be done as early as possible in
the protocol. This was even how the earliest efforts at spam rejection
in major MTAs operated in the mid-90s: both Sendmail and Postfix
originally defaulted to rejecting at connection, after HELO, and after
MAIL when clients had already violated policy rules that would mandate
rejection by those points. It was quickly discovered that this approach
has 2 problems:
1. A substantial subset of SMTP client implementations reacted
improperly to early rejections by retrying deliveries that should not
have ever been retried. Notably, versions of MS Exchange and QMail have
been problematic in this area.
2. A very large majority of mail systems eventually run into a need to
make at least one exception to a seemingly "universal" rejection policy
applied to client, helo, or sender values that is limited to specific
recipients, message data, or a combination of both. The broadest
examples of this are messages sent to "postmaster" and "abuse" standard
role addresses, both of which should be left open to receiving any mail
that has any chance of being well-intentioned and fit for those roles'
purposes.
However, that seems almost irrelevant to what you seem to be asking
Postfix to do. At connect time (when "client" restrictions are applied
if you override the default and don't delay rejections) you cannot know
the sender domain, which is the only domain value that has any real need
to have a MX record. To reject based on any aspect of the sender domain,
you must wait until the client provides that data in the MAIL command.
Postfix itself offers many tools for deciding to reject particular
sender addresses or domains, but discriminating between those with MX
records and those with only A records is not one Postfix offers *BECAUSE
IT'S A PROFOUNDLY BAD IDEA*. That said, Postfix *does* support the
Milter protocol, so if you really want to break your mail server by
doing this, the hook is available. If you have rudimentary Perl coding
skills, you could even do this using the MIMEDefang milter, which lets
one implement any filtering idea of any profound wrongness, limited only
by one's capacity to express bad ideas as Perl subroutines.
And finally, if what your REALLY want is sender address verification, a
definitive test that makes a "SMTP callback" at MAIL time to see if the
sender address is functional enough to get an affirmative reply to a
RCPT somewhere (consider the logic of this...) then there are multiple
implementations of that which can be used with Postfix. I will not say
more of them because I see SAV as itself an abusive practice that no one
should be doing except when restricted to a limited set of sender
domains that have given explicit permission for such verification. In
addition to being fundamentally wrong, SAV is a resource burden on
systems trying to use it and risks causing other mail systems to
(justifiably) reject all SAV traffic and so block legitimate mail into
the SAV-practicing system.
