Subject: [ietf-smtp] G.7.3 --- resolvable FQDNs

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Aug 2020 20:44:25 -0400

I am watching the video, and slide 17: G.7.3 resolveable domain names.

I want to suggest that the *protocol* should describe:
  1) what does it mean to resolve a domain name.
  2) which fields, SMTPs commands, etc. have things that might to resolve.

I think that then the Internet applicability should say whether or not this
should be on.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Dave Crocker <[email-masked]>
Date: Wed, 5 Aug 2020 18:23:43 -0700

>    1) what does it mean to resolve a domain name.

So you are suggesting that the smtp protocol specification should 
contain text that is redundant with the DNS specification, rather than 
merely cite it?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Aug 2020 19:44:32 -0400

> So you are suggesting that the smtp protocol specification should contain
    > text that is redundant with the DNS specification, rather than merely cite
    > it?

The explicit discussion was that in some non-Internet contexts, the domain
name is not from the DNS.  The discussion was that this (the citing of the
DNS specification, if you like, but actually there is more to it than that),
should go into an applicability statement.

I disagree: it should go into the base specification as a thing that software
should support.  The applicability statement should say "turn it on" when on
the Internet.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 7 Aug 2020 16:58:04 -0700

> should support.  The applicability statement should say "turn it on" when on

It's not clear to me what the 'turn it on' refers to.

It's also not clear why a localized operational choice that deviates 
from established Internet practice should be baked into the core 
specification.

d/

---

From: "John Levine" <[email-masked]>
Date: 7 Aug 2020 22:08:43 -0400

In article <22051.1596843872@localhost> you write:
>name is not from the DNS.

I don't understand what that has to do with writing specs that
interoperate on the Internet. If a host is sending mail on the
Internet, it looks names up in the DNS.

Most mail servers have a hack that lets you put in routes manually to
locally override the DNS results, but I've never heard anyone say the
details of that should be standardized. Certainly in the MTAs I've
used, the way you do so has varied all over the place.

R's,
John

---

From: Michael Peddemors <[email-masked]>
Date: Mon, 10 Aug 2020 09:43:51 -0700

> used, the way you do so has varied all over the place.

Just a thought, is this maybe time to enshrine some of the MAAWG 
recommendations surrounding this?

If your email server egress IP has a PTR of:

mail.example.com

There SHOULD be a URL that responds to http://example.com, where 
information and contact information about the operator can be found..

Also, some operators still find a need for multiple PTR's for an IP, and 
some language around avoiding too many PTR records for the same IP, and 
that EACH PTR should have an associated A record and functioning URL.

-- 
"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: Claus Assmann <[email-masked]>
Date: Mon, 10 Aug 2020 21:23:24 +0200

On Mon, Aug 10, 2020, Michael Peddemors wrote:

> There SHOULD be a URL that responds to http://example.com, where information

This is e-mail, not some web stuff.
The contact information for various purposes are defined in the
RFCs (e.g., postmaster for e-mail).

---

From: Michael Peddemors <[email-masked]>
Date: Mon, 10 Aug 2020 13:15:56 -0700

> RFCs (e.g., postmaster for e-mail).

The reason is for all the people who are NOT engineers, have an easy way 
to contact someone for ANY issues related to that domain.

As well, with everyone hiding 'whois', and so many companies that don't 
have a proper postmaster, or even check the postmaster mailbox, it does 
make sense, which is why it was recommended as a best practice.

There are more than just engineers out there that want to find out who 
is behind the 'mask'..

But yes, maybe it doesn't strictly belong in SMTP language, but a 
'suggestion' might be in order..

---

From: John C Klensin <[email-masked]>
Date: Mon, 10 Aug 2020 17:15:43 -0400

--On Monday, 10 August, 2020 13:15 -0700 Michael Peddemors
<[email-masked]> wrote:

>> The contact information for various purposes are defined in
>> the RFCs (e.g., postmaster for e-mail).
> 
> The reason is for all the people who are NOT engineers, have
> an easy way to contact someone for ANY issues related to that
> domain.

That is the first difficulty.  It is not unusual, probably even
common these days, for the person or group managing the domain
to be different from the person or group managing the email
systems for that domain.  For the domain management, you've got
too hooks-- whois (or the registry database du jour) and the
email address in the SOA record.  If one is useless and the
other is even less maintained than Postmaster, tell it to ICANN:
Allowing domains without available "help" or other contact
information is a policy decision, not a technical one that is
going to be solved by new or different mechanisms.  For the
email side, what causes you to believe that an email system
operator who does not listen to Postmaster will listen or
respond to a special URL?

> As well, with everyone hiding 'whois', and so many companies
> that don't have a proper postmaster, or even check the
> postmaster mailbox, it does make sense, which is why it was
> recommended as a best practice.

At least IMO, it doesn't make sense unless and until there is
evidence that the operators or policy makers who cannot or will
not make information available or respond to queries via
established protocols will decided to make it available given a
new mechanism.

> There are more than just engineers out there that want to find
> out who is behind the 'mask'..

Sure.  But the direction of things favors "right to be masked"
rather than "right to find out who or what is causing a problem
and get it fixed".

And do note that mailto:[email-masked] is a URL.

> But yes, maybe it doesn't strictly belong in SMTP language,
> but a 'suggestion' might be in order..

You could try writing an Internet-Draft pointing out that it is
really, really, important to have that information available.
But, given the conflict between that goal and privacy, I
wouldn't be optimistic about its getting traction.

   john

---

From: Sam Varshavchik <[email-masked]>
Date: Mon, 10 Aug 2020 19:28:15 -0400

Michael Peddemors writes:

> The reason is for all the people who are NOT engineers, have an easy way to  
> contact someone for ANY issues related to that domain.
>
> As well, with everyone hiding 'whois', and so many companies that don't have  
> a proper postmaster, or even check the postmaster mailbox, it does make  
> sense, which is why it was recommended as a best practice.

So, an anonymously whois-registered domains will be happy to put up a web  
site, at a well-known address, full of harvestable E-mail addresses, just  
waiting to be snarfed by spambots?

---

From: "John Levine" <[email-masked]>
Date: 10 Aug 2020 22:49:15 -0400

>information and contact information about the operator can be found..

Can you give us a pointer to the document that says that?  I've read a
lot of M3 documents and don't recall seeing it.

>that EACH PTR should have an associated A record and functioning URL.

I don't see the point here. Unless you're doing MTA-STS, which is a
separate spec, an MTA doesn't know what name a client thinks it has.

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly