Input on identities

> The proposed charter of this working group (and the BoF which has led
> to this point) have a limited scope and a limited timeframe. Since
> the initial pick list of identities was given, some of the proposals
> are leaning toward more grandiose mechanisms than previously
> proposed. Please keep in mind that the scope of the work here is to
> be limited to problems in the area of MTA authorization and the class
> of spam that may be stopped by this type of authorization (i.e. not
> spam generated from compromised hosts, ill-meaning senders, etc...).
Sorry to all for going out of scope before on trust. I have been
involved in trust discussions in the ASRG so some of this carried over
to here. I will try to keep silent about trust in the future in this forum.

> Therefore, we once again ask the participants of this list to focus on the 
> following identities:
>
> 2821 HELO/EHLO domain
> 2821 MAIL FROM
> 2822 From:
> 2822 Sender:
> New structure/RR's in .arpa *
I am pro 2821 HELO and .arpa, less enthusiastic about MAIL FROM since 
more changes will be needed to support rewriting and against 2822 
From/sender because of higher complexity. Comments below.
> 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; and in the receiving MTA for checking 
that parameter. 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. If filtering is done past the 
initial MTA (SpamAssasin for ex.), than 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.
MAIL FROM checking would require changes to support some form of 
rewriting or aliasing if the message is forwarded with the same bounce 
address, and an ability to relay the bounce messages back to the sender 
(unless each site has its own bounce address). This will raise the issue 
of spammers guessing the bounce format and using it to pass along spam, 
and there are proposals that address it. Of course the more complex the 
rewriting scheme gets, the more changes will be required to implement 
it. Filtering software past the initial MTA including the MUA (like in 
CID) would need to start parsing "Received" headers and check them 
against the "Return-Path" header, if MARID checking is desired on that 
layer. I don't see any changes in MUAs or MDAs, or MSAs, other than the 
need to make sure that the bounce address is configured properly on the 
sender's side.
With RFC2822 checking, the MUAs have to be changed to enforce the 
"From"/"Sender" header values as non-forged and to support checking by 
the receiver. MTAs will have to be changed to check these headers at the 
DATA command stage which would entail more processing since the entire 
message will be received before processed. HOWEVER, there is a catch 
here - MUA or filter level checking is not as foolproof since there is 
no 100% to know the IP address of the MTA accurately. On the other hand, 
MTA software under normal circumstances does not read the data inside 
the message itself after the DATA command.
With in-addr.arpa, no changes are needed at the sender's MTA or MUA. The 
only changes that are needed is the receiving MTA which will evaluate 
the information at connection time just like RBL info is used today by 
some systems.
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.
Of all of these, in-addr.arpa and HELO requires the least change, MAIL 
FROM checking requires change on MTA level to support rewriting and 
MSA/MUA level to constrict the bounce address; and header checking 
requires changes on either MUA and MTA levels to support checking, and 
MUA/MSA/MTA to constrict the address.
> 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. In those cases, this would imply that MARID 
records would have to be stored at the subdomain level for each MTA, 
which would make configuration more complicated. 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. Another issue is keeping the 
information in sync between the MTA configuration and the DNS configuration.
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.
For MAIL FROM checking, the configuration complexity is higher since 
MTAs must be able to check and rewrite bounce addresses. However, in 
regards to keeping information in sync between DNS and MTA configuration 
it is probably the same as HELO checking. There is also an issue with 
the need to change configuration whenever an MTA changes IPs.
In "from"/"Sender" checking there are configuration details on the 
sender's MUA and MSA to constrict the headers to legit values, and to 
properly check the incoming messages on the receiver's side. These 
sounds to me the same as MAIL FROM when we need to restrict "return path".
For in-addr.arpa there is only one entity being administered unlike the 
other identities, and only one piece of software that needs to be 
configured (the DNS server). However, since the rDNS zone is poorly used 
by ISPs, the administrator might have a harder time gaining access to 
the rDNS configuration then with other identities which use forward DNS.
In regarding to the configuration issue, in-addr.arpa and HELO checking 
require the least complexity. But once you move from MAIL FROM to 
RFC2822 checking, it sounds like the complexity is increased but is the 
same for both RFC2821 and RFC2822 FROM. However, since header checking 
involves the MUA and MDA possible, it will probably be more complex 
because of the number of components that need to be configured. I am 
positive with HELO and in-addr.arpa and less so about MAIL FROM/RFC2822 
headers.
> 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. DNS propagation delays might be a problem for machines that change 
IPs. Also, the use of the IP address in the HELO argument would not be 
possible anymore. For in-addr.arpa, relaying email from a machine 
without the permission of the network's operator would not be possible 
such as roaming or mobile users unless an MSA is used in conjunction 
with an authentication mechanism (see SUBMIT BCP draft). For HELO 
checking that would still be possible if another domain is used in 
conjunction with a given IP.
For RFC 2821 MAIL FROM checking, forwarders, mailing lists, greeting 
card sites, newspaper "Send copy to friend" sites, etc. would not be 
allowed unless their own bounce address is used or a rewriting mechanism 
is utilized. Mobile users will not be able to send email unless they 
used an MSA they have access to or their own domain while listing the IP 
dynamically in DNS. Users will not be able to relay email through a 
specific host with their bounce address on a different system unless a 
rewriting scheme is used. This would mean that someone who wants to send 
a personal email via his business MTA would need a bounce address 
associated with the business domain unless the MSA is rewriting his 
bounce address.
For RFC2822 header checking, the same would apply. Additionally, users 
would not be able to relay email through any MTA that does not match 
their headers, including the use case of a personal email with a 
different "from" header being sent via a business account (and vice 
versa). Users will be tied in directly to a specific set of MTAs 
provides by a domain, unless some kind of rewriting is used.
With HELO and in-addr.arpa checking, there are less use cases being 
broken. With MAIL FROM there are a lot more, and with header checking 
there are even more. Therefore, I am positive about HELO and 
in-addr.arpa checking, less so about MAIL FROM and against the RFC2822 
header checking.
> 4) Needed infrastructure changes.
Not entirely sure what is meant by this. Infrastructure of the Internet, 
or a given enterprise?
> 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.
Yakov