On Sat, 16 Jun 2012, Steve Holme wrote:

> Reading the list of response codes you sent me though indicates that 251 and
> 551 may be returned. Given this I am reluctant to change the code to test
> against a specific error code - I don't believe it adds anything apart from
> a bit of clarity to a programmer who may be reading the code.
>
> Maybe some of the other curl developers could give their views on this and
> whether it is worth changing this if statement?

I'm not sure we have any golden rule or established behavior here. There's a
benefit in checking for exact return codes as closely as possible to what the
spec says, but that would then require that servers and other clients adhere
to the specs very closely. If they aren't, it is better to be more liberal so
that we catch most of the cases easier.

I used my experience from FTP when I wrote the initial SMTP code and in FTP
land the servers are not all agreeing what to return in all cases.

I'm certainly open for your input and experience here to guide us going
forward. I guess looking at what existing popular clients do is also a way to
figure out good practises.

>> That would be a viable option- if the VRFY command is supported by the
>> server that you are working with. Not all servers will support the command-
>> as it is considered a bit of a security risk- since it can give more
>> information about any given username on a server
>
> If this was implemented as a custom request then it would be the programmers
> responsibility to send a meaningful command and interpret the response. If
> you as the programmer did:

Hm, wasn't VRFY suggested as a way to overcome the problems with getting
errors back for unaccepted mail recepients? Then I don't really see the
reason. I would rather just have us record the status of all recepients that
libcurl tries to address and then allow that list of addresses with status to
be returned with curl_easy_getinfo().

(If the discussion was something else then I'm sorry I confused things and
I'll instead blame my age or something. ;-)

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html