Drukowana wersja artykułu
Kliknij tutaj aby zobaczyć artykuł w oryginalnym formacie
Invisionize.eu - IP.Board (IPB) News _ IP.Board 3.x Tracker _ SMTP HELO/EHELO
Dodane przez: Invisionize.eu czw, 05 sierpień 2010
This is somewhat in reference to:
http://community.inv.../page__hl__helo
In the past 3.x defaulted to "HELO" and feel back on "EHELO", but according the the above report it was
changed to make the method selectable.
I've been doing further work in the SMTP and Email realm and have been pouring over RFC documentation,
and seeking out other examples of implementation (including IPB's) and I've noticed a couple points of
interest that may concern you.
The "HELO" command was part of the original spec of RFC 821, which does not include authentication. The
"EHELO" command was introduced to represent the "extended" or "enhanced" features described in RFC
5321, which does support authentication.
I'm not quite sure why IPB started with "HELO" and fell back to "EHELO", but according to the spec
authentication would have never worked under those circumstances since all MTA's should support HELO for
older SMTP clients. Instead it should have started with "EHELO" and fell back to "HELO". As far as I can see
in the code (this may be different in the settings) HELO is still the default even though it can be changed.
It's also worth noting that authentication should not be attempted with the HELO command and some mail
servers may require a digest type authentication depending on configuration... The commands supported, as
well as authentication types, from the RFC 5321 spec are sent in a response after the EHELO command.
Another thing I've noticed is the parameter for HELO:
HELO domain
IPB sends the same host that it connects to in the HELO parameter. What it should be doing is populating
this with the host that it's connecting from. Mail clients, like Thunderbird, tend to populate this with the
computers hostname. With a website this probably should be $_SERVER['HTTP_HOST'] or another specified
domain.
Everything I'm talking about is described in RFC 5321 under section 3.2 (as well as some other areas):
Quote
Once the server has sent the greeting (welcoming) message and the
client has received it, the client normally sends the EHLO command to
the 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 that are unable to
support service extensions, and contemporary clients that do not
require service extensions in the mail session being initiated, MAY
use HELO instead of EHLO. Servers MUST NOT return the extended EHLOstyle 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.
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").
I realize that some of this may require some further investigation and may be flagged for later review since
it isn't a critical issue... but I thought I would bring this to your attention anyway.
I've completed my mail class recently, and I've also implemented RFC 4870/4871 within in (client-side DKIM
signatures). The use of DKIM and SPF decreases the likelihood of a message being marked as spam.
Typically setting this up requires configuring the MTA to sign outbound messages... but with shared
environments this may not be possible. If you have any desire to peruse that I'd be willing to share what
I've learned. Some of the work I've done was posted here, which validates a signed message and could
easily be used to figure out how to sign a message.
Źródło: http://community.invisionpower.com/tracker/issue-24676-smtp-heloehelo/
Powered by SD.Agregator (http://www.invisionize.eu)
© SpannerDEV (http://www.spannerdev.pl)