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

Reply via email to