At 08:04 PM 5/17/2005 -0500, wayne wrote:
In <02fa01c55b0e$3e15c110$6401a8c0(_at_)hdev1> "Hector Santos"
<hsantos(_at_)santronics(_dot_)com> writes:
> ----- Original Message -----
> From: "David MacQuigg" <david_macquigg(_at_)yahoo(_dot_)com>
>
>> Here is an incoming email with no ID declaration.
>>
>> EHLO mailserver7.bigforwarder.com
>> MAIL FROM:<bob(_at_)sales(_dot_)some-company(_dot_)com>
>>
>> What do you do next if you want to authenticate this message?
>
> Dave,
>
> That should depend on the server, not the client. However, if I think
where
> you going with this (and this is not the say I agree with it), what
you are
> looking for the server expose to the client how the client can be
> authenticated:
>
> The more propery way to do this today with ESMTP would be for the server to
> expose what methods it support:
>
> C: EHLO mailserver7.bigforwarder.com
> S: 250-hostdomain.com, Plesase to meet you.
> S: 250-SIZE 5120000
> S: 250-ETRN
> S: 250-ID SPF1 SPF2 CSV
> S: 250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
> S: 250-AUTH=LOGIN
> S: 250 HELP
>
> So for this server, it supports SPF1, SPF2 and CSV.
Ok, so at this point, the phisher knows what will be required of the
email and can choose the appropriate 2821.MAILFROM or 2822.Resent-*
headers to make it past the authentication methods and yet minimize
the red lights that an MUA might display. This is good?
The only thing I can see that does anything that isn't damaging is
having the SMTP client say which methods *WILL* work, and leave it
open for the SMTP server to decide which methods it thinks is worth
while to check. The SMTP server must be free to check methods that
the SMTP client doesn't list. In fact, checking to see if methods
that aren't listed actually fail may be a very good idea.
The only advantage I can see is that if the SMTP server is willing to
trust the results of one of the methods that the SMTP client suggests,
it will be able to tell if the SMTP client is lying and ban the SMTP
client if it is.
While this isn't damaging, I'm not sure that it is that useful
either.
Wayne has a good point here. *All* information in the ID command is
suspect, including the ID itself. That is one reason I would prefer not to
load up on options at this point. It just gives the spammer more to play
with. We have to do a DNS query anyway, so
let's put the choice of methods in the Registry record, along with the
method parameters, public keys, whatever the ID owner needs to keep safe.
I will still support this proposal in spite of these problems, because
having a neutral ID is important, and we can ignore the cruft if it
contradicts what the DNS record says.
What if the ID is fake? The ID owner pays the price in lowered
reputation. ID owners will learn very quickly to fix their Registry
records, limiting their exposure to just the IP's they can control, and not
allow their ID to be abused.
--
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 *
************************************************************ *