On Fri, 2004-04-23 at 05:54, Margaret Olson wrote:
On 4/23/04 3:28 AM, "Greg Connor" <gconnor(_at_)nekodojo(_dot_)org> wrote:
For me, bandwidth savings is actually not the #1 or even #2 reason for
insisting on MAIL FROM validation. My #1 reason is that I don't want to
receive bounces from crap I didn't send.
I certainly sympathize, since my domains get lots of this junk too. But
forgive me if this sounds rude, but I don't think solving the problems of
mail server operators is what the general public is looking for in a spam
solution. They literally don't care, and most of them don't get bounce spam.
They get what I will call direct spam for lack of a better term.
The present SMTP system is prone to being spoofed with respect to return
addresses and is inundated with false bounces. The number of these
filtering down to users is a consideration, but without protecting the
basic infrastructure, no system will work. Being able to resolve the
domain responsible for the current transmission of mail helps
considerably in a process of deciding whether to accept the connection.
With domains added a dime a dozen, the concept of a rejection list will
likely evolve into an acceptance list. MTAs may adopt a wait-and-see by
issuing temporary errors on new domains or depend on a clearing house
before including a domain into this circle. A combination of these two
methods could be effective. I see a mechanism like SPF setting a
foundation for this approach. The basic integrity of the DNS system can
rid the system of the bulk of the problems.
For items needing security, encryption can happen with opaque objects at
the MUA where there exists a scaling advantage.
The most interesting thing about validation is not the validation itself,
but what you can do with the identity once you have it. Once you require
that certain records be in the DNS in order to send mail, spammers will
start publishing those records.
Any system that wishes to exclude miscreants must establish a circle of
trust. Being able to resolve the major party being trusted seems like a
good first step.
Personally, I'm not sure what the 2821 MAIL FROM tells you, unless people
start using the 2821 to signal other bits of information that link it more
directly than it is today to the sender (author). The domain that operates
the mail server has some control, the author has some control, and then
there is the 2821 from, which is linked to one or the other or both,
depending.
What is more important: knowing definitively that the error (bounce) handler
is valid, or knowing definitively that the originating server is legitimate
(e.g., that the domain example.com has authorized it's machine 1.2.3.4 to be
an outbound mail server), or knowing that knowing that purported the author
is legitimate? Of those three I can't help but think that the 2821 is the
least interesting.
Establishing a secure system using digital signatures and perhaps even a
third party secure time stamp to enable documents to withstand a period
of time involved in a possible litigation goes well beyond the scope of
this group. Adding encryption and signature processing at the MTA is
also the wrong place for this function as it does not scale well. The
load on MTA servers is increasing and adding functions that attempts to
resolve signatures for each from user will not helped the situation as
this will likely be a function not enabled.
At the risk of wandering into another thread, I am inclined to think that
validating the server is simpler than validating the sender, and if we have
a general purpose method it may make sense to use it first to check that
this server is authorized to send mail, effectively as a test, but with the
knowledge that that is just a start. That gets rid of the trojans and
hijacked machines. And, getting back to Harry's issue, I think you CAN
reject mail that comes from unauthorized mail servers.
Algorithms for creating a signature will not stop any entity from
posting their key information and complying. You are still left with
the task of deciding if this entity can be trusted. This mixing of
signatures with users complicates a process of deciding whether to
accept a connection that must then resolve to the user. This adds a
burden on the MTA. There is a cost for the domain no matter how small,
there is virtually no cost for adding a user. The essential elements
are discovering the domain responsible for the IP used to send the mail
via SMTP. Mixing user identities into this provides no relief, just the
opposite.
To transition into a system where responsible domains can be identified
seems to require providing a notice of some sort that the mail was
accepted without this verification. This would alert users that a
recommended practice was not being followed and that in the future, they
could start seeing mail lost from these parties as a result. An
educational process of sorts. A notice would also allow MTAs to start
dropping mail earlier depending on their policies.
-Doug