Subject: [ietf-smtp] EHLO domain validation requirement in RFC 5321

From: Sam Varshavchik <[email-masked]>
Date: Fri, 18 Sep 2020 18:36:18 -0400

RFC 5321 declares:

#  An SMTP server MAY verify that the domain name argument in the EHLO
#  command actually corresponds to the IP address of the client.
#  However, if the verification fails, the server MUST NOT refuse to
#  accept a message on that basis.

It's been my experience that this is frequently ignored in practice: in  
varying ways whatever is seen in EHLO gets validated against DNS and if  
found to be unacceptable mail gets rejected based solely on that criteria.  
This is not a very popular thing to do overall; but it is not a rarity  
either, and I hear about this regularly. This very own E-mail was prompted  
by a thread on my mailing list from someone who had this happen to them this  
week. I don't know how common this practice is, but it's not uncommon.

Courier has an optional setting that can be enabled, that verifies that "the  
domain name argument in the EHLO command actually correspond to the IP  
address". I have it enabled. It's one of my most successful spam filters.  
It's very valueable to me. It's possible that there were one or two  
instances in the last 25 or so years when I found out that this rejected  
something that wasn't junk, but I don't immediately recall a single one.  
I'll stipulate that there might've been one or two times, and that's a  
pretty good record.

I have no specific knowledge about other MTAs capabilities, but I suspect  
that many of them (at least the non-commercial ones) offer something similar  
in nature.

I think that the "MUST NOT", in there, should be, at the most, a "MAY NOT".  
The only situation where MUST NOT makes sense in my eyes would be someone  
who's already authenticated; a mail client on port 587.

I don't recall anyone flaming me in the aforementioned last 25 or so years,  
accusing me of violating the SMTP standard because I rejected whatever they  
deemed was so important to email to me and that I was obligated to read it.  
Maybe it happened, once or twice, I don't remember. But if someone did, I  
would've responded like this: you are absolutely right, and then end the  
conversion without any follow-up.

If I emailed someone and it bounced back because of this, it would never  
cross my mind complain about it. It's their mail server. Their rules.

Then there's also this part:

#  o  The domain name given in the EHLO command MUST be either a primary
#     host name (a domain name that resolves to an address RR) or, if
#     the host has no name, an address literal, as described in
#     Section 4.1.3 and discussed further in the EHLO discussion of
#     Section 4.1.4.

Not sure how to square this away. If it's a MUST, and this fails this test,  
it seems to me that a mail server is no longer under any obligation to  
continue to attempt to do something useful with a sender that does not  
comply with this RFC. But this requirement conflicts with the other  
requirement. I do not see how to reconcile these conflicting assertions.  
Either it is permissible to disengage from a non-compliant client, or not.  
Both can't be true.

As a side note, I wasn't sure whether I want to mention this at all. It's  
actually against my self-interest to do so. After all, if this gets changed  
and becomes compliant behavior, and EHLO/HELO domain name validation becomes  
more prevalent: the spam factories will surely notice, adjust, and this spam  
filtering technique will become much less effective.

---

From: Keith Moore <[email-masked]>
Date: Sat, 26 Sep 2020 21:45:15 -0400

On 9/18/20 6:36 PM, Sam Varshavchik wrote:

> It's been my experience that this is frequently ignored in practice: 
> in varying ways whatever is seen in EHLO gets validated against DNS 
> and if found to be unacceptable mail gets rejected based solely on 
> that criteria. This is not a very popular thing to do overall; but it 
> is not a rarity either, and I hear about this regularly. This very own 
> E-mail was prompted by a thread on my mailing list from someone who 
> had this happen to them this week. I don't know how common this 
> practice is, but it's not uncommon.

Ok, this will probably look a bit like a rant.   Apologies in advance, 
and this is not meant to be disparaging to anyone.

1. Especially these days in the widespread presence of NATs and proxies 
of various kinds, it is meaningless to "verify" the domain name argument 
in HELO/EHLO.   Really it has never made any sense to compare HELO/EHLO 
argument against PTR lookup results on the source IP address because (a) 
hosts commonly had multiple interfaces with different names, and clients 
might not bother checking which outgoing interface was being used; (b) 
the longstanding practice of two-faced DNS means that the client host 
and server  may legitimately see different results from PTR lookup; (c) 
ISPs have (unfortunately) been polluting in-addr.arpa for years with 
made-up names which add no value; (d) historically the most likely 
reason for HELO/EHLO arguments to be "wrong" (assuming one could even 
define what that meant) was client MTA misconfiguration unrelated to 
message content; (e) there was never any requirement that Internet hosts 
have distinguished names anyway.   Also, these days it's quite 
commonplace for servers to log source IP addresses independently of 
anything said in HELO/EHLO, so insisting that EHLO arguments match 
source IP address as viewed by the server, really adds no value.

2. The HELO/EHLO argument is historically (and should continue to be) 
simply what the client host thinks its name is.   This is useful in 
Received header fields and logs, to diagnose problems that occurred on 
the sender's end of things.  (e.g. "Which host is generating this 
garbage Content-Disposition field?"  "It's the one that thinks its name 
is 'mumblefrotz'".)  So when you find an MTA config with its name set to 
mumblefrotz, you know you've found it.   This is useful in a different 
way than source IP address is, because nothing (that I'm aware of) 
requires client SMTPs to have stable source IP addresses.  So I would 
argue that it SHOULD NOT be derived from the client host's idea of its 
source IP address. (I could make a case for encouraging HELO/EHLO 
arguments to be UUIDs or some other kind of globally-unique identifier, 
but it's probably about 30 years too late for that.)

3. 821, 1123, and subsequent revisions all seem to be based on the 
assumption that if you're operating an SMTP server, you're trying in 
good faith to deliver (legitimate) email reliably.   I'm not sure this 
assumption holds true anymore, or has held true in general for the past 
20 years or so, because a lot of providers these days seem instead to 
regard all externally-originated email with suspicion, and to be trying 
to find every possible excuse to reject email.

Seen from that perspective, maybe 5321's language about EHLO arguments 
could use some updating along the following lines:

- For a very many reasons [which could be listed, or not], SMTP servers 
have no reasonable expectation of being able to determine the validity 
or legitimacy of a message based on comparison of the EHLO command 
argument with anything else at all.   Therefore if what you're trying to 
do is reliably deliver legitimate mail (for some meaning of legitimate), 
validation of EHLO arguments is useless and strongly NOT RECOMMENDED.

Of course, if your goal is really to discard mail for no good reason, 
and you're not handling incoming mail for anyone but yourself, have at 
it!   Just have the decency to blackhole the mail rather than bounce it, 
since you're really not doing anyone any favors.

(If it were normal for SMTP clients to relay mail with TLS and use 
client certificates to do so, maybe it would then make sense to check 
EHLO arguments against the client certificate's name. But we're a long 
way from being there.)

> Not sure how to square this away. If it's a MUST, and this fails this 
> test, it seems to me that a mail server is no longer under any 
> obligation to continue to attempt to do something useful with a sender 
> that does not comply with this RFC. But this requirement conflicts 
> with the other requirement. I do not see how to reconcile these 
> conflicting assertions. Either it is permissible to disengage from a 
> non-compliant client, or not. Both can't be true.
I would argue for making this a SHOULD or perhaps a MAY, because making 
it a MUST tempts servers to perform meaningless checks against it.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sat, 26 Sep 2020 22:00:10 -0400

Sorry, there's a piece of this that I neglected to address in my earlier 
reply:

On 9/18/20 6:36 PM, Sam Varshavchik wrote:
>
> Courier has an optional setting that can be enabled, that verifies 
> that "the domain name argument in the EHLO command actually correspond 
> to the IP address". I have it enabled. It's one of my most successful 
> spam filters. It's very valueable to me. It's possible that there were 
> one or two instances in the last 25 or so years when I found out that 
> this rejected something that wasn't junk, but I don't immediately 
> recall a single one. I'll stipulate that there might've been one or 
> two times, and that's a pretty good record.
>
I didn't intend to dismiss or ignore this input.   I believe you when 
you say it's been a good spam filter for you.

At some point in the past, this was _not_ a reliable spam filter.    To 
me the fact that it works as a spam filter today seems like mere 
circumstance or accident; I don't see any inherent reason that it will 
be a reliable spam filter going into the future.   Spammers do learn, if 
slowly, so if they have to learn to make sure their EHLO arguments match 
their source IP addresses, they'll do that.   In the long term, I don't 
think this check helps anything.

SMTP has been around for nearly 40 years now (close enough to round 
up).   Are we intending this standard to be applicable for decades past, 
only today as a snapshot in time, or decades into the future?   I would 
argue that it's the latter, and that SMTPbis should make recommendations 
that there's reason to believe will hold up over time.

Separate from all of this, there is an emerging set of (as far as I 
know) largely-unwritten "rules" for how to make your outgoing mail 
appear legitimate enough so as to not get flagged by spam filters as 
often.   This is a mess because most of those "rules" are basically ad 
hoc and not based on any long-term reliable indicators of message 
legitimacy.   But these rules seem certain to keep changing, so IMO it 
makes sense to keep them out of the (hopefully long-term stable) SMTP spec.

Keith

---

From: "John Levine" <[email-masked]>
Date: 27 Sep 2020 01:22:21 -0400

In article <[email-masked]> you write:
>> spam filters. ...

>At some point in the past, this was _not_ a reliable spam filter. ...

I think you may be conflating SMTP and submission. For submission,
you're right, the EHLO argument is frequently some random name that a
computer thinks it has behind a couple of layers of NAT. For SMTP,
server to server, I agree with Sam that it is extremely rare for a
legit message to come from a host that doesn't know its name.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Sun, 27 Sep 2020 08:43:12 -0400

On 9/27/20 1:22 AM, John Levine wrote:

> computer thinks it has behind a couple of layers of NAT.
Well, if memory serves, that language from the 5321 originally dates 
from the days when port 25 was routinely used for submission.   So 
that's a useful point.
> For SMTP,

Okay, but should the SMTP standard effectively require that a client 
SMTP know the server's idea of its source IP address?

For example, should the standard insist that client SMTPs have and use 
an outgoing IPv4-capable interface any time the server SMTP is reached 
(directly or indirectly) via IPv4?   Or should client SMTPs be forced to 
use IPv6-to-IPv4 SMTP relays rather than NAT64?    Should we have to 
keep maintaining a public IPv4 network indefinitely (or at least until 
IPv6 is globally ubiquitous)?

To me NAT64 seems like an essential tool for transitioning to IPv6 and 
one quite often chosen by carriers, and I don't see the benefit in 
adding complexity to the SMTP signal chain  (with the consequent 
degradation of reliability)  just to preserve this rule.

Keith

---

From: Sam Varshavchik <[email-masked]>
Date: Sun, 27 Sep 2020 08:58:31 -0400

Keith Moore writes:

> assumption that if you're operating an SMTP server, you're trying in good  
> faith to deliver (legitimate) email reliably.   I'm not sure this assumption

And you should have a pretty good idea of what your IP address is.
 
> Seen from that perspective, maybe 5321's language about EHLO arguments could  
> use some updating along the following lines:
>
> - For a very many reasons [which could be listed, or not], SMTP servers have  
> no reasonable expectation of being able to determine the validity or  
> legitimacy of a message based on comparison of the EHLO command argument  
> with anything else at all.   Therefore if what you're trying to do is  
> reliably deliver legitimate mail (for some meaning of legitimate),  

The exact phraseology is only secondary. The point I was making is that I  
see that EHLO/HELO validation is employed in practice, and it is in  
practical use. And based on my own experience, it is highly effective. Like  
I said, in 20+ years I've been doing strict domain validation on HELO/EHLO I  
do not recall a single false positive, and a mind-boggling amount of crap  
that got blocked.

And I think that in practical situations this is going to outrank, in  
peoples' minds, any demand that they MUST NOT do that.

> Of course, if your goal is really to discard mail for no good reason, and  
> you're not handling incoming mail for anyone but yourself, have at it!    
> Just have the decency to blackhole the mail rather than bounce it, since  
> you're really not doing anyone any favors.

On that point I'll also have to disagree. It's better to reject the mail  
with a 5xx, than /dev/null it.

---

From: Sam Varshavchik <[email-masked]>
Date: Sun, 27 Sep 2020 09:01:36 -0400

Keith Moore writes:

> the fact that it works as a spam filter today seems like mere circumstance  
> or accident; I don't see any inherent reason that it will be a reliable spam  
> filter going into the future.   Spammers do learn, if slowly, so if they  
> have to learn to make sure their EHLO arguments match their source IP  
> addresses, they'll do that.   In the long term, I don't think this check  
> helps anything.

Yes, I agree. Domain validation is not mainstream, but it is being use in  
practice, just enough to fall under the radar stream. If for any reason –  
whether explicitly blessed in an RFC or for any other reason – it becomes  
more prevalent then spam generators will certainly adopt.

But at least right now it is a very effective filter. Like I wrote, this is  
really against my self-interest to bring more awareness to it.

---

From: "John R Levine" <[email-masked]>
Date: 27 Sep 2020 11:04:49 -0400

On Sun, 27 Sep 2020, Keith Moore wrote:
> For example, should the standard insist that client SMTPs have and use an 
> outgoing IPv4-capable interface any time the server SMTP is reached (directly 
> or indirectly) via IPv4?   Or should client SMTPs be forced to use 
> IPv6-to-IPv4 SMTP relays rather than NAT64?    Should we have to keep 
> maintaining a public IPv4 network indefinitely (or at least until IPv6 is 
> globally ubiquitous)?
>
> To me NAT64 seems like an essential tool for transitioning to IPv6 and one 
> quite often chosen by carriers, and I don't see the benefit in adding 
> complexity to the SMTP signal chain  (with the consequent degradation of 
> reliability)  just to preserve this rule.

This seems backward to me.  Keeping in mind that upwards of 90% of all 
mail is spam, and reliable spam signals are valuable, we know from 
experience that real mail servers have static addresses and matching 
forrward and reverse DNS.  Anything that comes from a dynamic or NAT pool 
is invariably spam from a botnet.

Small mail servers send and receive on the same address, so if they're 
going to work on IPv4 at all, they need a static v4 address.  Large 
providers do NAT64 for their customers, but that's not where they put 
their mail servers (or any servers that need an A record.)  They have a 
chunk of static v4 space for that, and that's where they put their 
outgoing mail hosts, too.

Also remember that mail hosts don't need a lot of address space. I've 
seen estimates of the total number of SMTP hosts in the 100,000 range.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: John C Klensin <[email-masked]>
Date: Sun, 27 Sep 2020 11:23:50 -0400

Responding to the thread, rather than any specific note...

(1) We need to tread rather carefully here.  These checks are
closely connected to checks involving address-> name mappings as
well as name-> address ones.  SMTP did not anticipate single
clients sending from multiple interfaces/addresses, nor clusters
or clouds of machines sending out traffic without clear
discrimination about the actual sending host.  While the DNS has
mechanisms that, IMO, are quite adequate for associating
multiple addresses with the same host name, my anecdotal
experience suggests that reverse-mapping records with one
address and a long list of host names are quite rare.  SMTP also
did not anticipate clients (especially when ones communicating
with submission servers are ignored) running on addresses
(whether static or dynamic) assigned by ISPs rather than
regional registries.  Independent of clients who are part of
clouds and business arrangements large enough to push ISPs
around, many ISPs refuse to create reverse mapping records at
all [1] or will not create ones that that match client
perceptions of their names rather than server-location based
names following the ITU model [2]/

And that is even before we get to questions of gateways or NATs
between IPv6 and IPv4 systems.

So, without taking a position on whether we should make changes
in this area, they, and their implications, need to be thought
through very carefully.  We should also, IMO, try to preserve
the "if two, why not more" logic used when 2821 created an
explicit prefix model for IPv6 address literals rather than
simply assuming IPv4 and IPv6 literals could be distinguished
from each other by a simple heuristic test and that we would not
ever need to worry about, e.g., candidates for IPv7, IPv10, etc.

Also, a substantive note:  people decided (fwiw, over my
objections) to create a separate email list for the emailcore
effort.   With the very recent formal creation of that WG, I'm
not going to track proposed changes for the potential 5321bis
posted to this list (and hope that the WG Chairs will soon take
that responsibility off my hands).  So, if someone would like to
see changes, take them there.

     john

[1] As handy examples pulled from this thread, 68.166.206.83 and
64.147.123.25 apparently have no reverse mapping records at all.

[2] Highly informative (if you happen to be the ISP) reverse
mappings to things like
70.88.254-40-Lynn.MA.hfc.comcastbusiness.net are fairly common.

---

From: Keith Moore <[email-masked]>
Date: Sun, 27 Sep 2020 11:33:59 -0400

On 9/27/20 11:04 AM, John R Levine wrote:

>> For example, should the standard insist that client SMTPs have and 
>> use an outgoing IPv4-capable interface any time the server SMTP is 
>> reached (directly or indirectly) via IPv4?   Or should client SMTPs 
>> be forced to use IPv6-to-IPv4 SMTP relays rather than NAT64?    
>> Should we have to keep maintaining a public IPv4 network indefinitely 
>> (or at least until IPv6 is globally ubiquitous)?
>>
>> To me NAT64 seems like an essential tool for transitioning to IPv6 
>> and one quite often chosen by carriers, and I don't see the benefit 
>> in adding complexity to the SMTP signal chain  (with the consequent 
> forrward and reverse DNS. 

I would say instead that because some subset of inbound MTAs do EHLO 
verification, "real mail servers" (i.e. those which manage to continue 
to deliver mail with some reliability) are forced to have static IPv4 
source addresses for which PTR lookup results match EHLO arguments.

In other words, "real mail servers" (i.e. client SMTPs that manage to 
deliver mail with some reliability) are forced to jump through arbitrary 
hoops in order to overcome SMTP servers' arbitrary restrictions.

> Anything that comes from a dynamic or NAT pool is invariably spam from 
> a botnet.

No, because nobody is looking that closely.   It's basically just 
prejudice that assumes that "legitimate" senders have static IP 
addresses, delegation of the corresponding zone in in-addr.arpa, and the 
knowledge to populate the PTR records.   Or to put it differently - it's 
prejudice that assumes that the only people who should be able to send 
mail are those with the resources to arrange for all of that.   (Which, 
given the shortage of IPv4 addresses, is getting more and more difficult 
to do.)

And the prejudice (like many kinds of prejudice) becomes 
self-fulfilling, because those who don't have the resources to do those 
things fail at their businesses, while those who don't necessarily care 
about delivering mail reliably (spammers, botnets) but only care about 
being able to deliver mail in significant volume, aren't eliminated.    
It's exactly the same thing as a belief that "/those/ people don't drive 
nice cars and live in nice neighborhoods, so clearly they're doing 
something sketchy and should be treated with suspicion", which then 
causes those people to be marginalized and can force some of them to 
resort to sketchy means of making a living.

So yeah, I'm not a big fan of this kind of mechanism even if it seems to 
work under current conditions.    I certainly don't think it belongs in 
a stable protocol specification, because it relies on conditions that 
can and should change over time.

> their mail servers (or any servers that need an A record.)  They have 
> a chunk of static v4 space for that, and that's where they put their 

We need to give some thought to how this works across a transition away 
from a ubiquitous public IPv4 Internet, to an Internet that is a mixture 
of IPv4 and IPv6 (where not all parties have IPv4 access) and tied 
together by NATs of various kinds and interception proxies, and 
subsequently to an Internet in which IPv6 is ubiquitous and IPv4 is the 
rare exception.

To me it appears that EHLO argument verification imposes unreasonable 
constraints on enterprise networks, mail providers, and network 
operators which have nothing to do with the legitimacy of their content.

> seen estimates of the total number of SMTP hosts in the 100,000 range.

Fair, but why should we need to retain _any_ semblance of a public IPv4 
Internet just so mail can be delivered reliably as the Internet 
transitions to IPv6?   Or alternatively, why should there need to be a 
flag day at which SMTP servers have to turn off EHLO verification?

Keith

---

From: "John R Levine" <[email-masked]>
Date: 27 Sep 2020 11:40:27 -0400

> verification, "real mail servers" (i.e. those which manage to continue to 
> deliver mail with some reliability) are forced to have static IPv4 source 
> addresses for which PTR lookup results match EHLO arguments.

No, we've observed in practice that hosts that don't have matching PTRs 
are spambots.

>> Anything that comes from a dynamic or NAT pool is invariably spam from a 
>> botnet.
>
> No, because nobody is looking that closely.

Sorry, but you're just wrong.  We absolutely look that closely.  I know 
people who maintain pools of patterns to recognize dynamic pool rDNS which 
lots of people use in their spam scoring.

It would be nice if mail still worked the way it did 30 years ago, but 
that was most definitely then, and this is now.

Regards,

---

From: Keith Moore <[email-masked]>
Date: Sun, 27 Sep 2020 11:43:10 -0400

On 9/27/20 11:40 AM, John R Levine wrote:

>> verification, "real mail servers" (i.e. those which manage to 
>> continue to deliver mail with some reliability) are forced to have 
>> static IPv4 source addresses for which PTR lookup results match EHLO 
>> arguments.
>
> No, we've observed in practice that hosts that don't have matching 
> PTRs are spambots.

I don't believe that anyone takes enough time to look at a sufficient 
volume of email, often enough, to be sure of that. And again, it's a 
self-fulfilling belief.

>
>>> Anything that comes from a dynamic or NAT pool is invariably spam 
>>> from a botnet.
>>
> Sorry, but you're just wrong.  We absolutely look that closely.  I 
> know people who maintain pools of patterns to recognize dynamic pool 
> rDNS which lots of people use in their spam scoring.

I didn't say it wasn't used, I said it wasn't reliably measured.

> that was most definitely then, and this is now.
And poorly chosen spam filters are a big reason for the degradation of 
email reliability during that time.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Sun, 27 Sep 2020 09:29:24 -0700

On 9/27/2020 8:33 AM, Keith Moore wrote:
> addresses, delegation of the corresponding zone in in-addr.arpa, and 
> the knowledge to populate the PTR records.
>

John L. has been correctly summarizing what members of M3AAWG have been 
quite consistent about, for many years.  It is part of the reason that 
running a legitimate mail server on the open Internet, these days, 
requires a significant amount of knowledge about the rather elaborate 
set of expected configuration and procedure.

Properly registering the domain name and the IP address, forward and 
backwards, has been one of the more basic and practical requirements for 
at least 10 years, that I know of, but probably a lot longer.

As for 'prejudice', I encourage folk to spend some time around the 
anti-abuse industry and learn more about how it operates, since it takes 
a 95% spam level for incoming mail and brings in down to a tiny percent.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Sun, 27 Sep 2020 09:31:41 -0700

> volume of email, often enough, to be sure of that. And again, it's a 

Keith,

Exactly how much experience do you have with the real-world practices of 
the real-world anti-abuse industry?

I'm asking not as an ad hominem, but in order to try to find out how 
your blanket rejection can be so wildly different from what I see within 
M3AAWG.  For many years.

d/

---

From: Russ Allbery <[email-masked]>
Date: Sun, 27 Sep 2020 09:32:52 -0700

> people who maintain pools of patterns to recognize dynamic pool rDNS
> which lots of people use in their spam scoring.

It's effectively impossible to get reliable mail delivery from a dynamic
pool these days because of how frequently it is used for spam (so
providers start blocking outbound 25) and as a spam signature (because
it's so frequently used for spam).  Therefore people (like me) who would
happily be sending mail directly from dynamic ranges instead configure our
systems to route through a cloud server with a static IP address, and
therefore show up in your statistics as reinforcing that all mail comes
from static IPs.

In other words, I think you're both right.  Keith is clearly correct that
we accepted a whole lot of false positives and discarded a lot of valid
mail when we started down the path of blocking all mail from dynamic
ranges, but that was the tradeoff decision that most of the mail
recipients made at the time (for defensible reasons).  It's now become a
self-sustaining situation: it's so widely known that dynamic ranges are
just spam that deliverability is awful, and therefore legitimate senders
are effectively forced to go extra expense to avoid using dynamic ranges,
and therefore nearly all mail still sent from dynamic ranges is spam.

I think one can argue about whether or not it was a bad tradeoff, but at
this point I think it's water under the bridge and I find it hard to
imagine how we would reverse those decisions.  They weren't standards
decisions; they were decisions made by an ad hoc consensus of mail
recipients.

-- 
Russ Allbery ([email-masked])             <https://www.eyrie.org/~eagle/>

---

From: John C Klensin <[email-masked]>
Date: Sun, 27 Sep 2020 12:36:38 -0400

--On Sunday, September 27, 2020 11:40 -0400 John R Levine
<[email-masked]> wrote:

>> I would say instead that because some subset of inbound MTAs
>> do EHLO  verification, "real mail servers" (i.e. those which
>> manage to continue to  deliver mail with some reliability)
>> are forced to have static IPv4 source  addresses for which
>> PTR lookup results match EHLO arguments.
> 
> No, we've observed in practice that hosts that don't have
> matching PTRs are spambots.
>...
>>> Anything that comes from a dynamic or NAT pool is invariably
>>> spam from a  botnet.
>...

John,

(as with Keith earlier comment, this is not intended to be a
rant, but might come out sounding that way)

This is a self-fulfilling prophecy which gets back to Keith's
comment about resources.  In order to run an SMTP client or
server with any of the three ISPs I've dealt with recently, and
do so without violating the contracts they impose, I first have
to obtain a business account which is not much different from a
residential account other than costing three or four times as
much.  Because the anti-spam powers that be don't think I should
be running either an SMTP server or a client on dynamic
addresses (even if I have dynamic DNS set up properly and
appropriate MX arrangements), I have to then obtain one or more
static addresses from said ISP and the costs of those are not
going down [1].   And, since the idea of delegating
reverse-mapping ranges on bit boundaries failed, once one has
those static addresses, one than has to convince the ISP to
provide the correct reverse mapping.  That, too, has costs -
either in terms of money or in efforts to negotiate.  There may
be ISPs out there who, upon supplying a static address  or
address range inquire how one would like the reverse mapping
records to read, or even insist on getting that information, but
I haven't encountered one yet.

So, if the goal, however unintentionally, is to further reduce
the number of independent (and legitimate) SMTP clients and
servers, and force those without extensive resources to shift
over to large and dominant email providers, perhaps we are on
track.

> It would be nice if mail still worked the way it did 30 years
> ago, but that was most definitely then, and this is now.

And, from the standpoint of those large providers, the fight
against spam and other sorts of evil behavior would be ever so
much easier if they had only a handful of other providers to
work with s.t. anything not coming from one of them was suspect.
Of course, the way DMARC was developed and deployed might be
believed to reflect exactly that attitude.

    john

[1] I don't know that I believe it but I've heard it suggested
that some ISPs are doing less than they might to encourage IPv6
adoptions because they couldn't get away with charging nearly as
much for static addresses in that space.

---

From: Keith Moore <[email-masked]>
Date: Sun, 27 Sep 2020 12:39:20 -0400

On 9/27/20 12:29 PM, Dave Crocker wrote:

> John L. has been correctly summarizing what members of M3AAWG have 
> been quite consistent about, for many years.  It is part of the reason 
> that running a legitimate mail server on the open Internet, these 
> days, requires a significant amount of knowledge about the rather 
> elaborate set of expected configuration and procedure.

I find that very prejudiced notion of "legitimate" offensive. 
"legitimate" is legitimate content, nothing more or less.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sun, 27 Sep 2020 12:40:45 -0400

On 9/27/20 12:31 PM, Dave Crocker wrote:

> Exactly how much experience do you have with the real-world practices 
> of the real-world anti-abuse industry?
>
It has cost me tens of thousands of dollars, and those are the cases I 
know about.

I see all the time that ordinary people cannot send mail reliably.   I 
understand that spam filtering is a daunting problem, but don't talk to 
me about legitimacy when the practices harm ordinary users' ability to 
use email.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sun, 27 Sep 2020 12:42:09 -0400

On 9/27/20 12:32 PM, Russ Allbery wrote:

> I think one can argue about whether or not it was a bad tradeoff,

Yes, that part is water under the bridge.   I'm arguing that it's still 
a heuristic based on temporary conditions that can and should change in 
the future, and therefore should not be standardized.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Sun, 27 Sep 2020 09:43:01 -0700

> "legitimate" is legitimate content, nothing more or less.

Ahh.  Ok.

You are rejecting industry standard practice, because you disapprove of 
some of its methods.

Apparently you are imposing a set of criteria for deciding upon how to 
evaluate massive streams of mail that have very poor signal to noise 
rations that differ from the folk who have to process those massive streams.

Thanks for the clarification.

d/

---

From: Dave Crocker <[email-masked]>
Date: Sun, 27 Sep 2020 09:44:45 -0700

On 9/27/2020 9:36 AM, John C Klensin wrote:
> So, if the goal, however unintentionally,

If it is not intentional, it is not a goal.

d/

---

From: Keith Moore <[email-masked]>
Date: Sun, 27 Sep 2020 12:46:12 -0400

On 9/27/20 12:43 PM, Dave Crocker wrote:

>
> You are rejecting industry standard practice, because you disapprove 
> of some of its methods.

NO, I'm rejecting it because it does tremendous harm to email and has 
actually ruined email for most of the ordinary people I know.

Keith

---

From: "John R Levine" <[email-masked]>
Date: 27 Sep 2020 12:53:36 -0400

> much. ...

For reasons many but not all of which are related to Redmond WA, 
residential networks are so thoroughly infected with botnets that ISPs 
block outbound port 25 connections out of self defense.  They can't afford 
to deal with the complaints otherwise.

On the other hand, if you want to run your own mail server, setting up a 
BSD or Linux VPS with matching f/rDNS is not hard and not expensive.  I 
have a tiny one (20GB disk, 512MB RAM, 1TB/mo) for $27/yr and a reasonably 
cqpable one (30GB/1GB/2TB) for $43.20/yr.  To set the rDNS I just put in a 
ticket which they typically handle within a few hours, no extra charge. I 
presume they check that there's forward DNS to match.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Sun, 27 Sep 2020 10:01:00 -0700 (PDT)

> rant, but might come out sounding that way)

A pretty even-handed description of the situation IMO.

> much.

Around here the service isn't much more expensive, but getting it at
a residental location is difficult at best, impossible at worst.

Of course there's always the option of deplying in someone's cloud, but that
has issues of its own. For one thing, you're far more likely to get nailed by a
noisy neighbor in the cloud. (One of my neighbors is having exactly this issue
right now.)

> Because the anti-spam powers that be don't think I should
> going down [1].

Add to that the number of providers who actually offer static IPs is
dropping, and the geographies where the remaining ones are
able to provide the service are also decreasing.

> And, since the idea of delegating

Around here we have:

(1) HugeISP - I managed to get them to set my reverse names when my service
    was installed. As for updates, their elaborate web site, where
    my name appears as "null CUSTOMER", is so difficult to navigate it's
    impossible to be sure, but there doesn't seem to be a way to do it.
    But there is good news: They do let you give your modem a nickname.
    (I chose "Joe Egg".) So I guess a service ticket is necessary. Past
    experience with those has been mixed.

(2) MediumISP - Back when I used their service they had a really convenient
    web page that let you set them. 24 hour max turnaround. Sweet. The bad news
    is they are one of the ISPs who no longer offer static IPs in this
    area. 
    
(3) TinyISP - You call "the guy" and he takes care of it when he has a
    moment. Usually takes a day or two.

(4) FiberISP - Send mail to [email-masked] saying what you want
    changed. They stopped their buildout two blocks down the road because
    of a lawsuit, so no direct experience, but reportedly the possible
    responses include (a) Done and dusted, (b) You need to pay $$$ for that,
    and (c) Huh?

> over to large and dominant email providers, perhaps we are on

The other thing that's worth noting is the frequency of forced IP address
changes. I've had this happen four times in the past 20 years, and each time
getting the PTRs set up has been the worst part of the process. And yes, it has
resulted in lost mail, so please don't try and tell me these checks never
impact legitimate senders.

> believed to reflect exactly that attitude.

Such a cynic ;-)

>     john

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 27 Sep 2020 15:24:37 -0400

>> believed to reflect exactly that attitude.

Having been around while DMARC was being designed, I don't think that was 
even a little bit the plan.  The goal was to deter phishing of major 
targets like Paypal.  Then AOL and Yahoo abused it and it's been downhill 
from there.

We have a problem that I think is insoluble: there is a long tail of mail 
senders, most of people in the tail don't know what they're doing, and 
spammers have made it impossible to give senders the benefit of the doubt. 
Given the prevalence and maliciousness of spam, much of which comes from 
compromised hosts whose nominal owners have no clue, if it doesn't look 
squeaky clean, it's probably malware.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Sun, 27 Sep 2020 15:53:47 -0400

On 9/27/20 3:24 PM, John R Levine wrote:

> We have a problem that I think is insoluble: there is a long tail of 
> mail senders, most of people in the tail don't know what they're doing, 

The bar for "knowing what you're doing" has been raised considerably.   
What used to be simple has become a black art.

> and spammers have made it impossible to give senders the benefit of 
> the doubt. Given the prevalence and maliciousness of spam, much of 
> which comes from compromised hosts whose nominal owners have no clue, 
> if it doesn't look squeaky clean, it's probably malware. 

Every time I see a statement like that that doesn't even consider the 
false positive rate, my bogometer pegs.   It's like the elephant in the 
room that nobody wants to talk about.

Keith

p.s. However, we don't have to revisit the whole spam problem in order 
to decide what 5321bis should say about EHLO verification.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 27 Sep 2020 13:08:59 -0700

On 9/27/2020 12:53 PM, Keith Moore wrote:
> false positive rate, my bogometer pegs.   It's like the elephant in 
> the room that nobody wants to talk about.

1. Since it wasn't trying to provide a comprehensive statement about all 
of the factors that go into the balancing act of real-world email 
filtering, your criticism for what it doesn't cover is claiming a 
failure to cover something that wasn't in scope.

2. You appear to be implying that folk running email services don't 
worry about false positives.  But I'll be that you know they must.

3. In fact in rooms where folk who do actual anti-abuse operations talk, 
they do talk about false positives.  (duh).

4. This ain't one of those rooms, since few of those folk are hear and 
that isn't the topic for this room.

d/

---

From: Sam Varshavchik <[email-masked]>
Date: Sun, 27 Sep 2020 16:30:37 -0400

> 64.147.123.25 apparently have no reverse mapping records at all.

;; ANSWER SECTION:
83.206.166.68.in-addr.arpa. 4156 IN	PTR	mailx.courier-mta.com.

;; AUTHORITY SECTION:
166.68.in-addr.arpa.	71418	IN	NS	ns3.gtt.net.
166.68.in-addr.arpa.	71418	IN	NS	ns2.gtt.net.
166.68.in-addr.arpa.	71418	IN	NS	ns1.gtt.net.

The somewhat cumbersome https://mxtoolbox.com/ReverseLookup.aspx verified  
that it's not just the little bubble of the Intertubes that I live in can  
see this reverse mapping.

Anyway, the only point I made is that I believe that the MUST NOT, when it  
comes to EHLO/HELO validation, is frequently ignored in practice. Those who  
are of the opinion that validation is bad practice, nobody will force them  
to do it. And those who do believe that it filters out a bunch of crap will  
do it; they will ignore the MUST NOT. That's it.

---

From: Claus Assmann <[email-masked]>
Date: Sun, 27 Sep 2020 22:39:11 +0200

> 64.147.123.25 apparently have no reverse mapping records at all.

Hmm, not sure why you saying that?

83.206.166.68.in-addr.arpa. 38400 IN	PTR	mailx.courier-mta.com.
25.123.147.64.in-addr.arpa. 3597 IN	PTR	wout2-smtp.messagingengine.com.

DNS problems? Those are sooo much fun to resolve :-(

---

From: Keith Moore <[email-masked]>
Date: Sun, 27 Sep 2020 17:24:52 -0400

> that isn't the topic for this room.
Because degradation of email reliability isn't at all relevant to ietf-smtp?

Keith

---

From: Dave Crocker <[email-masked]>
Date: Sun, 27 Sep 2020 15:00:34 -0700

> Because degradation of email reliability isn't at all relevant to 

gosh, Keith.  Don't you consider 95% spam in email over the Internet to 
be a degradation worthy of attention?

Simple suggestion:  Since you take considerable exception to common 
email anti-abuse practices, how about providing a detailed plan for an 
alternative approach and demonstrate its efficacy?

For extra points, get some actual email services to adopt it.

d/

---

From: Keith Moore <[email-masked]>
Date: Sun, 27 Sep 2020 19:15:33 -0400

On 9/27/20 6:00 PM, Dave Crocker wrote:

> gosh, Keith.  Don't you consider 95% spam in email over the Internet 
> to be a degradation worthy of attention?

Of course I do, but ONLY if the degradation due to spam filtering is 
part of the picture.

> alternative approach and demonstrate its efficacy?

Simple suggestion:   Why don't you stop pretending that this isn't a 
problem?   Or maybe, stop trying to change the subject any time this 
gets uncomfortable?

Keith

---

From: Sam Varshavchik <[email-masked]>
Date: Sun, 27 Sep 2020 19:55:50 -0400

Keith Moore writes:

>> gosh, Keith.  Don't you consider 95% spam in email over the Internet to be a  
>> degradation worthy of attention?
>
> Of course I do, but ONLY if the degradation due to spam filtering is part of  
> the picture.

Any "degradation due to spam filtering" is only due to the spam's existence  
itself. If there were no spam, there wouldn't be any spam filtering to  
degrade anything. Spam filtering is not a problem, it's a reaction to a  
problem.

Furthermore, nobody has any real standing to complain about anyone else's  
spam filtering. I have no standing to take issue with whatever spam  
filtering you employ, no matter what I think of its merits. And if you don't  
do any spam filtering, that's wonderful. However, neither do you have any  
standing to take issue with anyone else's spam filtering, either.

Once this basic fundamental fact is established – that anyone is free to  
configure their mail servers in whaever whey they deem to see fit and they  
are no obligation to accomodate any external third party's desires or  
opinions – then any pontifications on the negative effects on spam  
filtering become nothing more than philosophical discussions, void of any  
practical application. Anyone is free to campaign as much as they wish about  
whatever undesirable effects of spam filtering they object to. They won't  
have any effect. People will continue to use spam filtering methods that  
work for them, and not the ones that some other third party approves of, in  
some way.

>> Simple suggestion:  Since you take considerable exception to common email  
>> anti-abuse practices, how about providing a detailed plan for an alternative  
>> approach and demonstrate its efficacy?
>
> problem?   Or maybe, stop trying to change the subject any time this gets  
> uncomfortable?

What problem? I see no problem with spam filtering, whatsoever. And I see no  
problem with EHLO/HELO domain validation. It's a very effective spam filter,  
and I will continue to use it. I do not believe that I have a unique, or a  
novel, take on this subject matter.

---

From: Keith Moore <[email-masked]>
Date: Sun, 27 Sep 2020 20:01:07 -0400

On 9/27/20 7:55 PM, Sam Varshavchik wrote:

> Any "degradation due to spam filtering" is only due to the spam's 
> existence itself. If there were no spam, there wouldn't be any spam 
> filtering to degrade anything. Spam filtering is not a problem, it's a 
> reaction to a problem.

Emphatically disagree.   Anytime a legitimate message isn't delivered 
due to spam filtering, the spam filtering IS the problem.

>
> Furthermore, nobody has any real standing to complain about anyone 
> else's spam filtering. 

Emphatically disagree.  Users should have a reasonable expectation of 
having their mail delivered without having to stand on their heads and 
beat a syncopated rhythm with a walrus appendage on a skin drum during a 
full moon.

> Once this basic fundamental fact is established 

as soon as you start stating relevant facts, I'll listen.

> – that anyone is free to configure their mail servers in whaever whey 
> they deem to see fit and they are no obligation to accomodate any 
> external third party's desires or opinions – then any pontifications 
> on the negative effects on spam filtering become nothing more than 
> philosophical discussions, void of any practical application. Anyone 
> is free to campaign as much as they wish about whatever undesirable 
> effects of spam filtering they object to. They won't have any effect. 
> People will continue to use spam filtering methods that work for them, 
> and not the ones that some other third party approves of, in some way.

Irrelevant.   For the most part, "people" don't choose their spam 
filtering; they have it imposed on them and often have zero control over 
it except to try a different email address.

Keith

---

From: Sam Varshavchik <[email-masked]>
Date: Sun, 27 Sep 2020 20:13:41 -0400

Keith Moore writes:

> Emphatically disagree.   Anytime a legitimate message isn't delivered due to  
> spam filtering, the spam filtering IS the problem.
>
>>
>> spam filtering.
> Emphatically disagree.  Users should have a reasonable expectation of having  
> their mail delivered without having to stand on their heads and beat a  
> syncopated rhythm with a walrus appendage on a skin drum during a full moon.

Anyone around here been on Usenet in the late 1990s, and remember this on- 
going flamewar, how spam filtering is detrimental, how everyone has an  
entitled right to have their email delivered, yadda yadda yadda?

That's what this reminds me of. I'm really getting a sense of deja vu here.

>> they object to. They won't have any effect. People will continue to use  
>> spam filtering methods that work for them, and not the ones that some other  
>> third party approves of, in some way.
>
> Irrelevant.   For the most part, "people" don't choose their spam filtering;  
> they have it imposed on them and often have zero control over it except to  
> try a different email address.

That was another frequent theme on news.admin.net-abuse.email, circa  
1990s – how people are suffering victims of their administrators' draconian  
spam filtering policies.

Well, those arguments weren't exactly widely accepted back then, and I don't  
think they're widely accepted now, either.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 27 Sep 2020 17:18:11 -0700

> Of course I do, but ONLY if the degradation due to spam filtering is 

Please provide documentation that the people running serious email 
platforms do not already include that factor in their decision-making.

> problem?   Or maybe, stop trying to change the subject any time this 

Please provide documentation that I have said it isn't a problem.

As for changing the subject, I am indeed trying to alter it. I would to 
move its treatment in this forum from standalone, idealistic and 
apparently-uninformed statements of impractical absolutes to, instead, 
acknowledging the balancing act this is inherent in any real-world, 
imperfect analysis process of human behavior, such as email.

My usual reference to such tradeoffs is Type I vs. Type II.

d/

--

---

From: Keith Moore <[email-masked]>
Date: Sun, 27 Sep 2020 20:21:58 -0400

On 9/27/20 8:13 PM, Sam Varshavchik wrote:

>
> Anyone around here been on Usenet in the late 1990s, and remember this 
> on-going flamewar, how spam filtering is detrimental, how everyone has 
> an entitled right to have their email delivered, yadda yadda yadda?
>

I was around then.      But if you don't think that users care whether 
their email is delivered, you're not paying much attention to users.

Ordinary users simply don't trust email to work.   They'll use email 
only as a last resort, and if they really need to send email, will try 
random combination of sender and recipient addresses (because people 
often need multiple addresses to try to negotiate the mess).   It's that 
bad.

>
>>> they object to. They won't have any effect. People will continue to 
>>> use spam filtering methods that work for them, and not the ones that 
>>> some other third party approves of, in some way.
>>
>> filtering; they have it imposed on them and often have zero control 
>> over it except to try a different email address.
>
> 1990s – how people are suffering victims of their administrators' 
> draconian spam filtering policies.
>
> Well, those arguments weren't exactly widely accepted back then, and I 
> don't think they're widely accepted now, either.

Just because people refuse to accept the truth doesn't mean it isn't true.

But this is a silly discussion.  I certainly acknowledge that spam 
filtering is hard, and that the state of the art is to use unreliable 
heuristics.   The point is, even if it's the best that we can currently 
do, it still doesn't work very well.   We do no credit to ourselves if 
we put our heads in the sand and mutter "it's not a problem!".

Keith

---

From: Keith Moore <[email-masked]>
Date: Sun, 27 Sep 2020 20:25:01 -0400

> platforms do not already include that factor in their decision-making.

Again you're trying to change the subject.   I'm not talking about their 
discussions.   I'm talking about THIS discussion.

> As for changing the subject, I am indeed trying to alter it. I would 
> to move its treatment in this forum from standalone, idealistic and 
> apparently-uninformed statements of impractical absolutes to,

This is where we would need a chair or SAA to step in if we had one.     
Since we don't have one, Dave, I am calling you out for abusive behavior.

Keith

---

From: "John Levine" <[email-masked]>
Date: 27 Sep 2020 20:26:43 -0400

>entitled right to have their email delivered, yadda yadda yadda?

I'm definitely getting a 1990s vibe here.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Sun, 27 Sep 2020 20:33:05 -0400

> I'm definitely getting a 1990s vibe here.

If anything, the state of email delivery is worse now than it was then.

(of course, email spam wasn't as bad then as it is now.)

Keith

---

From: Richard Clayton <[email-masked]>
Date: Mon, 28 Sep 2020 01:51:16 +0100

In message <[email-masked]>,
Keith Moore <[email-masked]> 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 certainly acknowledge that spam 
>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.

Since the only practical way of tuning these algorithms is end-user
free-back that means that special precautions are needed to (a) ensure
that the bad guys do not detune them by "gaming" and (b) that even if
large numbers of people give the feedback that their cellphone bill is
spam this does not override the fact that treating everyone's cellphone
bill as spam would not be a Good Thing

"Heuristics" ... that is, human generated rules which give consensus
"scores" to the spammy-ness of email are far less effective (and we have
25 or so years of experience to demonstrate that).

Now of course, tuning the ML clustering algorithms is especially
difficult if you don't see enough email (ie not billions a day) because
almost everything is too unique to cluster.  But that doesn't make
heuristics "state of the art" -- it just indicates that there's a
failure to by the community as a whole (rather than a handful of very
large providers) to develop ways to share pre-tuned clustering models. 

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

---

From: Dave Crocker <[email-masked]>
Date: Sun, 27 Sep 2020 18:10:04 -0700

On 9/27/2020 5:21 PM, Keith Moore wrote:
> Ordinary users simply don't trust email to work. 

More blanket certitude. Please document that claim.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

Volunteer,Silicon Valley Chapter
American Red Cross
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Sun, 27 Sep 2020 18:11:14 -0700

On 9/27/2020 5:25 PM, Keith Moore wrote:
> This is where we would need a chair or SAA to step in if we had 
> one.     Since we don't have one, Dave, I am calling you out for 
> abusive behavior. 

Please explain that carefully, because I don't see it.  As you do that, 
note it against you own statements.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Keith Moore <[email-masked]>
Date: Sun, 27 Sep 2020 21:26:14 -0400

On 9/27/20 8:51 PM, Richard Clayton wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

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

> 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:

> 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

---

From: Sam Varshavchik <[email-masked]>
Date: Sun, 27 Sep 2020 21:51:57 -0400

Keith Moore writes:

> 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

To me, "SHOULD NOT" is a better match for "should not be encouraged". The  
current phrasing, "MUST NOT", prohibits it.

Whether or not EHLO domain validation is prohibited or not, it is used in  
practice right now, and the current language in 5321 is being ignored, to  
some degree. The same language also existed in 2821, so this has been  
ignored for a while. An Internet standard that does not reflect current  
practice is not as valuable as one which is.

---

From: Keith Moore <[email-masked]>
Date: Sun, 27 Sep 2020 22:00:07 -0400

On 9/27/20 9:51 PM, Sam Varshavchik wrote:

> Keith Moore writes:
>
>> 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
>
> To me, "SHOULD NOT" is a better match for "should not be encouraged". 
> The current phrasing, "MUST NOT", prohibits it.

I might agree with that, though I would also like to see some 
elaboration as to why it's a Bad Idea in the long run, rather than just 
SHOULD NOT.

(I have a little but of trouble with the current 5321 language, because 
it conflicts with the notion that an SMTP server can reject mail for any 
reason.    At best the juxtaposition of these two seems conflicting and 
confusing even though I think that EHLO verification is overall a 
shortsighted idea that should be discouraged.)

>
> Whether or not EHLO domain validation is prohibited or not, it is used 
> in practice right now, and the current language in 5321 is being 
> ignored, to some degree. The same language also existed in 2821, so 
> this has been ignored for a while. An Internet standard that does not 
> reflect current practice is not as valuable as one which is.

I actually disagree.   The purpose of a protocol specification standard 
should not be to reflect current practice; it should be to specify 
desirable practice.    And it's important to not confuse the two goals.

However I will admit that if the standard specifies a practice that 
doesn't interoperate well with current practice, it can harm the 
effectiveness of the standard.

Keith

---

From: Laura Atkins <[email-masked]>
Date: Mon, 28 Sep 2020 09:38:55 +0100

> On 28 Sep 2020, at 03:00, Keith Moore <[email-masked]> wrote:
> 
>>> 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
>> 
>> To me, "SHOULD NOT" is a better match for "should not be encouraged". The current phrasing, "MUST NOT", prohibits it.
> 
> I might agree with that, though I would also like to see some elaboration as to why it's a Bad Idea in the long run, rather than just SHOULD NOT.
> 
> (I have a little but of trouble with the current 5321 language, because it conflicts with the notion that an SMTP server can reject mail for any reason.    At best the juxtaposition of these two seems conflicting and confusing even though I think that EHLO verification is overall a shortsighted idea that should be discouraged.)
> 
>> 
>> Whether or not EHLO domain validation is prohibited or not, it is used in practice right now, and the current language in 5321 is being ignored, to some degree. The same language also existed in 2821, so this has been ignored for a while. An Internet standard that does not reflect current practice is not as valuable as one which is.
> 
> I actually disagree.   The purpose of a protocol specification standard should not be to reflect current practice; it should be to specify desirable practice.    And it's important to not confuse the two goals.
> 
> However I will admit that if the standard specifies a practice that doesn't interoperate well with current practice, it can harm the effectiveness of the standard.

Do you think if the wording in the RFC is changed that established behavior will change? That the SMTP servers will be reconfigured to stop doing what they are doing? 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741		

Email Delivery Blog: https://wordtothewise.com/blog

---

From: Keith Moore <[email-masked]>
Date: Mon, 28 Sep 2020 06:38:15 -0400

On 9/28/20 4:38 AM, Laura Atkins wrote:

> Do you think if the wording in the RFC is changed that established 
> behavior will change? That the SMTP servers will be reconfigured to 
> stop doing what they are doing?

I think most operators will not bother to change their existing 
practices if/when the RFC wording changes.   But if the RFC recommends 
poor practice, it will be harder to change that poor practice, because 
some people will say "but the RFC says...!"   So the RFC should not 
recommend poor practice.

If, OTOH, the RFC recommends NOT filtering based on EHLO arguments, then 
it will be at least a bit easier for operators to stop doing that when 
they start seeing that it's a bad idea.

I'm thinking long term here.   I expect 5321bis, if we do our jobs 
right, to be around for decades.   So its recommendations need to make 
sense in the long term rather than the short term.

It doesn't actually bother me that much if existing operators filter 
based on EHLO validation as long as they re-evaluate that policy over 
time.   I expect operators to be pragmatists.   But I really do expect 
use of NAT64 to increase, and I really think it's unhelpful to network 
operators if reliable email operation requires them all to maintain 
static IPv4 addresses and connections to the public IPv4 Internet.   
It's silly for email to delay a transition away from IPv4 for this reason.

Keith

---

From: Laura Atkins <[email-masked]>
Date: Mon, 28 Sep 2020 13:04:11 +0100

> On 28 Sep 2020, at 11:38, Keith Moore <[email-masked]> wrote:
> 
> I think most operators will not bother to change their existing practices if/when the RFC wording changes.  

That’s what I thought. 

> But if the RFC recommends poor practice, it will be harder to change that poor practice, because some people will say "but the RFC says...!"   So the RFC should not recommend poor practice.

What is your evidence that it is poor practice? 

> If, OTOH, the RFC recommends NOT filtering based on EHLO arguments, then it will be at least a bit easier for operators to stop doing that when they start seeing that it's a bad idea.

What is your evidence that it’s a bad idea?

> I'm thinking long term here.   I expect 5321bis, if we do our jobs right, to be around for decades.   So its recommendations need to make sense in the long term rather than the short term.

That presumes that your recommendation makes sense and that allowing any random NATed machine to connect to the internet and send mail is a good thing. I think we have ample evidence that this is actually an abuse vector and a bad thing. What changes do you see happening that will make this currently good practice become a bad one. 

> It doesn't actually bother me that much if existing operators filter based on EHLO validation as long as they re-evaluate that policy over time.   I expect operators to be pragmatists.   But I really do expect use of NAT64 to increase, and I really think it's unhelpful to network operators if reliable email operation requires them all to maintain static IPv4 addresses and connections to the public IPv4 Internet.   It's silly for email to delay a transition away from IPv4 for this reason.

Can you explain this use case in more detail? 

laura 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741

---

From: Keith Moore <[email-masked]>
Date: Mon, 28 Sep 2020 08:53:10 -0400

On 9/28/20 8:04 AM, Laura Atkins wrote:

>
>> But if the RFC recommends poor practice, it will be harder to change 
>> that poor practice, because some people will say "but the RFC 
>> says...!"   So the RFC should not recommend poor practice.
>
>> If, OTOH, the RFC recommends NOT filtering based on EHLO arguments, 
>> then it will be at least a bit easier for operators to stop doing 
>> that when they start seeing that it's a bad idea.
>

I've made those arguments multiple times already.  "evidence" seems like 
the wrong thing to ask for because this is really a question of /design/ 
- what choices should be made to allow the email network to continue 
operating seamlessly and efficiently in the event of widespread use of 
NAT within the network (either to gateway between IPv4 and IPv6 or to 
economize use of IPv4 space)?

>> right, to be around for decades.   So its recommendations need to 
>> make sense in the long term rather than the short term.
>
> That presumes that your recommendation makes sense and that allowing 
> any random NATed machine to connect to the internet and send mail is a 
> good thing. I think we have ample evidence that this is actually an 
> abuse vector and a bad thing.

I disagree.   At one time NAT was mostly associated with consumer grade 
routers, therefore NATted mail was unlikely to originate from a mail 
service provider, and more likely to originate from a compromised PC.   
But "carrier grade" or "large scale" NATs are increasingly being used 
within the network (rather than only at the periphery) in order to 
maximize use of IPv4 address space in the face of increasing address 
scarcity.   Various flavors of NAT have also emerged as the likely best 
way to exchange traffic between IPv6 and IPv4, and their use is also 
increasing.

> What changes do you see happening that will make this currently good 
> practice become a bad one.

The changes I see happening include the increasing scarcity of IPv4 
address space and the consequent emergence of IPv6-only network 
providers using NAT to move packets between IPv4 and IPv6 addressing 
domains.  I'm also anticipating the need to eventually phase out the 
public IPv4 Internet altogether.

(From operators' perspective: how long does it make sense for every 
network to maintain its IPv4 baggage, just so that email won't be 
blocked?   At the very least we need input from network operators.)

>> time.   I expect operators to be pragmatists.   But I really do 
>> expect use of NAT64 to increase, and I really think it's unhelpful to 
>> network operators if reliable email operation requires them all to 
>> maintain static IPv4 addresses and connections to the public IPv4 
>> Internet.   It's silly for email to delay a transition away from IPv4 
>> for this reason.
>

I'm not sure what I've left out.

Keith

---

From: Laura Atkins <[email-masked]>
Date: Mon, 28 Sep 2020 14:10:06 +0100

> On 28 Sep 2020, at 13:53, Keith Moore <[email-masked]> wrote:
> 
> I've made those arguments multiple times already.  "evidence" seems like the wrong thing to ask for because this is really a question of design - what choices should be made to allow the email network to continue operating seamlessly and efficiently in the event of widespread use of NAT within the network (either to gateway between IPv4 and IPv6 or to economize use of IPv4 space)?
> 
I’ve seen lots of arguments, yes, but I’ve not seen any real evidence backing up your assertions. I’m trying to better understand your point of view and understand why this is so important. But it’s been hard to find that in the sniping. 

The design question is one that should be discussed, but is this the correct space for that? 
>> That presumes that your recommendation makes sense and that allowing any random NATed machine to connect to the internet and send mail is a good thing. I think we have ample evidence that this is actually an abuse vector and a bad thing.
> I disagree.   At one time NAT was mostly associated with consumer grade routers, therefore NATted mail was unlikely to originate from a mail service provider, and more likely to originate from a compromised PC.   But "carrier grade" or "large scale" NATs are increasingly being used within the network (rather than only at the periphery) in order to maximize use of IPv4 address space in the face of increasing address scarcity.   Various flavors of NAT have also emerged as the likely best way to exchange traffic between IPv6 and IPv4, and their use is also increasing.
> 
I understand carrier grade nat, thank you. 

I was struggling to come up with use cases. I understand the use case now, and better understand why you’re bringing this up thinking about the v6 to v4 NATing going on. 
>> What changes do you see happening that will make this currently good practice become a bad one. 
> The changes I see happening include the increasing scarcity of IPv4 address space and the consequent emergence of IPv6-only network providers using NAT to move packets between IPv4 and IPv6 addressing domains.  I'm also anticipating the need to eventually phase out the public IPv4 Internet altogether.    
> 
Or we could write the BIS to recommend anyone running v4 services also provide v6 services, couldn’t we? Take the burden off the v6 only systems which are likely newer entrants and put it on the ‘old timers’ who’ve been around for decades. 
> (From operators' perspective: how long does it make sense for every network to maintain its IPv4 baggage, just so that email won't be blocked?   At the very least we need input from network operators.)
> 
My experience is that folks running MTAs on IPv6 actually enact stricter technical requirements on those systems. For instance, many IPv4 servers will accept mail without valid rDNS on the sending IP or will accept mail without SPF records, while the IPv6 servers run by the same entities require those things directly. 
> I'm not sure what I've left out.
This makes things clearer. 

laura

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741

---

From: Keith Moore <[email-masked]>
Date: Mon, 28 Sep 2020 09:26:40 -0400

On 9/28/20 9:10 AM, Laura Atkins wrote:

>> I've made those arguments multiple times already.  "evidence" seems 
>> like the wrong thing to ask for because this is really a question of 
>> /design/ - what choices should be made to allow the email network to 
>> continue operating seamlessly and efficiently in the event of 
>> widespread use of NAT within the network (either to gateway between 
>> IPv4 and IPv6 or to economize use of IPv4 space)?
>>
> I’ve seen lots of arguments, yes, but I’ve not seen any real evidence 
> backing up your assertions.

Most of this is what I've picked up reading IETF lists and trade 
publications for years.   I guess I thought it was common knowledge 
within IETF that NATs were increasingly being used in these ways - 
certainly there were many discussions about it in IETF several years ago.

> I’m trying to better understand your point of view and understand why 
> this is so important. But it’s been hard to find that in the sniping.
>

Arguably the discussion should be taking place on the emailcore WG 
mailing list rather than here.   But we started the discussion here.

> Or we could write the BIS to recommend anyone running v4 services also 
> provide v6 services, couldn’t we? Take the burden off the v6 only 
> systems which are likely newer entrants and put it on the ‘old timers’ 
> who’ve been around for decades.

We could make such a recommendation.   Though I expect, that like spam 
filterers, network operators will do what they want, and consider 
themselves justified in doing so, regardless of what we recommend.

I suspect that the task before us is to make recommendations that both 
spam filterers and network operators will find palatable.

> My experience is that folks running MTAs on IPv6 actually enact 
> stricter technical requirements on those systems. For instance, many 
> IPv4 servers will accept mail without valid rDNS on the sending IP or 
> will accept mail without SPF records, while the IPv6 servers run by 
> the same entities require those things directly.

It might even make sense for IPv6 operations to "raise the bar".   For 
example, PTR lookup of IPv6 addresses allows finer-grained delegation 
than PTR lookup of IPv4 addresses.   But regardless of what some 
operators are doing, I think this requires careful analysis to justify 
from a standards perspective.   I suspect there will be IPv4-only 
networks with a legitimate need to originate mail to IPv6-only servers.

Keith

---

From: Laura Atkins <[email-masked]>
Date: Mon, 28 Sep 2020 14:49:27 +0100

> On 28 Sep 2020, at 14:26, Keith Moore <[email-masked]> wrote:
> 
>> I’ve seen lots of arguments, yes, but I’ve not seen any real evidence backing up your assertions.
> Most of this is what I've picked up reading IETF lists and trade publications for years.   I guess I thought it was common knowledge within IETF that NATs were increasingly being used in these ways - certainly there were many discussions about it in IETF several years ago.   
> 
NATs, yes. NATs handling significant amounts of SMTP traffic, I’ve not seen any evidence for.

And if it’s just an issue of NATs, there are other solutions. So the question really becomes: is this an issue affecting large amounts of email? What emails is it affecting? Is it likely to affect email in the future? That’s the kind of evidence I was asking for. Tell me, how much traffic, does this affect now? How much traffic do we expect this to affect moving forward? What tools are we removing from filters if we say they cannot evaulate the hostname? What impact does that have on them? 

The next round of questions will look something like:

Is this a RFC status that MTA operators are simply going to ignore? In the email space we have some very large players who handle billions of emails a day and blatantly violate the RFCs. ’But the RFC says’ is not, in my experience, a persuasive argument for these types. They usually have significant analysis and data that shows that the operational and human problems resulting from their lack of implementation is not enough to force them to follow the RFCs. Simply saying something MUST or MUST NOT be done doesn’t actually result in that happening. 

And then there is the abuse problem. I understand that it’s outside the scope of the rewrite here but it is relevant for adoption. There are absolutely cases where interoperability takes a back seat to protecting the network. 
>> I’m trying to better understand your point of view and understand why this is so important. But it’s been hard to find that in the sniping. 
>> 
> Arguably the discussion should be taking place on the emailcore WG mailing list rather than here.   But we started the discussion here.
> 
> 
> 
> We could make such a recommendation.   Though I expect, that like spam filterers, network operators will do what they want, and consider themselves justified in doing so, regardless of what we recommend.
> 
> I suspect that the task before us is to make recommendations that both spam filterers and network operators will find palatable.
> 
So why are we wasting time on the EHLO evaulation question, if that’s the case. 

> It might even make sense for IPv6 operations to "raise the bar".   For example, PTR lookup of IPv6 addresses allows finer-grained delegation than PTR lookup of IPv4 addresses.   But regardless of what some operators are doing, I think this requires careful analysis to justify from a standards perspective.   I suspect there will be IPv4-only networks with a legitimate need to originate mail to IPv6-only servers.
> 
You suspect, but I’m not convinced your suspicions are a reason to upend current practices. 

laura 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741

---

From: "John Levine" <[email-masked]>
Date: 28 Sep 2020 10:27:58 -0400

>NATs, yes. NATs handling significant amounts of SMTP traffic, I’ve not seen any evidence for.

I've seen lots of CGNs handling lots of consumer traffic. Many mobile
networks are IPV6 only, with NAT64 to talk to the IPv4 Internet. I
have seen no servers at all behind NATs and I don't ever exoect to see
any. Servers need static addresses so clients can find them, so if
they're visible on IPv4 at all, they have native IPv4 addresses. Every
outbound mail server is associated with an inbound mail server, so if
they can find IPv4 addresses for the inbound server, they can also
find some for the outbound server.

Keith is asking us to expect that mail clients will move behind NAT64
even while their associated servers do not, and that will happen
enough that it will change a strong spam filtering signal. Doesn't
seem likely to me.

R's,
John

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 28 Sep 2020 17:26:03 +0200

> enough that it will change a strong spam filtering signal. Doesn't

For that to happen, someone has to say "well, I think that I'll change my 
mail server configuration to be more like a spammer" and then a million 
more people have to do the same, eventually weakening the spam signal. I 
fail to see why the first few thousand people would do any such thing.

It's a case where we can't get there from here, so debating whether "there" 
is a good place or not has no connection to reality. Please let's stop this 
now.

Arnt

---

From: Keith Moore <[email-masked]>
Date: Mon, 28 Sep 2020 17:39:22 -0400

> NATs, yes. NATs handling significant amounts of SMTP traffic, I’ve not 
It's fairly clear that NAT44s aren't just used in consumer routers any 
more.     What I don't know is, are the ISPs that are imposing NATs only 
doing so on consumer traffic for now (and thus still likely to be 
spam/malware)?,   Or does/will this affect enterprise traffic also?

It's also fairly clear to me that we (IETF) don't want to impose 
unnecessary requirements to support IPv4.

We should also take care that we don't impose US or first-world 
assumptions on global email operations, because people in areas with 
less IPv4 address space need to cost-effectively send email too.

>
> And if it’s just an issue of NATs, there are other solutions. So the 
> question really becomes: is this an issue affecting large amounts of 
> email? What emails is it affecting? Is it likely to affect email in 
> the future? That’s the kind of evidence I was asking for. Tell me, how 
> much traffic, does this affect now? How much traffic do we expect this 
> to affect moving forward? What tools are we removing from filters if 
> we say they cannot evaulate the hostname? What impact does that have 
> on them?

I would say that the questions are more like: is this issue imposing a 
burden on MSPs or enterprises trying to send email? Are those 
organizations having to jump through hoops to send email that they 
shouldn't have to jump through?   Is this marginalizing small 
organizations or unnecessarily forcing them to use external MSPs when 
they shouldn't need to?   How much worse will this problem become in the 
future if not addressed?

> Is this a RFC status that MTA operators are simply going to ignore? In 
> the email space we have some very large players who handle billions of 
> emails a day and blatantly violate the RFCs. ’But the RFC says’ is 
> not, in my experience, a persuasive argument for these types. They 
> usually have significant analysis and data that shows that the 
> operational and human problems resulting from their lack of 
> implementation is not enough to force them to follow the RFCs. Simply 
> saying something MUST or MUST NOT be done doesn’t actually result in 
> that happening.

I think that's completely the wrong question.   Our job is to figure out 
what it takes to make email work well, not to cater to large players.    
Sure they might ignore the advice, but it's not IETF's job to legitimize 
harmful behavior.

> And then there is the abuse problem. I understand that it’s outside 
> the scope of the rewrite here but it is relevant for adoption. There 
> are absolutely cases where interoperability takes a back seat to 
> protecting the network.

I have no problem with filtering malware as long as there's a reliable 
indication that it's malware.   I have a lot of problem with IETF 
endorsing a practice of MSPs imposing shortsighted and meaningless 
restrictions.

>>>> providers using NAT to move packets between IPv4 and IPv6 
>>>> addressing domains.  I'm also anticipating the need to eventually 
>>>> phase out the public IPv4 Internet altogether.
>>>>
>>> Or we could write the BIS to recommend anyone running v4 services 
>>> also provide v6 services, couldn’t we? Take the burden off the v6 
>>> only systems which are likely newer entrants and put it on the ‘old 
>>> timers’ who’ve been around for decades.
>>
>> We could make such a recommendation.   Though I expect, that like 
>> spam filterers, network operators will do what they want, and 
>> consider themselves justified in doing so, regardless of what we 
>> recommend.
>>
>> I suspect that the task before us is to make recommendations that 
>> both spam filterers and network operators will find palatable.
>>

It's a question that needs to be resolved before we can consider 5321 
ready for publication.

>>> IPv4 servers will accept mail without valid rDNS on the sending IP 
>>> or will accept mail without SPF records, while the IPv6 servers run 
>>> by the same entities require those things directly.
>>
>> It might even make sense for IPv6 operations to "raise the bar".   
>> For example, PTR lookup of IPv6 addresses allows finer-grained 
>> delegation than PTR lookup of IPv4 addresses.   But regardless of 
>> what some operators are doing, I think this requires careful analysis 
>> to justify from a standards perspective.   I suspect there will be 
>> IPv4-only networks with a legitimate need to originate mail to 
>> IPv6-only servers.
>>

I'm not convinced that such practices are a reason to delay transition 
to IPv6.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 28 Sep 2020 17:41:34 -0400

On 9/28/20 10:27 AM, John Levine wrote:

> even while their associated servers do not,

No, I expect IPv4 to go away.   Gradually at first, and then much more 
quickly.    Are people here really going to insist that operators have 
to maintain IPv4 servers (or ALGs or whatever they need to maintain the 
illusion that the client and server see the same source IP address?).   
Architecturally it seems like an extremely shortsighted viewpoint.

---

From: "John Levine" <[email-masked]>
Date: 28 Sep 2020 18:16:01 -0400

>illusion that the client and server see the same source IP address?).   

I'm sorry but this is making less and less sense.

You appear to be saying there will be mail systems that need to send
mail to IPv4 systems, but will not have an IPv4 mail server so the
recipients can't reply to them.  Really?

If you do expect the recipients to be able to reply, why wouldn't the
inbound IPv4 mail server's address be the one it uses to send mail,
like it has for the past 40 years?

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Mon, 28 Sep 2020 18:26:57 -0400

> recipients can't reply to them.  Really?

No, I'm saying that when IPv4 starts going away, there will be more and 
more systems needing to send mail via NAT to such that client and server 
ends of the connection have different address types.

(There are already some IPv6 only ISPs and I expect this will become 
more viable over time.   Should they have to set up IPv4 tunnels or ALGs 
for their "legitimate" customers so those customers can still send email 
to IPv4 servers?)

Keith

---

From: "John R Levine" <[email-masked]>
Date: 28 Sep 2020 18:41:14 -0400

> No, I'm saying that when IPv4 starts going away, there will be more and more 
> systems needing to send mail via NAT to such that client and server ends of 
> the connection have different address types.

Um, not to belabor the obvious, but I presume you know that to send 
someone mail, their domain needs to publish an MX record that points to a 
host with an A or AAAA record.

Could you explain in detail how I am supposed to send mail to people whose 
mail servers are stuck behind a NAT64 without a fixed public address?

Alternatively, it sounds like you're confusing submission and SMTP relay 
again.  We all agree that you don't need to verify IPs or anything like 
that for submission since submit clients identify themselves with AUTH.

Regards,

---

From: "John R Levine" <[email-masked]>
Date: 28 Sep 2020 18:44:31 -0400

> (There are already some IPv6 only ISPs and I expect this will become more 
> viable over time.   Should they have to set up IPv4 tunnels or ALGs for their 
> "legitimate" customers so those customers can still send email to IPv4 
> servers?)

No, they need a fixed IPv4 address with an MX so people on IPv4 servers 
can send mail *to* them.  As we've said a few dozen times already, one 
mail server on one IPv4 address can handle a whole lot of mail for a whole 
lot of people, both inbound and outbound.

The usual word for one-way mail to which one cannot reply is "spam".

Regards,

---

From: Mark Andrews <[email-masked]>
Date: Tue, 29 Sep 2020 08:59:34 +1000

> On 29 Sep 2020, at 08:16, John Levine <[email-masked]> wrote:
> 

Actually I expect there will be systems where just 25/<ipv4-address> is
statically NAT46’d to a 25/<IPv6-address> and all the outbound traffic goes
back through the NAT64 with no linkage to the IPv4 address except for those
established by the inbound connections.

I expect that setups like this will happen dynamically in the future and the
A records will be dynamically updated to reflect whatever IPv4 address the
server happened to negotiate out of the NAT64.  The protocols to do this
have existed for years now.  They just haven’t been initiated from SMTP
servers yet.

The same thing will happen for other services like HTTP{S} that needs to
supported in house.

> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 29 Sep 2020 09:11:20 +1000

> On 29 Sep 2020, at 08:44, John R Levine <[email-masked]> wrote:
> 
>> (There are already some IPv6 only ISPs and I expect this will become more viable over time.   Should they have to set up IPv4 tunnels or ALGs for their "legitimate" customers so those customers can still send email to IPv4 servers?)
> 
> No, they need a fixed IPv4 address with an MX so people on IPv4 servers can send mail *to* them.  As we've said a few dozen times already, one mail server on one IPv4 address can handle a whole lot of mail for a whole lot of people, both inbound and outbound.
> 
> The usual word for one-way mail to which one cannot reply is "spam”.

And if you have a IPv6 address that is reachable it is not “spam”.  Out bound address do not have to
match in bound addresses.  Remember this is delivering email to legacy addresses who may well end up
having a smart dual-stacked host for outbound traffic to workaround not having IPv6.

> Please consider the environment before reading this e-mail. https://jl.ly_______________________________________________
> ietf-smtp mailing list
> [email-masked]

---

From: "John R Levine" <[email-masked]>
Date: 28 Sep 2020 19:35:42 -0400

> established by the inbound connections.

Hmmn.  I suppose that if I wanted to set up a mail system to maximize the 
chance that my mail would fall afoul of well established anti-abuse 
metrics and get thrown on the floor, that'd be a good plan.

On the other hand, if I were running a mostly v6 network and wanted a mail 
path for a few legacy v4 users, I would set up a gateway on a dual stacked 
host with static IPv4 and IPv6 addresses, publish its v4 address as a 
secondary MX for my v6-only mail systems, and use it to pass mail both 
ways.

Regards,