At 08:57 AM 5/17/2005 -0700, ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
I assume from the position of your comment above, that you are objecting to
the expectation that Reply Code 500 could be a normal and harmless
response. The key question for me is - Will it actually break
something? I've tried sending the ID command to a variety of receivers
using different server software, and they all respond with either 500 or
502, yes even Hector's super-strict Winserver!
Servers exist that will hang up on the first invalid command they receive.
Examples include the Microsoft Mail SMTP server (where it was a bug since it
also applied to EHLO) as well as a bunch of more modern servers, many of which
are configurable to allow only so many bad commands before hanging up. I don't
think it is wise for people to set such limits to 1, but I've seen several
people do it.
Can you give me some example domains, so I can do an experiment?
It is therefore essential that the EHLO negotation framework be used to
avoid sending unrecognized commands.
Done. I added a short example to the IANA section. See previous post.
But this isn't the real problem with your proposal - fixing it so it
used EHLO is simple enough. The real problem is that you have yet to
demonstrate how adding an ID command is actually effective in combating
spam. I'm with Valdis on this one.
This is not the right forum for an extended discussion of email
authentication, but many, including myself, believe that authentication is
a key enabler to stopping spam. Without forgery, spam couldn't exist.
Assuming more than one authentication method will be widely deployed,
receivers will have a problem knowing exactly what method a sender is
using. Valdis didn't reply to my earlier challenge, so I'll ask you the
same question.
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
************************************************************ *
* 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 *
************************************************************ *