Responding to multiple, relatively small, issues...
--On Monday, December 23, 2019 23:37 -0500 Keith Moore
<moore(_at_)network-heretics(_dot_)com> wrote:
...
But perhaps the fundamental problem is that too many people
actually don't consider reliable email delivery as an
essential service, and that's why they justify throwing away
messages for dubious reasons.
Or they see it as a "what you get is what you get" service,
which is not quite the same as not considering reliable email
delivery as essential, but close.
--On Wednesday, December 25, 2019 10:44 -0500 Sam Varshavchik
<mrsam(_at_)courier-mta(_dot_)com> wrote:
And, in situations where it counts, the task of a mail
administrator who has to explain to her boss's boss why a
message from an important customer was rejected and didn't get
through is, well, not enviable.
That depends on what happened in the first place – whether
the mail administrator did that on their own volition, or
because the same boss complained "I'm getting too much spam,
can you do anything about it", the mail administrator
explained the options, but the boss's eyes started glazing
over hearing all the technical mumbo-jumbo, and the boss just
waved their hand "just do it". So now the mail administrator
explained that the mail was rejected because the boss approved
the change, and the boss will simply tell the mail
administrator to undo it, then, and everyone lives happily
ever after.
You have clearly been hanging around with a better class of boss
than some of the ones I had in mind. For the latter, if a
problem occurs, even if was clearly their own fault, the normal
response would be to find someone to blame and throw under a
passing bus. I certainly prefer your more positive view of the
world, bosses, and likely outcomes, but...
--On Sunday, December 22, 2019 14:59 -0500 Viktor Dukhovni
<ietf-dane(_at_)dukhovni(_dot_)org> wrote:
Of course if one wants to send mail to "luser@[192.0.2.1]"
that'll work too (but that address form isn't by default
accepted via SMTP from clients that are neither on a local
network nor by some means authenticated, an open-relay
configuration als possible, though it is not likely to be
enabled just by accident.
It also prevents any sort of MX resolution, so whatever is at
192.0.2.1 had better be (at least as far as SMTP is concerned)
the final delivery host (and, for that particular address, very
local). Of course, in some situations, that might be considered
an advantage.
--On Saturday, December 21, 2019 17:50 -0500 Keith Moore
<moore(_at_)network-heretics(_dot_)com> wrote:
So, if it's a host name, it has to resolve. So,
'shortname.localdomain' wouldn't be valid.
The interesting thing to me is that if you don't have a valid
DNS name, an IP address literal seems like the right thing to
use. Even if behind a NAT at least it's some identifier that
is associated with the sending host that can go in a Received
header, still potentially useful for tracing if the server has
logs showing the source IP address. An EHLO tag based on a
boilerplate hostname and boilerplate suffix is essentially
useless for that purpose.
And, while the wording is different, that is essentially what
5321 (and 2821 before it) say. So I think you are suggesting
that the core requirement is fine and that, if anything is
needed, it is better language about when it may, or may not, be
a good practice.
--On Saturday, December 21, 2019 22:28 +0000 Paul Smith
<paul(_at_)pscs(_dot_)co(_dot_)uk> wrote:
So, if it's a host name, it has to resolve. So,
'shortname.localdomain' wouldn't be valid.
With several qualifications, yes. The first is that 5321 (IMO,
intentionally) does make careful distinctions between the public
DNS and various more local arrangements. Section 2.3.5
requires FQDNs, but "shortname.localdomain" is, at least by the
rules described in that section, an FQDN. The second
qualification is that Section 4.1.4 prohibits rejecting an EHLO
command based on the domain name not resolving to the same
address that originated the connection, so it is not clear what
the implications of "not valid" are in terms of what a
conforming SMTP server should or should not do.
--On Saturday, December 21, 2019 17:20 -0500 Viktor Dukhovni
<ietf-dane(_at_)dukhovni(_dot_)org> wrote:
So if you don't have an explicitly configured hostname, do
you simply refuse to send messages? Or send EHLO
example.com? or what?
There's always a hostname. It defaults to the return value of
gethostname(). And if that contains no dots, and "mydomain" is
not set, then the domain defaults to "localdomain". So worst
case you get "shortname.localdomain".
Victor, while what you are describing would be a perfectly
reasonable implementation, 5321 doesn't know a thing about
gethostname() (and, given issues with stable references and
independence of particular programming languages and operating
systems, probably shouldn't). Whether we now think 5321 is
correct or not going forward, it is very specific about what
happens if the sending host decides, for whatever reason, that
it has no appropriate FQDN to use and that it is to use the IP
address literal.
Carrying Keith's analysis a bit further, if your systems want to
reject EHLO commands with IP address literals on the grounds
that you assume whomever controls the connection-originating
host is a spammer, and idiot, or both and you don't want mail
from anyone sending from a host run by such people, no one is
going to say you can't do that and, if they did, you would
presumable ignore them. But changing SMTP to prohibit such
literals would essentially ban any host without an FQDN, maybe
even an FQDN on the public Internet, from participating in the
mail system (except, maybe, via a Submission Server that would
sort things out) would be a rather big step. The same comment,
btw and incorporating another thread by reference, applies to
any system or host that, for whatever reasons, can't acquire a
valid and usable reverse-mapping record, especially one that
will return the same FQDN as the one it intends to use in EHLO.
And I still think that special considerations apply to SMTP
servers that appear to represent the IETF and its practices.
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp