Dave, I agree with your thoughts, in particular your parenthetical
statement:
(The 2822.Sender sets the value for 2821.MailFrom. Hence,
2821.MailFrom is really an end-system identity.)
If I may add one question and one comment to your thoughts.
Question:
If it is *mandatory* for MTA to add the network control header Received: why
it is not possible to use this as part the "chain of trust" separately or
in combination with the end-system entity verification?
In other words, as a transaction is routed, I believe we already have the
mechanism in place to validate the chain of trust. I just don't know how
many systems use this information other than maybe to stop a endless or
maximum hop loop.
Am I missing something here?
Here is an algorithm I can see:
Level 1: SMTP protection
They can use whatever means they seem fit as long as it follows the new
conformant standards for 2821, meaning they can reject based on HELO/IP/MAIL
FROM.
The forwarding situation can be detected if the HELO is validated first or
rather NOT excluded from the test.
HELO validation - successful
MAIL FROM validation - failure, softfail or neutral.
This Must Be True because of the chain of trust. In this situation, this
can be marked "Soft-fail" and the transaction allowed to continue for RFC
2822 validation Lets assume that a "Received-SPF:" is used to record this
situation.
Level 2: RFC 2822 validation either with dynamic DATA SMTP or POST SMTP.
If the Received-SPF is present, the forwarding situation can be resolved if
the originating Received: header MATCHES the RFC 2821 and/or RFC 2822
information.
If there are more than two routers, then it be left up to the implementation
to decide how much of the chain trust is required.
Finally, at level 2, the system implementation can decide to provide
administrative defined logic or options to have a "strong" RFC 2821/RFC 2822
Sender/From matching check. But this has to be optional.
I see this as doable, the questions I have about are:
1) Integrity, can this be helped with a continuous CRC concept on each
header? Maybe, but required extensive software change.
2) The Received: header can be added by more than just the SMTP receiver.
Other sub-systems add it, gateways, internal routers, etc. Even some POP3
servers are known to optionally add it to help solve a "Date Problem" with
MUAs such as Outlook. Can this alone kill the idea? Or is there a
distinctive tag that can be used to pick off the SMTP record.
Comment:
Lets use pareto's principle (80:20 rule) in solving this anonymous access
management problem. It is a known fact that at least 60-80% of all spams
and current generation malicious email-virus use "spoofing" addresses and/or
domain. I don't know how many systems our there are using IP:DOMAIN
association algorithms and/or CBV concepts, but this has empirically proven
to be a true situation.
So what are our goal? Rhetorically, To turn the spoofers into a valid
sender or to eliminate the spoofers?
I say both. A simple philosophical change in providing RFC 2821 enforcement
will eliminate an extremely large percentage of the problem. Again, I am
not tooting my own horn, but we proved this. Those spammers who are intent
in staying in business will have no choice but to show valid information
that can be traced, tracked and audited. Others will probably get a new
line of work.
Basically, what I am saying is that, I have no issue with any IDEA or
method. I am not against RFC 2822. I am an system engineer and I am trained
to look at everything. But what I am saying I think we are complexing the
problem because at least 60-80% of the spoofers can be detected and stopped
at SMTP and unless we change the SMTP state machine to a concept similar to
BDAT or a HEAD/BODY concept where we optimally and technically perform
network/mail control header validation concepts at this level, with the
current SMTP model, we will promoting a mode of operation that is most
definitely going to create local system and network bandwidth issues. Mail
Data is going to increase, not decrease. Imaging, Audio, etc, is all part
of the future, if not already. For a system to distribute this body
information when the odds are extremely high it is spoofed, it will be a
complete waste to not focus on RFC 2821 level protection first.
I really wish I was wrong. Any software logic would love to have all the
information it can get to make logical decisions. But the current model does
not lend itself to this design. It is two levels and promotion of RFC 2822
as a prevailing mechanism before RFC 2821, in my technical opinion, is
completely wrong, so wrong, I will have a difficult time endorsing it or
even using it. It just doesn't make sense. Again, change SMTP to include
header information and then I'm all for it 100% - no questions asked. But
that's not reality and I don't see that happening.
From what I see/read here, I think everyone is nearly on the same page but
for this chicken and egg problem of "what comes first" RFC 2821/2822 issue.
Hence, let use some management principles to decide - pareto's principle.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
To: <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Thursday, April 22, 2004 4:24 PM
Subject: Re: Client SMTP Validation jabber summary
Folks,
DC> 4) Why pursue this mechanism first, rather than authenticate another
DC> SMTP or RFC2822 identity through one of the other proposals?
Some further thoughts:
There are vastly more users (and user domains) than there are
operators. Hence, finding a way to vouch for an operator will produce
a benefit across a number of users (and domains).
Interestingly, this really is only the one, strong argument that is
used in favor of pursuing an infrastructure-based solution, rather
than the usually-superior end-system based one.
This approach is has an important degree of stability, because it is
not subject to the problem of combinatorial explosion, as is present
with using a channel-based mechanism to check and end-system identity.
2822.From, 2822.Sender and 2821.MailFrom are all end-system
identities. (The 2822.Sender sets the value for 2821.MailFrom. Hence,
2821.MailFrom is really an end-system identity.)
In particular, any scheme that ties authentication/authorization of
the last-hop MTA to an end-system identity means that all combinations
of last-hop MTAs that the identity must be pre-registered. This
creates a scaling problem for any end-system identity with a
substantial amount of MTA mobility. (This is in addition to the
problem posted by independent intermediaries that are used and not
amenable to pre-registration.)
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>