Stuart, I'm disappointed that you gave this no more than a few minutes
thought. I worry this is nothing but downhill from here, but I'll give it
a try.
At 05:11 PM 5/20/2005 -0400, Stuart D. Gathman wrote:
On Fri, 20 May 2005, David MacQuigg wrote:
> Does it require some new authentication method, or can we trust it to
> really be the sending MTA's Declaration of Identity?
No, we can't trust it. Any MTA can say anything they want - just like
with the other identities we already have.
An MTA can make a false declaration, but it is still their declaration. It
isn't just information they are passing along. This is an important
distinction between the ID command and the other identities in an email.
Authentication is the next step, and that does not require some new method.
> Nothing in the ID command is hearsay. You didn't get the information from
> someone else. You can't claim that using someone else's ID was an
innocent
You have proposed nothing that would allow you to check whether I am
lying about any name I make up for the ID identity.
You snipped some important context from the previous paragraph:
Assuming this is a legitimate domain with an authorized Public Mail
Server, you will not have access to its authentication records. These
records will not authorize your mail server.
A sending MTA can lie about any identity, including the MAIL FROM. The
difference is, when that identity fails the authentication check, if it
came from the ID command, you will know it was a lie, or at least gross
negligence. You can safely reject this email. If it came from the MAIL
FROM command or the HELO command, it could be one of many common mistakes,
or even a sender's policy decision, for example, leaving the Return-Path as
is rather than modifying it as expected by SPF.
> With an ID command, the border guard says - Give me an ID that authorizes
> you to cross this border!! Present a false ID, and you are in trouble.
How would you know whether it is a false ID?
Go to _AUTH.<ID>.mail.net, use the specified authentication method, and see
if the ID authorizes the IP. Nothing magic here, just a shortcut to avoid
DNS hunting when you don't know up front which method will be used.
There is a huge black market business in manufacturing false IDs - both
physical and virtual. In a newletter I received on illegal immigration, a
Congressman claimed he had instructed his staff to steal his identity (to see
how difficult it was). A fake drivers license was $15.
The whole point of SPF is providing a way to check the MAIL FROM ID. There is
no existing or yet proposed method of checking your new ID type.
Microsoft is closer with their PRA ID type. At least they have
*proposed* a checking method, and can force their large customer
base to implement it.
There is no need for a separate check on the declared ID. If that ID
provides a method that generates a PASS, then it accepts responsibility for
the transfer, even if the sending MTA is committing forgery (deliberately
claiming a false identity). No doubt there will be plenty of worthless IDs
available that authorize anyone to do anything, and those IDs will be
heavily used by spammers. That's what we need domain ratings for.
I'm thinking of adding a paragraph at the end of section 5 to make it more
clear how the normal authentication checks are done. How does this sound:
Assuming the _AUTH record calls for a CSV check, you will need to need to
check the DNS record setup at the identity specified in the EHLO
command. If it calls for an SPF check, you will need to check the EHLO and
MAIL FROM identities. The MAIL FROM identity may need to be altered to
preserve the original Return Path, while allowing an SPF check against the
IP for the current hop.
--
Dave
************************************************************ *
* David MacQuigg, PhD email: david_macquigg at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *