On Thu, 2004-07-22 at 21:32, Hector Santos wrote:
Who cares what it means or what the original intent was! It still must be
verifiable!
If the industry has Time Square neon flashing advertisements saying the
"60-80% of the MAIL FROM: address is BAD," it is completely boggles the
mind as to why everyone is ignoring it in the name of what the darn user
will see!!!
Your proposal is based on a verifiable client domain name. Why can't the
MAIL FROM be verifier? Even it is a bounce address? Why must one 1 of 2
inputs be valid and not the second?
The RFC 2822 identities being checked are also often not seen by the
user. As with with the expression of having two lawyers arriving at
three opinions, the definition of who actually sent the mail is not
concerned with the question who authored the message either. The return
error path is unrelated to the author as is the sender in many cases.
The advantage using the RFC 2821 MAIL FROM, is less confusion over what
is being checked and what piece of information adds to any assurances.
Another important aspect of the RFC 2821 MAIL FROM is that it is used to
sneak into the back door of sites that block with IP based accreditation
services using those sites that don't. Blocking with name based
accreditation, this blocking figure could approach 100% as such could
become very aggressive in a safe manner. This accreditation could also
declare the age of the domain. To do this, authentication and
authorization of the MTA by the controlling domain is vital. The Core
specification fails to provide that information. The submitter
specification fails to provide that information. These are filtering
inputs only.
What is important varies depending upon what is being accomplished. If
to accredit the polices of the MTA, the HELO domain must be
authenticated and authorized. If to close the back door on the bounce
traffic, then the RFC 2821 MAIL FROM should be checked. I suspect the
BATV proposal could include an option to allow use of the CIDR notation
to specify legal Return paths in addition to a signature.
If you wish to filter the messages, then the RFC 2822 identities play a
role, but filtering is an inherently bad choice to control the problem.
Filtering is a cause for the loss of mail integrity. The goal should be
to put the burden upon the sender to keep their accreditation high to be
accepted, rather than expecting the receiver to filter junk that
continues to enter unabated. Desirable mail gets discarded in the
filtering process only because it is impossible to recognize spam from
desirable mail in many case.
Dave Crocker's Bounce Address Tag Validation can solve this back door
problem. If done using public key encryption methods, it can be used to
block this traffic before being bounced. It can also be used to exclude
traffic completely forged. The down side, if you wish to call it that,
is that it can be susceptible to 'replay' attacks. By using a time
stamp, any replay can be filtered and would only need to be stored in a
filter list for the duration of the key life of perhaps 10 days.
Sender ID offers a means to continue phishing by playing games with the
PRA, which users are likely not to understand, and which there is likely
a means to find differences between interpretations of what is being
checked and presented, owing to the complexity of the task. Such
differences alone will offer ample opportunity to phish. As the user
will likely continue to focus on the RFC 2822 From, the ability to
confuse the user remains. It is already amusing the SPF records are to
be used "as is" which are based upon the RFC 2821 return path. Should
there be a desire not to agree to the contract offered by Microsoft, the
use of the RFC 2821 MAIL FROM over the same record set is still
possible.
What is being checked? The error return path? The sender? Does it make
a difference, as it is not the author that is being checked and that is
what people will likely be looking at. Something like Identified
Internet Mail answers the question, is this the author and is this their
message? Frankly, other than selling a filtering MUA, I can not see
much use for the RFC 2822 checking stuff.
-Doug
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
To: "Jim Lyon" <jimlyon(_at_)exchange(_dot_)microsoft(_dot_)com>
Cc: <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Tuesday, July 20, 2004 2:55 AM
Subject: Re: MTAs should focus on email TRANSPORT not email CONTENT
Jim,
JL> The mis-named "MAIL FROM:" doesn't tell you who sent the message, but
JL> who wants to receive the bounce if any. Much confusion would have been
JL> avoided if the 2821 command were spelled "MAIL BOUNCETO:". Many people,
JL> including me, have gone down the path of erroneously trying to use "MAIL
JL> FROM:" for authentication.
given that the misnomer dates back to rfc 821, it's rather impressive
that it took more than 20 years for us to notice the error!
in an odd way, this highlights the difficulty of preventing scaling
problems.