At 09:57 15-06-2012, Dan wrote:
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?
That would require a mail server which supports EAI.
Regards,
-sm
Hi again
On Fri, 15 Jun 2012, Steve Holme wrote:
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
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
Dan wrote:
Did we come to any sort of consensus about what the implementation should
look like?
I must apologize for my lack of activity on this thread. I've simply been
hammered by work and domestic issues and will be for some time yet to come.
I have been trying to follow it though and
On 6/8/2012 4:57 PM, Steve Holme wrote:
Hiya,
On Fri, 8 Jun 2012, Daniel Stenberg wrote:
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
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
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
Hi Dan,
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
Alright ya'll. I may have found another issue, but maybe it's just me.
Arising from the loop idea that was brought up as a temporary workaround-
if curl_slist_free_all is called and I loop around and add a recipient
to the same slist I just free all'ed, it creates an infinitely linked
list- so
Hi Dan,
Alright ya'll. I may have found another issue, but maybe it's
just me. Arising from the loop idea that was brought up as a
temporary workaround- if curl_slist_free_all is called and I
loop around and add a recipient to the same slist I just free
all'ed, it creates an infinitely
On Fri, 8 Jun 2012, Dan wrote:
Alright ya'll. I may have found another issue, but maybe it's just me.
Arising from the loop idea that was brought up as a temporary workaround- if
curl_slist_free_all is called and I loop around and add a recipient to the
same slist I just free all'ed, it
On Fri, 8 Jun 2012, Steve Holme wrote:
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.
Do we really need to separate MAIL errors from RCPT ones like that?
Hiya,
On Fri, 8 Jun 2012, Daniel Stenberg wrote:
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.
Do we really need to separate MAIL errors from RCPT
William Betts wrote:
HI Steve,
If libcurl will ditch the entire message because of a failed RCPT TO command
it should be listed as a bug. If the SMTP session has at least 1 valid
recipient the transaction should finish. I'll check it out in a bit and see
if that's the case on my end.
Best
On 6/7/2012 9:21 AM, Rich Gray wrote:
William Betts wrote:
It seems to me that without a mechanism provide the caller with
information about WHICH address(es) failed, it is appropriate to give
up on any failure and abort the transaction.
I've been tossing that around, and though it makes sense
HI Dan,
Another alternate (simple and rather crude) solution might be
to mimic mail servers in that curl could do bookkeeping of
the unsent addresses and send an undeliverable mail
email to the return address (if it isn't ) for the unsent
addresses.
That's kind of the problem I have when
Hi again,
On Thu, 7 Jun 2012, Steve Holme wrote:
The other thing you could do is to loop round in your
code calling libcurl, sending the same email (except
for a line or two of header information) with one
address at a time rather than putting all recipients in
the recipient list.
If you
On Thu, 7 Jun 2012, Steve Holme wrote:
If you do decide to do this, I would also recommend you first connect to
your mail server with CURLOPT_CONNECT_ONLY in the first curl_easy_perform(),
then do each of the send mails in their own curl_easy_peform()'s. That way
you only connect and log into
Hi,
No need for CURLOPT_CONNECT_ONLY to achieve that. If only
the easy handle is re-used for subsequent requests, the
connection will be kept open and get re-used!
Ta for the tip Daniel - Odd... I wonder why I wrote my code like that then
:-/
... Extra steps for the sake of it ;-)
S.
On Thu, Jun 7, 2012 at 9:00 AM, Steve Holme steve_ho...@hotmail.com wrote:
HI Dan,
Another alternate (simple and rather crude) solution might be
to mimic mail servers in that curl could do bookkeeping of
the unsent addresses and send an undeliverable mail
email to the return address (if it
Hello all,
I've been working with cURL for about 2 weeks and I've been scouring the
web looking for the solution to my problem to no avail- I'm sorry if I
missed the answer somewhere along the way.
My problem arises when there are multiple recipients of an email and one of
the recipients is
Hi Dan,
I've been working with cURL for about 2 weeks and I've been scouring
the web looking for the solution to my problem to no avail- I'm sorry
if I missed the answer somewhere along the way.
Welcome to curl and libcurl ;-)
My problem arises when there are multiple recipients of an
On Wed, Jun 6, 2012 at 12:07 PM, Steve Holme steve_ho...@hotmail.comwrote:
Hi Dan,
I've been working with cURL for about 2 weeks and I've been scouring
the web looking for the solution to my problem to no avail- I'm sorry
if I missed the answer somewhere along the way.
Welcome to curl
Below are is the output from setting CURLOPT_VERBOSE, true. It does
appear that it will kill the entire SMTP session if there is 1 invalid
recipient. We really should look into fixing this, because imho it's a
pretty bad bug. Steve would you like me to take a look at this and
attempt to fix it?
Hiya William,
I'm kind of guessing what the problem might be at the
moment as it largely depends what your mail server
returns in response the MAil RCPT command.
If libcurl will ditch the entire message because of a
failed RCPT TO command it should be listed as a bug
If the SMTP session
On Wed, Jun 6, 2012 at 1:39 PM, Steve Holme steve_ho...@hotmail.com wrote:
Hiya William,
I'm kind of guessing what the problem might be at the
moment as it largely depends what your mail server
returns in response the MAil RCPT command.
If libcurl will ditch the entire message because of
Hi again,
Below are is the output from setting CURLOPT_VERBOSE, true. It
does appear that it will kill the entire SMTP session if there is 1
invalid recipient. We really should look into fixing this, because
imho it's a pretty bad bug. Steve would you like me to take a
look at this and
On Wed, 6 Jun 2012, Steve Holme wrote:
* What CURLE error code are we going to return if one or more recipients
fail?
We probably need to expose that information somehow. Possibly something for
curl_easy_getinfo() or so. An application can figure it out by using
CURLOPT_DENUGFUNCTION but it
28 matches
Mail list logo
