> If you're referring to the "if(smtpcode/100 != 2)" then I would agree that
> it is a broad net to catch a small fish, however, it is more efficient to do
> this than have various if/else statements or a switch statement for the
> possible error codes that might come back from the server. At the end of the
> day, all the code is really interested at that point is whether the command
> was a success or a failure. If the response from the server is guaranteed to
> be 550 then we could do "if(smtpcode != 550)" but I'm not sure if that is
> the case / nor was Daniel when he originally wrote the function.
Since most of the code is broken down into the specific parts, wouldn't it be fairly predictable at this point- since SMTP server behavior has been well defined by now.

> Indeed - I'm not too familiar with the command so I would have to do a
> little bit of research to fully understand it's use. However, I believe we
> could either support VRFY automatically before a RCPT or as a one off
> command. To do the latter we would probably implement it through a custom
> request like what I did in the POP3 module - that way we could support EXPN
> and other commands as well. The programmer would then call perform with
> curl_easy_setopt(handle, CURLE_CUSTOM_REQUEST, "VRFY address") set. It would
> execute the command and return the result. The programmer could then verify
> the next address and so on, before deciding whether to perform a normal smtp
> send or not.
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- Steve, I sent you
an off list quick primer on this and server responses.

> If we were to do an auto send on the VRFY like some email
> clients do, I don't really see that being any different to just sending a
> RCPT and the server returning a 550 - additionally I don't think you would
> want to do this if you were sending in relay mode. But like I say, I don't
> fully understand the command to give a concrete answer at present :(
>
> However, if you want to have a bash at adding this yourself we would welcome
> your contribution otherwise I will add it to my to do list ;-)
Well, right now I'm working on some other aspects of the project I'm
developing right now. cURL is an integral part of what I'm doing overall
(under our current plan), so it might be possible to swing working on
it, but that's going to have to be approved by the powers that be.

As it is, I would enjoy specific errors, but that's a bit of a selfish
interest, as I'd love to only have to look to the return of the
curl_perform() call to determine which part of the interaction may have
gone awry- since there are distinct parts of the transaction with an
mail server. Is there some way to get more information about any given
error that happens? I would love to be able to provide some
functionality that actually tells my user more about what went wrong,
rather than "something went wrong" if the single smtp error path is chosen.

On the other topic:
> I'm not too sure I've fully understood your question... Do you mean
> automatic conversion of strings to utf8 or the ability to pass through
> strings in as utf8?
Well, I suppose that wasn't the most transparent question. Basically,
some servers will support transfer of UTF-8 encoded strings, and some
won't. I'm working on some code that ideally will be functional
worldwide and ideally across all character sets- so the ability to send
UTF-8 Strings would be the minimum- I can work out the external
conversion to UTF-8. So my question was about curl's abilities in the
area of sending UTF-8 strings, and I figured the experts would be able
to tell me- since I don't recall spotting very much about it on the API-
though there was something about converting from UTF-8 as a setopt option.

Thanks for your time!
~Dan

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-06-15