Andrew Newton <andy(_at_)hxr(_dot_)us> wrote:
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.
People should not be blamed for discussing the projects outlined in
the "recommended reading" documents (which are, admittedly, a bit on the
grandiose scale).
I certainly agree we shouldn't be designing something which is the
union of those documents.
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...).
From the charter:
"
" It would be useful for those maintaining domains and networks
" to be able to specify that individual hosts or nodes are authorized
" to act as MTAs for messages sent from those domains or networks.
" This working group will develop a DNS-based mechanism for
" storing and distributing information associated with that authorization.
" ... This will help combat a certain class of domain forgery common in spam.
I do not agree that "spam generated from compromised hosts" is excluded
from our scope. Nor do I see how anyone can believe that mail generated
by "ill-meaning senders" is out of scope.
Our scope _is_ limited, yes, but the limits are that we are designing
a mechanism for storing and distributing "authorization" information.
Therefore, we once again ask the participants of this list to focus on
the following identities:
2821 HELO/EHLO domain
A wide variety of posters have said that we need to fall back on this
for testing authorization of bounce messages (and other emails with an
empty RFC2821-MAIL-From). I entirely agree.
2821 MAIL FROM
This is the fundamental identity in the envelope (which is the only
information currently used by most Mail-Transfer_Agents). IMHO, it would
be senseless to exclude it.
2822 From:
There is every reason for "those maintaining domains and networks" to
want to "specify that individual hosts or nodes are authorized to act
as MTAs" for the user-visible RFC2822-From address.
I'm _willing_ to put that off, if absolutely necessary, but I do not
believe we can leave it untouched. At the very least, we should carve
out room for expandability. (I believe that a single DNS query should
be able to tell us _whether_ the domain owner wants to list authorization
for using that domain in the RFC2822-From.)
(I agree with Aredridel that it's easy to create misleading domains;
but I stronly urge allowing expansion to allow specifications relating
to headers which may automatically generate email addresses.)
Thus, I'm unhappy to _exclude_ Reply-To:, for example.
2822 Sender:
Frankly, I don't care much about this. YMMV...
New structure/RR's in .arpa *
Huh?
We also ask that participants consider and list the following
ramifications regarding deployment issues:
These must wait for another email:
1) Amount of change in software components (MDA, MTA, MUA, DNS servers,
DNS resolvers).
2) Configuration complexity.
3) Current use cases that will no longer be viable.
4) Needed infrastructure changes.
5) Considerations for use in both IPv4 and IPv6.
--
John Leslie <john(_at_)jlc(_dot_)net>