Hector,
I'm not the guru and actually might be wrong, but I believe the first
line should contain the hostname, just as you did it. This is also how,
for example, sendmail does it when using multiline greeting messages.
RFC2821 does not explicitly mention this and the info in the RFC seems,
at least to me, a bit confusing:
4.1.1.1:
[...]
ehlo-ok-rsp = ( "250" domain [ SP ehlo-greet ] CRLF )
/ ( "250-" domain [ SP ehlo-greet ] CRLF
*( "250-" ehlo-line CRLF )
"250" SP ehlo-line CRLF )
[...]
For the 250 reply code, the data in the first line stays the same, no
matter whether it is single line or multiline. Somehow it would also be
counterintuitive to move the first line to the end in multilines.
But oops, the SP right after the 250 code is missing in the single line
version. A documentation bug?
4.2
[...]
In particular, the 220, 221, 251, 421, and 551 reply codes
are associated with message text that must be parsed and interpreted
by machines.
[...]
Formally, a reply is defined to be the sequence: a
three-digit code, <SP>, one line of text, and <CRLF>, or a multiline
reply (as defined in section 4.2.1)
[...]
Only the EHLO, EXPN, and HELP
commands are expected to result in multiline replies in normal
circumstances, however, multiline replies are allowed for any
command.
[...]
Should a multiline greeting be allowed as well, even it is not the
reply for a command, but rather the reply of the connection initiation?
I believe yes.
4.2
[...]
Greeting = "220 " Domain [ SP text ] CRLF
Reply-line = Reply-code [ SP text ] CRLF
[...]
The ABNF for the greeting, does include a space right after
the reply code and there is no multi-line variant given. Possibly
this ABNF should be adjusted to
Greeting = ( "220" SP domain [ SP text ] CRLF )
/ ( "220-" domain [ SP text ] CRLF
*( "220-" text CRLF )
"220" SP [ text ] CRLF )
4.2.1
[...]
The reply text may be longer than a single line; in these cases the
complete text must be marked so the SMTP client knows when it can
stop reading the reply. This requires a special format to indicate a
multiple line reply.
The format for multiline replies requires that every line, except the
last, begin with the reply code, followed immediately by a hyphen,
"-" (also known as minus), followed by text. The last line will
begin with the reply code, followed immediately by <SP>, optionally
some text, and <CRLF>. As noted above, servers SHOULD send the <SP>
if subsequent text is not sent, but clients MUST be prepared for it
to be omitted.
[...]
In many cases the SMTP client then simply needs to search for a line
beginning with the reply code followed by <SP> or <CRLF> and ignore
all preceding lines. In a few cases, there is important data for the
client in the reply "text". The client will be able to identify
these cases from the current context.
The last paragraph probably only should be applicable if the client does
not need/want to interpret any of the data in the reply but simply wants
to skip over it. It is likely the implementation you encountered is
either skipping to the last line of the greeting or is looking for a 220
reply code which is followed immediately by a space. Would be
interesting to know what that implementation does when a 554 is given
for the greeting, rather than a 220.
All in all I would think the domain has to be looked for in the first
line of the greeting, even if it is a multiline greeting.
Cheers,
Kurt
On Tue, Jan 20, 2004 at 11:59:36AM -0500, Hector Santos wrote:
220-winserver.com Wildcat! ESMTP Server v5.7.450.9b13 ready
220-************** WARNING: FOR AUTHORIZED USE ONLY! **********************
220-* THIS SYSTEM DO NOT AUTHORIZE THE USE OF ITS PROPRIETARY COMPUTERS *
220-* AND COMPUTER NETWORKS TO ACCEPT, TRANSMIT, OR DISTRIBUTE UNSOLICITED *
220-* BULK E-MAIL SENT FROM THE INTERNET. THIS SYSTEM WILL RESTRICT ACCESS *
220-* TO CAN-SPAM (US S. 877) COMPLIANT CLIENTS ONLY. *
220 ************************************************************************
[...]
mail.winserver.com claims to be host **************.
It seems DNSREPORT.COM is only looking at the last line to get the
information it expects.
I tested this theory by manually adding a simulated SMTP greeting line that
looks like the top line to the bottom of the system policy:
220-winserver.com Wildcat! ESMTP Server v5.7.450.9b13 ready
220-************** WARNING: FOR AUTHORIZED USE ONLY! **********************
220-* THIS SYSTEM DO NOT AUTHORIZE THE USE OF ITS PROPRIETARY COMPUTERS *
220-* AND COMPUTER NETWORKS TO ACCEPT, TRANSMIT, OR DISTRIBUTE UNSOLICITED *
220-* BULK E-MAIL SENT FROM THE INTERNET. THIS SYSTEM WILL RESTRICT ACCESS *
220-* TO CAN-SPAM (US S. 877) COMPLIANT CLIENTS ONLY. *
220-************************************************************************
220 winserver.com Wildcat! ESMTP Server v5.7.450.9b13 ready
and this time it got pass this particular SMTP greeting/hostname test.
The question I have is what is the correct logic?
Where should the offical SMTP greeting line be in a multi-line greeting
display? Top or Bottom? Both maybe for compatibility? Unless I missed
it, RFC 2821 does not touch on this particular subject item.