On Wed, 21 May 2014, Tom Sparrow wrote:

> >Does your app work with the problematic server if you perform either
> > of the following:
> >
> >a) smtp://xxxx.yyyy.com/DUMMY_HOST
> >b) smtp://xxxx.yyyy.com/realhostname.example.com
>
> Yes.. App works fine with both of the above cases.

Cool.

> (Curl_gethostname is not getting called. *path in smtp_parse_url_path()
> is non-null - set to "DUMMY_HOST" for case a and
> "realhostname.example.com" for case b)

Sorry - I meant under normal circumstances when you don't specify the host
on the URL.

Regarding the patch... Is DUMMY_HOST a recognised domain for the EHLO and
HELO commands as I couldn't find it mentioned in either of the RFCs you
mentioned? Ie Can it be any valid set of characters that looks like a domain
or hostname?

My understanding is that the SMTP server can validate what you send it but,
as long as it looks like a domain then the server shouldn't reject it if
what is mentioned in RFC 1123 section 5.2.5 is correct. It can't, for
example, perform a reverse DNS look up, check if the IP address matches the
address that you're connecting from and then reject your connection because
they are different. It can however, then reject the email when you specify
the MAIL or RCPT commands or set SCL headers etc... etc..

Well... that's my interpretation - please feel free to correct me if I am
wrong.

You're log did flag up whether we are interpreting the failure code of the
EHLO command correctly before sending a HELO. Typically a server responds
with a 500 if a command is not known. In your log, the server responded with
a 501, so we then sent the HELO which also responded with a 501 and only at
that point did we fail. In this regard, I think we should only send the HELO
if the server responds with a 500.

Kind Regards

Steve

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-05-21