ietf-smtp
[Top] [All Lists]

Re: Options for the ID command

2005-05-17 18:46:07

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          *
************************************************************     *



<Prev in Thread] Current Thread [Next in Thread>