Hi Dan,

> > Alternatively if Daniel does mind us adding new SMTP
> > specific error codes we could add
> > CURLE_SMTP_MAIL_ERROR and
> > CURLE_SMTP_RCPT_ERROR and change the data failed
> > to be CURLE_SEND_ERROR.
>
> Did we come to any sort of consensus about what the
> implementation should look like?

I think in the short term it would be better to return CURLE_SEND_ERROR - I
need to check out the test cases to see if this has a knock on effect on
them (will break them if I change it) but if there are no objections that I
can push a fix over the weekend (possibly).

> I'm not very familiar with the development cycle around
> here, but I'm looking at the part of smtp.c where this bug
> hails from. ( lines 1038- 1042) To me, it's either an efficient
> way to catch responses that are errors, or a broad net for a
> tiny fish, since the accepting response from a server is well
> defined (550 If I'm not mistaken).

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.

> If a consensus is reached, it should be a quick fix... but that's
> just inexperienced me talking. The issue then comes to
> determine invalid recipients- which could be done using a
> (sometimes supported) VRFY command to the mail server-
> the question becomes then how the invalid recipients are
> kept track of.

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. 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 ;-)

> A slightly off topic question about smtp: I haven't seen
> anything about UTF-8 Support through SMTP- is this
> already supported or something that would need to be
> added on?

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?

I hope this helps.

Kind Regards

Steve

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