On 9/27/20 8:51 PM, Richard Clayton wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message
<6330c607-5ede-4766-1823-5c8be8a9097b(_at_)network-heretics(_dot_)com>,
Keith Moore <moore(_at_)network-heretics(_dot_)com> writes
But this is a silly discussion.
It seems backwards from where it started ... which effectively came down
to what would be good advice to proffer to a client to ensure that their
email deliverability improved. The good advice "why don't you make sure
that forward and reverse DNS match up and say EHLO in a consistent
manner" is difficult (as has been pointed out) for some clients to
follow ... and that's why IMO it ends up as a SHOULD rather than a MUST.
I thought it was about advice to the server which is currently that the
server MUST NOT refuse to accept a message based on failure of EHLO
argument verification.
My argument is that EHLO verification is, in the long run, poor practice
and should not be encouraged by 5321bis /even if it seems like an
effective spam countermeasure today./ There are various reasons for
this, but probably the most salient is that the need to support mail
sending from some IPv6-only networks, and eventually to no public IPv4
Internet, makes any expectation that the client knows what DNS name will
result from a PTR lookup of the client's source address as seen by the
server, to be dubious at best and perhaps completely meaningless.
Since we expect 5321bis, as a Full Standard, to be long-term stable, it
doesn't make sense to promote a practice that seems dubious or even
harmful to mail reliability in the long run.
(I'm open to other ways of rewording the language currently in 5321, as
long as it takes into account the fact that in a world where
communications between IPv4 hosts and IPv6 hosts is mediated by NATs
supplied by carriers, a client no longer has a reasonable expectation of
knowing what its source IP address will be as seen by the server, or of
having control over the PTR records in the corresponding DNS zone to
that source address. What I don't think is reasonable in the long run
is to expect all SMTP clients to have direct access (and their own
static addresses) on both the public IPv4 network and the public IPv6
network.)
I certainly acknowledge that spam
filtering is hard, and that the state of the art is to use unreliable
heuristics.
I would disagree ... state of the art is ML clustering algorithms using
a wide range of signals, where even the people who developed the systems
find it fairly hard to reliably predict beforehand which of those
signals are going to be of real significance.
Thanks for the clarification. I agree that it's useful to distinguish
ML algorithms from heuristics.
This does bring a tangential question to mind, though:
Since the only practical way of tuning these algorithms is end-user
free-back
To me it seems like a very important case where reliability is concerned
is when a willing sender (who has not previously received mail from this
recipient) tries to send their first email to a willing recipient. If
that doesn't work, the sender and recipient may simply give up, but
whatever they do, they're shooting in the dark.
If end-user feedback is already difficult to get (and I acknowledge that
it is), it seems like measuring this critical case and tuning ML
algorithms based on this case would be extremely difficult.
Keith
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp