(As I submit this just one day before the deadline! eek!)
Therefore, we once again ask the participants of this list to
focus on the following identities:
2821 HELO/EHLO domain
Useful for verifying the identity of a MTA only, but this is very useful to
know for such things as delivery status notifications, allowing
store-and-forward when the MTA isn't a sender for a domain, and similar.
Most of the time, a MUA doesn't have enough information to provide an
accurate or even useful HELO/EHLO identity. However, modern MUAs can perform
authentication against a specific MTA to send its mail, allowing tighter
controls than with HELO/EHLO alone. Accountability for MUAs and their users
may be achieved through these other controls, allowing the MTA to ignore the
HELO/EHLO from a MUA.
Delivery Status Notifications are unverifiable by MAIL FROM alone. HELO/EHLO
checking provides additional information to identify if the DSN at least came
from a verifiable MTA. The operators of the MTA could then be held
accountable for DSNs originating from it.
2821 MAIL FROM
Bias: this was my main focus in draft-fecyk-dmp.
Most of the proposals assume the end-to-end transmission occurs from sender
MTA to receiver MTA only, and asusming this, the sender MTA MUST belong to
the domain specified in MAIL FROM. If these assumptions are completely
correct, then the MAIL FROM information is extremely useful at least to tell
where to send bounces back to, and at most hold the domain identified as
accountable for that mail.
Real-world applications break these assumptions, ie: store-and-forward,
referral and greeting card applications, and some mailing list applications.
Workarounds for all of these have been identified at one point or another,
and some are even in use currently.
2822 From:
Bias: I don't like messing with message content, including headers. There
are legal, political, customer service and social problems surrounding any
messing around with content.
RFC 2821 requires a MTA to receive an entire message if it is going to
receive a message at all. Any verification of this header can occur only
after the MTA receives the message. At the least, bandwidth is still used
should the MTA reject the message based on verifying the From header. At the
most, this breaks routing bounces to special addresses, as many mailing list
applications use.
Not verifying this header leaves forgery, in the eyes of the receipient, wide
open. Nothing stops a sender from faking a prominent domain here while still
verifying RFC 2821 MAIL FROM, or RFC 2821 HELO/EHLO. MTAs could tag these
messages as "may be forged" to help. I would prefer verifying this be left
in the hands of the mailbox user, or the application the mailbox user
uses.[1]
2822 Sender:
Same bias as above.
The most common MUAs don't display this header, so this would be of limited
use today. Newer MUAs could look for this and compare it against the 2821
MAIL FROM, and some MTAs might insert this header using the MAIL FROM data,
or a "X-Sender" equivelant. More visible in common MUAs is the 2822
Reply-to: header, which may be displayed as "From: [original-sender] on
behalf of [intened-reply-address]".
Sending on behalf of another is still useful and, if Sender: could be
required and matched to the sender's hosts or domain, we could at least hold
the sender accountable for this mail.
We still have the problem of having to receive an entire message to parse
this header.
New structure/RR's in .arpa *
As pointed out at the BOF, .arpa is closest identified with the network
infrastructure, where the forward domains are identified with organizations
and components of those organizations.
Is identifying a host as a mail sender an organizational problem or a network
infrastructure problem? Also, the administrators of the organization and the
administrators of the infrastructure may be in conflict here, notably when
the infrastructure's administrators say "no servers" in their terms of
service.
My own experience is those who control the network infrastructure, and thus
control .arpa, are LAZY in identifying components of the infrastructure and
in delegating responsibility for identifying components downstream.
in-addr.arpa specifically has limitations in how large those delegations must
be (minimum /24 unless RFC 2317 is used), and those delegations (especially
with RFC 2317) are not trivial to maintain and administer. ip6.arpa appears
better suited for smaller delegations than in-addr.arpa.
If organizational control is available in the .arpa name spaces, records to
identify mail hosts here may be useful. But only if that control is
available. We could hold the organization accountable for the mail hosts
identified here. Already we can hold network infrastructure administrators
accountable, through tracing network routes or with WHOIS information,
without special records in .arpa.
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).
The existing documents focus on MTA changes only. This was intended to keep
changes at a minimum. Mostly the MTA would query and parse DNS data during
the SMTP conversation and act in accordance with the documents' instructions.
MUAs can be held to tighter controls already, through AUTH, SUBMIT and other
mechanisms. To identify received mail, however, the more common MUAs may
need to expose the 2822 Sender: header to the user.
If we require one or more DNS RRs, DNS servers will need at minimum to handle
previously unknown record types (What was the RFC again?) and at best be able
to work with the new record types we create here by name.
In theory, a MARID-aware MTA could submit dynamic DNS updates to a dynamic
DNS server on startup, or at any other time. Information for these records
could come from the MTA's environment, a configuration file, both, or other
sources. In some cases (such as Active-Directory[tm]-integrated DNS) this
may be the only way to provide new records to the DNS server.
Resolvers would need to be capable of querying and retriving previously
unknown record types. Most resolvers speak UDP with DNS servers directly
anyway, and editing an existing resolver or writing a new one is
near-trivial. This resolver could be part of the MTA, or a plug-in package
for the MTA.
2) Configuration complexity.
This varies wildly betwen proposals but achieves similar results. Some allow
for quicker responses to queries and dynamic DNS updates, some allow for more
efficient and cachable information, some allow for an entire policy language.
Performance data is only available for one type right now - I'd like to see
performance data for the others too.
NOTE: I barely have time as it is to do this. Besides if I benchmarked the
others I could be seen as biased.
Speaking of biases: I like the KISS principle myself. Less chance for
implementation mistakes and "assumptions."
If we're really clever, a DNS administrator might not even have to worry
about hand-writing a bunch of new DNS records, if the DNS server supports
dynamic updates and works with previously unknown record types (if using new
RRs), and the MTA software feeds them to the DNS server.
3) Current use cases that will no longer be viable.
Store-and-forward is the hotly-debated current use case that I believe will
be LESS viable, but not impossible to use.
In fact every case that's been debated as a current use to be no longer
viable, is adaptable in some fashion. The developers of those applications
can and will find new ways to make them viable again, while still providing a
means to hold its users accountable.
4) Needed infrastructure changes.
Did anyone else come up with anything for here? I don't see any needed
changes to _network_ infrastructure, for example. DNS servers will get
busier but MTAs will get less-busy from lower SMTP volumes. But these are
site changes only.
If information is stored in .arpa, we'd need to kick the rear ends of its
administrators to populate it with useful information and to delegate access
to .arpa name space to organizations with mail hosts. I seem to remember
commentary from the BOF suggesting it was the equivelant of herding cats, or
something like that. This could just as easily be a _customer service_
problem, though, and organizational administrators will demand access to
.arpa from their providers if needed.
5) Considerations for use in both IPv4 and IPv6.
The MTA will have to know which network type to look up, but it should know
that based on what kind of host connected to it.
Two proposals mimic .arpa in their design, and will have to mimic
in-addr.arpa and ip6.arpa to store information as appropriate. Others will
require more data space to store an IPv6 host's information compared to an
IPv4 host, which could limit the capability to return useful information in a
single DNS UDP response.
[1] I believe Daniel Hanson at Securityfocus put it best:
<http://www.securityfocus.com/columnists/231>
Some of these mass-mailing viruses require that users:
1. open an email message
2. open a picture to determine a word used as a password
3. open a zip file
4. enter the password when prompted
5. and then run what is included in the zip file
The virus authors have people jumping through more hoops
than a circus seal, and all for what, a glimpse of a
naked celebrity?
Users are going to let themselves get duped if they're that stupid, and
nothing we do here will stop that. This is a social problem and not a
technical one.
--
PGP key (0x0AFA039E):
<http://www.pan-am.ca/consulting(_at_)pan-am(_dot_)ca(_dot_)asc>
Sometimes it's hard to tell where the game ends and where reality bites,
er, begins. <http://vmyths.com/resource.cfm?id=50&page=1>