On 12/19/2019 1:32 PM, Viktor Dukhovni wrote:
This includes RBL checks, presence of PTR, PTR name regexp checks, ...
Rejecting address literal in EHLO is a filter in this class, that can
be justified entirely on its efficacy. If the reported one complaint
in 10 years is about right, then it is working well enough in practice.
I don't agree this is a justification to bring break a base SMTP
protocol feature.
This subjective justification talk is equivalent to someone using
Pareto's Principle to create a RISC SMTP server with low used commands
like VRFY, EXPN, HELP, NOOP, TURN eliminated. Odds are very high the
impact will be low and they will probably get away. We can ignore
those one or two clients still using the above low occurrence commands.
For the record, the "complaint" would of been much more and earlier if
the mail.ietf.org site wasn't whitelisted. It hid the problem. When
it was changed recently, the CBV kicked in.
I also have some doubt this was instituted for "10 years." I can
easily verify that. If the IP was constant for 10 years until the
recent IP change, the CBV check was preempted. I can verify this by
checking my 16 years WCSAP configuration of wcSAP daily statistics and
session trace logs archives. All saved. I might do that soon.
But I'd rather deal with a responsive operator with a few odd rules
that reject traffic outright (I get a bounce), than operators that
strictly follow the wire protocol, but then silently deliver to the
Junk folder, and are too big to respond to reports from most senders.
We have a different view in what is a subjective consideration vs a
robust standard SMTP protocol feature which is deterministic in nature
when filtering is applied. Subjective filters have a higher rate of
false/true positives/negatives. Its one reason in the wcSAP, we have a
disclaimer:
http://www.winserver.com/public/aup/antispamsupport.htm#Disclaimer
Wildcat! is one of more aggressive mail filters package around. But I
look for deterministic methods, not subjective, and leave the latter
to admins.
The fact is, there is a SMTP protocol rule of using a HELO/EHLO
[ip-literal] that MUST match the connection IP. If not, it is a
strong reason for rejection. I have wcSAP stats for that.
The difference with the SDO is a flat rejection of ip-literal based on
some subjective notion that ALL senders using ip literals are bad.
If it rejected on the rDNS detection that a FQDN was available and
enforces its usage, that may be a easier argument to sell because it
is a deterministic rule.
But unfortunately, that isn't the case here.
Finally, depending on one's view of the controversial CBV method,
others will have a different view on this than me, but I and my
customers have 16+ years of a high efficacy system to detect
fraudulent senders, especially reverse paths. By far, CBV is the
highest payoff filter right now, today, bar none, than any other known
method. The CBV is a compliant SMTP client. It needs to be low
overhead and fast. It uses the [ip-literal] to reduce PTR overhead and
to allow it to work ALL the time out of the install box. Since it is
a standard feature, it is always expected to work. If sites who are
beginning to use ip-literal as a subjective trigger to flat out reject
- they are all in violation of the specification.
BTW, the system does offer the required options that covers the CBV
option:
; CBV Mail Host Domain
;SapHost mail.yourdomain.com ; Use a special mail host domain,
should be MX host.
;SapHost [serverdomain] ; Use Primary Host Domain
;SapHost [mailhost] ; Use PTR lookup of WCSMTP server IP
SapHost [serverip] ; Use WCSMTP server bracketed IP address
So its not something that we are stuck with but no doubt, it adds to
the efficiency of the method. To eliminate it for no good reason at
all is pretty hard to swallow.
I have to stop, sorry. Time for a drink. :)
--
HLS
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp