Subject: Re: [Emailcore] Ticket #19: G.7.6. Requirements for domain name and/or IP address in EHLO

From: Dave Crocker <[email-masked]>
Date: Wed, 15 Dec 2021 09:25:36 -0800

A domain name that is registered through the ICANN hierarchy of 
registries is 'valid'.

What your effort, here, does is to bring back 'resolvability', which I 
assume is what you really mean by 'validity'.

d/

On 7/13/2021 4:27 AM, Alessandro Vesely wrote:
> On Fri 09/Jul/2021 21:24:47 +0200 Todd Herr wrote:
>>
>> I propose the following as a strawman...
>>
>> Change the above paragraph to read as follows:
>>
>>     An SMTP server MAY verify that the domain name argument in the EHLO
>>     command has an address record matching the IP address of the client.
> 
> 
> I'd make that even more abstract, for example:
> 
>      An SMTP server MAY verify the validity of the domain name argument in
>      the EHLO command.
> 
> Domain name to IP, IP to PTR name, SPF, and more are different 
> verification criteria, sometimes overlapping and sometimes not.
> 
> 
>> And include the following text in the Applicability Statement:
>>
>>   [snip text to be discussed at A/S time]
> 
> 
> Best
> Ale

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Michael Peddemors <[email-masked]>
Date: Wed, 15 Dec 2021 10:40:55 -0800

An industry standard, and MAAWG recommendation, the domain portion in 
the PTR and in the email MAIL FROM should not only be resolvable, but 
should have an accompanying URL publicly accessible, so inquiries 
related to those domains can find a contact for the operators.

As far as EHLO is concerned, there are STILL cases where the domain in 
the EHLO is an internal domain, representing the name of the server, 
according to internal requirements.

EG, there should not yet be a constraint that would prevent the use of 
'mail-unit-3.seattledatacenter.ibm' if all servers at IBM used an 
internal TLD of .ibm.

The PTR is there to check validity of the exit node.  EHLO is meant for 
a different historical purpose IMHO.  I don't think IETF should by 
policy require broad sweeping industry changes in practice.

IMHO..

The EHLO value is valuable, no matter how a company names it's internal 
servers.. EHLO/HELO means .. 'Hi, I am named this' effectively.

IP should of course NOT be used, as that is the lack of an identifying 
name for the server initiating the connection.

-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

---

From: "John Levine" <[email-masked]>
Date: 15 Dec 2021 14:05:23 -0500

It appears that Michael Peddemors  <[email-masked]> said:
>the PTR and in the email MAIL FROM should not only be resolvable, 

So far so good.

>but should have an accompanying URL publicly accessible, so inquiries 

Nope.

R's,
John, [email-masked] (try it)

---

From: "John Levine" <[email-masked]>
Date: 15 Dec 2021 14:07:27 -0500

>assume is what you really mean by 'validity'.

I have no idea what he means.  If the domain publishes an SPF -all record,
is that domain valid?

The check for A/AAAA/MX is pretty common so if that's the intent, say so.

R's,
John

PS: I think most ccTLDs would say IANA hierarchy, not ICANN.

---

From: Michael Peddemors <[email-masked]>
Date: Wed, 15 Dec 2021 11:16:53 -0800

> John, [email-masked] (try it)

Hey, you can do anything you want, but be aware that reputation 
companies will treat it with much more suspicion if..

http://sp.am/

.. doesn't exist,  but at least you have a clear 'whois' record.

Problem is the general public doesn't read or know anything about 
'whois', so who do they contact?

---

From: Dave Crocker <[email-masked]>
Date: Wed, 15 Dec 2021 12:07:43 -0800

On 12/15/2021 11:07 AM, John Levine wrote:
> It appears that Dave Crocker<[email-masked]>  said:

And yet, your next sentence demonstrates that you did.

> The check for A/AAAA/MX is pretty common so if that's the intent, say so.

To the extent there is a desire to have text here make reference to all 
of the possible mechanics for demonstrating 'validity', perhaps.  It 
might be safer, for the long term, to use text that describes the 
semantics of validity, rather than the mechanics.

d/

---

From: Claus Assmann <[email-masked]>
Date: Wed, 15 Dec 2021 20:29:27 +0000

On Wed, Dec 15, 2021, Michael Peddemors wrote:
> An industry standard, and MAAWG recommendation, the domain portion in the PTR
> and in the email MAIL FROM should not only be resolvable, but should have an
> accompanying URL publicly accessible, so inquiries related to those domains

"industry standard"?  Those are the companies who don't care about
RFCs and make up there own rules?

Please let's follow the rules for RFCs -- which define the e-mail
addresses for contacts -- without requiring some web stuff.

-- 
Address is valid for this mailing list only, please do not reply
to it directly, but to the list.

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 15 Dec 2021 21:12:37 +0000

>> related to those domains can find a contact for the operators.

Agreed.  SMTP should not depend on HTTP nor any of the lines
of development starting there, including URLs.
-- 
Cheers,
   Jeremy

---

From: "John Levine" <[email-masked]>
Date: 15 Dec 2021 17:45:27 -0500

>> The check for A/AAAA/MX is pretty common so if that's the intent, say so.

Uh, no, that sentence means what it says. 

>semantics of validity, rather than the mechanics.

Well, OK.  Send text, keeping in mind that a fair amount of SMTP happens
behind firewalls, split horizon DNS, and all of the other duct tape that
glues parts of the Internet together.

R's,
John

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 15 Dec 2021 17:56:36 -0500

> glues parts of the Internet together.
So this helps me, John.  I see a lot of things during my day jobs, and
receive
a lot of email from broken servers with invalid names on some internal
network that
nobody should be forced to see.  It's email that should never escape into
the Internet,
but there is an expectation of internal delivery.

I'm not advocating a position, only thinking the requirement should be more
semantic.

tim

---

From: Steffen Nurpmeso <[email-masked]>
Date: Thu, 16 Dec 2021 00:38:01 +0100

Jeremy Harris wrote in
 <[email-masked]>:
 |On 15/12/2021 19:05, John Levine wrote:
 |> It appears that Michael Peddemors  <[email-masked]> said:
 |>> An industry standard, and MAAWG recommendation, the domain portion in
 |>> the PTR and in the email MAIL FROM should not only be resolvable,
 |> 
 |> So far so good.
 |> 
 |>> but should have an accompanying URL publicly accessible, so inquiries
 |>> related to those domains can find a contact for the operators.
 |> 
 |> Nope.
 |
 |Agreed.  SMTP should not depend on HTTP nor any of the lines
 |of development starting there, including URLs.

You know i struggle with OAuth authentification that not only uses
JSON for key/value pairs etc., but may also upgrade to HTTP/2 or
even QUIC, and not even the cURL library (just let me say: !,
please) implements these themselve but uses external libraries
which themselve (!) use external libraries for the QUIC case.
All that nothing but a pity.
That is to say, how adorable this protocol was designed to still
scale after decades, the ugliness produced by other participants
of IETF soils it whatever you do.  (I have my spoiler week.)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

---

From: Dave Crocker <[email-masked]>
Date: Wed, 15 Dec 2021 22:57:34 -0800

> glues parts of the Internet together.

Thanks for the work assignment, but there are least 3 problems with it:

1. I really don't know what semantics you guys think is appropriate.  So 
the task is on you guys.

2. I thought the agreement during the Interim was to dump validity (or 
whatever it should be called) testing, and while it's fine for the 
mailing list discussion to reverse meeting 'decisions', I have missed 
the list discussion that makes the compelling case for the test, in the 
protocol specification.

3. I've grown increasingly clear that there is a difference between a 
protocol specification and a service, or operations, specification, and 
that it is important for documents to be careful about making this 
distinction.(*)  Also a validity/whatever test is not needed for basic 
email transfer functionality; so it's an service/operations requirement 
not a protocol requirement.  It makes pretty obvious sense to have some 
sort of testing across the open Internet, as part of the public email 
service.  It is less clear that it is needed in other operational 
environments.

d/

(*) DANE did quite a good demonstration of this, by requiring use of 
DNSSec.  It is an operational requirement, rather than a protocol 
requirement, and the one sentence in the DANE spec that requires it 
imposed a massive barrier to adoption of DANE.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 16 Dec 2021 13:11:06 +0100

On Wed 15/Dec/2021 18:25:36 +0100 Dave Crocker wrote: (reordered for readability)
>> Domain name to IP, IP to PTR name, SPF, and more are different verification 
>> criteria, sometimes overlapping and sometimes not.
>
> A domain name that is registered through the ICANN hierarchy of registries is 
> 'valid'.

Isn't that overly restrictive?

> What your effort, here, does is to bring back 'resolvability', which I assume 
> is what you really mean by 'validity'.

My intention was the opposite.  By replacing 'resolvability' (and matching IP) with an abstract 'validity' the semantic remains open.  Which validity criteria to use is entirely in the ambit of the receiving SMTP server.  The point is that such validity judgment can be made using the given domain name argument.  The A/S can give multiple examples of validations in the public Internet.

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Thu, 16 Dec 2021 07:20:52 -0800

> Isn't that overly restrictive?

To answer that requires first seeing what alternative you have in mind.

> My intention was the opposite.  By replacing 'resolvability' (and 
> matching IP) with an abstract 'validity' the semantic remains open.  

A specification that has an 'open' semantic is not specifying anything a 
normative protocol detail that is meaningful.  (literally)

d/

---

From: "John Levine" <[email-masked]>
Date: 16 Dec 2021 11:55:32 -0500

>the list discussion that makes the compelling case for the test, in the 

We seem to have been talking past each other.  I'm with you, validity
testing of the EHLO doesn't work well enough to standardize.

I'd go as far as saying that the EHLO argument SHOULD be a domain name
that has an A or AAAA that points to the host issuing the command if
such a domain name exists, but specifically not say to do if it's not.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 16 Dec 2021 18:40:05 +0100

On Thu 16/Dec/2021 16:20:52 +0100 Dave Crocker wrote:
>> On Wed 15/Dec/2021 18:25:36 +0100 Dave Crocker wrote:
>>>
>>> A domain name that is registered through the ICANN hierarchy of registries 
>>> is 'valid'.
>>

SMTP, as a protocol, can be used between internal hosts; where "internal" 
stands for non-registered and/or not publicly accessible.  They must still be 
considered valid by the server they connect to.

>> My intention was the opposite.  By replacing 'resolvability' (and matching 
>> IP) with an abstract 'validity' the semantic remains open. 
> 

Uh... I beg your pardon, perhaps I should have said an open mechanism.  The 
semantic meaning is that the EHLO argument had better be good because the 
server will check it.  Missing details can be specified afterwards, without 
modifying the core protocol.  These are mechanisms, such as like looking up PTR 
or TXT records, each of which, in turn, has its own semantic.  Hence the confusion.

An immediate consequence of such specification, whether open or limited to the 
correspondence with the IP address of the client, is to say what action should 
a server take if the argument is invalid.

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Thu, 16 Dec 2021 11:20:03 -0800

On 12/16/2021 8:55 AM, John Levine wrote:
>   I'm with you, validity

I'm pretty sure I said nothing at all like that.

I don't even have a guess how one could develop that interpretation of 
what I posted.

d/

---

From: Dave Crocker <[email-masked]>
Date: Sat, 18 Dec 2021 08:19:50 -0800

On 12/16/2021 9:40 AM, Alessandro Vesely wrote:
> SMTP, as a protocol, can be used between internal hosts; where 
> "internal" stands for non-registered and/or not publicly accessible.  
> They must still be considered valid by the server they connect to.

Given split DNS, and even host.txt, operation within an enterprise does 
not require use of non-registered names.  (Just to be clear, putting a 
name in host.txt is a kind of registration.)

So while it is possible to allow for 'internal' operation that does not 
require names to be registered, it isn't required.  It's a specification 
choice.

In any event, my intent has been to press for clarity and precision in 
the specification.  The details of what all that clarity and precision 
says is a matter for working group agreement.

My own inclination, at this point, is to move details about domain name 
testing to an applicability statement, or the like, and to keep it out 
of the protocol specification.  This allows a clean protocol doc to be 
applied to different environments that have different operational 
requirements and constraints.

>>>> What your effort, here, does is to bring back 'resolvability', which 
>>>> I assume is what you really mean by 'validity'.
>>>
>>>
>> A specification that has an 'open' semantic is not specifying anything 
>> a normative protocol detail that is meaningful.  (literally)
> 
> 
> Uh... I beg your pardon, perhaps I should have said an open mechanism.  
> The semantic meaning is that the EHLO argument had better be good 
> because the server will check it. 

And my point is that the semantic for 'good' needs to be precisely 
statement and operationally meaningful.

d/

---

From: John C Klensin <[email-masked]>
Date: Sat, 18 Dec 2021 13:02:14 -0500

--On Saturday, December 18, 2021 08:19 -0800 Dave Crocker
<[email-masked]> wrote:

>...
> In any event, my intent has been to press for clarity and
> precision in the specification.  The details of what all that
> clarity and precision says is a matter for working group
> agreement.
> 
> My own inclination, at this point, is to move details about
> domain name testing to an applicability statement, or the
> like, and to keep it out of the protocol specification.  This
> allows a clean protocol doc to be applied to different
> environments that have different operational requirements and
> constraints.
>...

For information and commenting on the above only, I should
probably state my personal preference/rule as editor.   It is,
of course, subject to interpretations and decisions by the WG
Chairs.   It also reflects my personal view of the types of
changes it is appropriate to make when going to Internet
Standard -- a view on which I will defer to any WG consensus as
long as that consensus does not conflict with clear statements
in the relevant BCPs.

RFC 5321 was an IETF consensus document that came out of a WG
with a much higher level of activity and much broader
participation than this one has exhibited (at least so far).  It
built on a long operational and consensus history, including
that developed in other high-participation WGs, not only about
the narrowly interpreted protocol specification but of what was
appropriately covered and included (or not).  That suggests to
me that there should be fairly clear agreement about any changes
in definitions or scope and that, if there is significant
controversy about some potential change, we should just leave
things alone.  Doing things that way not only preserves the
earlier consensus, but adheres to a principle that drove 5321
and 2821 (fwiw, several times over my objections) to avoid
making changes that might inadvertently introduce errors or new
sources of confusion.   One implication is that, while it makes
me personally uncomfortable because, like Dave in his statement
above, I generally have a strong preference for clarity and
precision, there are places in which 5321 (and its predecessors)
are a bit vague but where we need to examine whether the
vagueness may have served the community well and whether
removing it might either unintentionally create problems for
now-conforming implementations or require considerable
explanation that we might not get quite right.

What we might do in an/the applicability statement to clarify
preferences or offer guidance are separate matters; this note is
addressed to 5321bis and its content only.

In a way, that is a rather verbose way to say "if it isn't
clearly broken, let's err on the side of not trying to fix it".
It is also a way of saying "let's get this done rather than
spending large amounts of time on aesthetic preferences,
including document reorganization". 

Again, those are preferences and editor's guidelines that don't
count if there is consensus, even if rough, announced by the
co-chairs using the usual procedures.  I note that the recent
and pending changes to clean up source routes are examples of
ones that had that level of consensus.

Just my opinion.
    john

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 20 Dec 2021 10:44:53 +0100

On Sat 18/Dec/2021 17:19:50 +0100 Dave Crocker wrote:
> [...]
> My own inclination, at this point, is to move details about domain name testing 
> to an applicability statement, or the like, and to keep it out of the protocol 
> specification.  This allows a clean protocol doc to be applied to different 
> environments that have different operational requirements and constraints.

+1 to move details to the A/S.

>> server will check it. 
> And my point is that the semantic for 'good' needs to be precisely stated 
> and operationally meaningful.

How can we square stating that point precisely and moving details to the A/S?

IMHO, SMTP has to be a completely stated, self standing protocol even without 
the A/S which specifies the details.  OTOH, the very meaning of good can even 
evolve with time.

Best
Ale
--