Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321
2020-09-28 16:39:38
On 9/28/20 9:49 AM, Laura Atkins wrote:
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.
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?
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.
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.
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.
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's a question that needs to be resolved before we can consider 5321
ready for publication.
(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.
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.
I'm not convinced that such practices are a reason to delay transition
to IPv6.
Keith
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321, (continued)
- Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321, Mark Andrews
- Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321, John R Levine
- Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321,
Keith Moore <=
- Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321, Dave Crocker
- Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321, John Levine
- Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321, Keith Moore
- Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321, Dave Crocker
- Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321, Keith Moore
- Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321, Dave Crocker
- Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321, Dave Crocker
- Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321, Keith Moore
- Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321, Dave Crocker
- Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321, Keith Moore
|
|
|