Julian Mehnle wrote:
> I also added a brief explanation of why the "implicit MX" rule
> is problematic.
No problem with that brief explanation, but it doesn't convince
me that there is a problem. You argue that most domains have an
IP and therefore fall under the "implicit MX" rule. I'd argue
that most domains have an explicit MX, and therefore can't muddy
the waters.
Validating the "existence" of a domain by merely looking if it
has an MX (or lacking that an IP) won't help you long wrt spam,
professional spammers can arrange to survive this validation.
A part of the SPF FAIL philosophy is built on the assumption that
professional spammers prefer to abuse addresses surviving "call
back verification" (IOW real addresses), and that FAIL-protected
addresses aren't "good enough" for these professional spammers,
because checking (and rejecting) SPF FAIL is cheaper than CBV.
When we're in the realm of "plausible" addresses (from the POV
of the professional spammers), then MX or "implicit MX" (IP) is
only a precondition for further "plausibility" checks like "no
SPF FAIL for the IPs of my botnet" and "no 5xx after RCPT TO in
a 'call back verification'".
At some point in time the professional spammers will be forced
to fine tune their "plausibility" tests depending on their next
target, maybe that's already the case. "No MX and no IP" can't
qualify as "plausible" for such professional spammers, removing
the "implicit MX" from the picture won't make a big difference
for them.
This construct can be harmful, e.g. if stupid senders implement
it as "try the direct IP if all MXs failed", it's also easy to
get the details wrong while explaining e.g. SPF's mx-mechanism,
or when discussing IPv4 vs. IPv6, but that's not exactly the
fault of this "implicit MX" rule.
Changing that rule would be also tricky wrt EHLO, at the moment
an MTA claiming to be smtp.example.com in its HELO might not
have an MX, but still accept mail to postmaster@smtp.example.com
at its IP. Without the "implicit MX" rule the assumption could
be that any MTA without an MX for its HELO is what, suspicious ?
Frank
-------------------------------------------
-----------------------------------------------------------------------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com
> I also added a brief explanation of why the "implicit MX" rule
> is problematic.
No problem with that brief explanation, but it doesn't convince
me that there is a problem. You argue that most domains have an
IP and therefore fall under the "implicit MX" rule. I'd argue
that most domains have an explicit MX, and therefore can't muddy
the waters.
Validating the "existence" of a domain by merely looking if it
has an MX (or lacking that an IP) won't help you long wrt spam,
professional spammers can arrange to survive this validation.
A part of the SPF FAIL philosophy is built on the assumption that
professional spammers prefer to abuse addresses surviving "call
back verification" (IOW real addresses), and that FAIL-protected
addresses aren't "good enough" for these professional spammers,
because checking (and rejecting) SPF FAIL is cheaper than CBV.
When we're in the realm of "plausible" addresses (from the POV
of the professional spammers), then MX or "implicit MX" (IP) is
only a precondition for further "plausibility" checks like "no
SPF FAIL for the IPs of my botnet" and "no 5xx after RCPT TO in
a 'call back verification'".
At some point in time the professional spammers will be forced
to fine tune their "plausibility" tests depending on their next
target, maybe that's already the case. "No MX and no IP" can't
qualify as "plausible" for such professional spammers, removing
the "implicit MX" from the picture won't make a big difference
for them.
This construct can be harmful, e.g. if stupid senders implement
it as "try the direct IP if all MXs failed", it's also easy to
get the details wrong while explaining e.g. SPF's mx-mechanism,
or when discussing IPv4 vs. IPv6, but that's not exactly the
fault of this "implicit MX" rule.
Changing that rule would be also tricky wrt EHLO, at the moment
an MTA claiming to be smtp.example.com in its HELO might not
have an MX, but still accept mail to postmaster@smtp.example.com
at its IP. Without the "implicit MX" rule the assumption could
be that any MTA without an MX for its HELO is what, suspicious ?
Frank
-------------------------------------------
-----------------------------------------------------------------------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com