Salut Xavier,
On Thu, Apr 04, 2013 at 11:49:42AM +0200, Xavier Beaudouin wrote: > Le 4 avr. 2013 à 11:37, Sylvain Rochet <grada...@gradator.net> a écrit : > > > > Humm, ça ce n'est pas dramatique, rien dans le protocole SMTP n'oblige > > le HELO/EHLO. > > Si c'est une obligation, cf http://www.ietf.org/rfc/rfc2821.txt > > 3.2 Client Initiation > > Once the server has sent the welcoming message and the client has > received it, the client normally sends the EHLO command to the "normally" != MUST > server, indicating the client's identity. In addition to opening the > session, use of EHLO indicates that the client is able to process > service extensions and requests that the server provide a list of the > extensions it supports. Older SMTP systems which are unable to > support service extensions and contemporary clients which do not > require service extensions in the mail session being initiated, MAY > use HELO instead of EHLO. Servers MUST NOT return the extended "MAY use" != MUST > EHLO-style response to a HELO command. For a particular connection > attempt, if the server returns a "command not recognized" response to > EHLO, the client SHOULD be able to fall back and send HELO. "SHOULD" != "MUST" > In the EHLO command the host sending the command identifies itself; > the command may be interpreted as saying "Hello, I am <domain>" (and, > in the case of EHLO, "and I support service extension requests"). > > Après on peux avoir différentes interprétation du "client's identity", > comme certains spammeurs ne font pas du travail propre, certains admin > de mail insitent que HELO/EHLO <truc> représente le FQDN complet et > propre de l'IP source et que sont reverse correspondent. Ce qui est tout aussi faux, il n'y a aucune restriction sur la chaîne suivant le HELO/EHLO. Sylvain
signature.asc
Description: Digital signature
