I wish to commend Yakov on an excellent pass at Andrew's question
about ramifications. In this email, I limit my discussion to HELO
checking; I expect to do another one about additional checking for
RFC2821 MAIL FROM.
Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com> wrote:
We also ask that participants consider and list the following
ramifications regarding deployment issues:
1) Amount of change in software components (MDA, MTA, MUA, DNS servers,
DNS resolvers).
HELO checking would entail changes in receiving and sending MTAs for
using a TLD as a HELO parameter;
I think Yakov meant changing the configuration of sending MTAs to
use the top domain of the domain owner in the HELO.
This brings up the near-impossibility of discussing Andrew's questions
without referring to specific semantics of what will be in DNS records.
One option for HELO checking is obviously to advertise a single DNS
record for the domain, and make sure that that exact string is found
in the HELO/EHLO (leaving open the question of additional information
in the HELO delimited in a well-defined manner).
But that's not the only option, of course. We could instead define
semantics so that a set of domain-name-like strings would be advertised
via DNS at the top domain-name level, and potentially multiple DNS
queries would be made to find that record.
More likely, we might specify that any number of DNS records may be
advertised, and the DNS query will be on the exact string found in the
HELO. Obviously these three choices would present different change
requirements in different areas.
I think that about all that can be said is that _some_ sending MTAs
will have to change the HELO string to match something advertised in
DNS.
and in the receiving MTA for checking that parameter.
This clearly is required for any receiving MTA which wishes to
use our Standard. (Not all will.)
This might be mitigated by already existing procedure to use the
machine's name but this would entail publishing records for the
subdomain if the FQDN is a subdomain.
I'm not aware of any MTA software which insists on using a "machine
name" which cannot be configured to be different from other "machine
name" uses. Does anyone know of any?
If filtering is done past the initial MTA (SpamAssasin for ex.),
then some form of "received" header parsing would be needed to
extract the HELO prompt which would not be foolproof; IF MARID
checking is desired at that layer.
This is a little scary. I would rather specify adding some
well-defined header showing the results of checking the HELO during
the SMTP session than depend on being able to extract the HELO
string from whatever "standard" the MTA may have for recording it
in the Received header it must add. (I would assume this would be
a "The receiving MTA MAY..." sort of thing.)
I will note that if the HELO is the only check we do, this will
probably be needed, as a "SHOULD", not a "MAY", and thus needs to
be listed among changes to MTAs.
The issue of change in DNS software is not necessarily related to the
type of identity, rather it depends on how the data is expressed in DNS.
Therefore, I don't see a difference between different identities in
regards to DNS software.
I don't believe we can address changes to DNS software at all until
_after_ we design syntax (not just semantics) of DNS records.
2) Configuration complexity.
For HELO checking, the configuration problems will revolve around the
use of subdomains. Most software will use the machine's FQDN or IP
address for the HELO prompt.
"Most software", IMHO, allows configuration of the HELO string.
Yakov correctly notes that we have a balancing act between software
changes and configuration in several different places.
I think all we can say is that sending MTAs may need to change the
HELO string or configure different DNS records for different MTAs.
An alternative would require configuring the MTA to use a specific
domain or subdomain for the HELO prompt, which would make DNS
administration easier but would involve more work on the MTA
configuration.
This raises the issue of whether we should advise using the same
HELO string for different MTAs sending on behalf of the same domain.
I'd rather not talk about that yet...
Another issue is keeping the information in sync between the MTA
configuration and the DNS configuration.
That is a definite issue if we recommend using a single string for
every MTA sending on behalf of a domain.
There is also a side issue of the HELO checking vs. the domains from
which it is sending email. A single SMTP transaction may process more
than one message within a single HELO prompt with the MAIL FROM values
for multiple domains. Therefore, it might be impossible to determine
whether network B has authorized the MTA when it is using network's A
domain name in HELO (for which it is authorized), while in fact it may
be relaying email from network B within that transaction.
Yakov correctly notes that HELO checking does very little to assure
that we have a good bounce address. It _might_ be able to accomplish
more if we defined things in such a way that a MTA sending on behalf
of multiple domains (_very_ common!) would give different HELO strings
depending upon which domain it is sending for -- per email. That, of
course, would definitely require software changes in the sending MTA.
3) Current use cases that will no longer be viable.
For HELO and in-addr.arpa, simply plugging in a machine and making it
an SMTP server will not be possible without configuration changes
including DNS.
Mostly correct. I'd accept "generally not be possible", and note that
the configuration changes could be automated with simple scripts. (In
fact, I would expect that the configuration changes _will_ be automated
based on a single email to a configuration server for the domain.)
DNS propagation delays might be a problem for machines that change
IPs.
DNS propagation delays _will_ probably be an issue -- leading to
mostly confusion rather than any actual failure. SMTP servers _will_
continue attempts at delivery for any temporary errors (typically for
up to five days), leading to potential questions of how to keep DNS
records active long enough without leaving security holes long enough
for spammers to find them. (This is why I greatly prefer SMTP-SUBMIT
to dynamic DNS.
Thus, IMHO, simply plugging in a machine -- for short periods --
and making it a SMTP server should be deprecated.
Also, the use of the IP address in the HELO argument would not be
possible anymore.
I believe this should be deprecated anyway. It passes no useful
information except if the IP address is different from its actual
IP address for the TCP connection -- in which case most admins would
automatically drop the session if they notice the difference.
4) Needed infrastructure changes.
Not entirely sure what is meant by this. Infrastructure of the Internet,
or a given enterprise?
I interpret the question to be broad: any known changes of any
infrastructure. By my interpretation:
- bandwidth requirements: minimal, overall, certainly will decrease.
- routing issues: none.
- DNS load: will increase, roughly N inquiries per email attempted.
N unknown until we have syntax.
- DNS root-server load: could be significant; can't say without syntax.
- support desks: perhaps 10 minutes per customer to explain each
change; eventual reduction in explaining spam/virus issues.
5) Considerations for use in both IPv4 and IPv6.
I am not an IPv6 expert but offhand there will probably be an issue with
recording IPv6 addresses in MARID records due to the UDP 512 size limit,
especially if a text format is used like SPF. This would be an issue for
all identities except .arpa (if mapped to rDNS). Otherwise they all look
pretty much the same to me.
As we get to syntax, we'll be able to intelligently address this.
Until then, I see no more we can say.
====
A metacomment: Andrew has handed us, IMHO, an insurmountable task.
I see absolutely no way we can have intelligent discussion of all these
issues in the time allotted. I believe Yakov's contribution is excellent;
I believe most contributions are helpful and good, but ruling out any
of these "identities" before nearing consensus on the semantics of each
IMHO prevents us from reaching a useful understanding of ramifications.
This email, at 200 lines, is already dangerously long, and only covers
what I consider essential for one small piece of the question before us.
--
John Leslie <john(_at_)jlc(_dot_)net>