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