Is it possible to do? I know about custom request; so I send custom request with text "DELE", and set message ID that I want to delete. As a result, curl_easy_perform hangs until timeout appears. On web forums people write advice to send also "QUIT" command after "DELE"; but how can I send "QUIT" command if libcurl hangs?
libcurl debug output follows:
* Connected to pop-mail.outlook.com (157.55.1.215) port 995 (#2)
* SSL connection using DES-CBC3-SHA
* Server certificate:
* subject: C=US; ST=Washington; L=Redmond; O=Microsoft Corporation; CN=*.
hotmail.com
* start date: 2013-04-24 20:35:09 GMT
* expire date: 2016-04-24 20:35:09 GMT
* issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign Organization Validation
CA - G2
* SSL certificate verify result: unable to get local issuer certificate (
20), continuing anyway.
< +OK DUB0-POP132 POP3 server ready
> CAPA
< -ERR unrecognized command
> USER ************#hotmail.com
< +OK password required
> PASS ******************
< +OK mailbox has 1 messages
> DELE 1
< +OK message deleted
* Operation too slow. Less than 1000 bytes/sec transferred the last 10 seconds
> QUIT
* Operation too slow. Less than 1000 bytes/sec transferred the last 10 seconds
* Closing connection 2
So, the message is removed, but libcurl hangs until speed limit forces it to disconnect, which is bad idea. How to force it to stop after deleting of message and don't wait until timeout comes?
If you look at the libcurl documentation, CURLOPT_CUSTOMREQUEST says:
POP3
When you tell libcurl to use a custom request it will behave like a LIST or RETR command was sent where it expects data to be returned by the server. As such CURLOPT_NOBODY should be used when specifying commands such as DELE and NOOP for example.
That is why libcurl is hanging - it is waiting for more data that the server is not actually sending. So add CURLOPT_NOBODY to stop that waiting.
There's a recently added example code on the libcurl site showing exactly how to do this:
pop3-dele.c
Related
Using Boost v1.74:
int main()
{
auto ctx = boost::asio::io_context{};
auto socket = boost::asio::ip::tcp::socket{ctx};
auto ep = boost::asio::ip::tcp::endpoint{
boost::asio::ip::make_address_v4("192.168.0.52"),
80};
boost::asio::connect(socket, std::array{std::move(ep)});
std::cout << "Success!" << std::endl;
}
The IP address of my machine on my local network is 192.168.0.31/24, and so trying to connect to a non-existent address in the same subnet with the above code gives:
10:24:55: Starting /home/cmannett85/workspace/build-scratch-Desktop-Debug/scratch ...
terminate called after throwing an instance of 'boost::wrapexcept<boost::system::system_error>'
what(): connect: No route to host
10:24:59: The program has unexpectedly finished.
This is all expected. If I change the bottom octet of the subnet in the address (e.g. 192.168.1.52), then the app just waits for a few minutes - presumably because it sent messages to any routers to see if they own the requested subnet. There aren't any routers on my network, so it eventually times out:
10:27:39: Starting /home/cmannett85/workspace/build-scratch-Desktop-Debug/scratch ...
terminate called after throwing an instance of 'boost::wrapexcept<boost::system::system_error>'
what(): connect: Connection timed out
10:29:49: The program has unexpectedly finished.
Again, as expected. If I change the next octet (e.g. 192.167.0.52) instead, I would expect this to behave exactly the same as it is an equally unknown subnet as the previous. But it suceeds!
10:31:22: Starting /home/cmannett85/workspace/build-scratch-Desktop-Debug/scratch ...
Success!
This address is definitely not on my network:
$ ping 192.167.0.52
PING 192.167.0.52 (192.167.0.52) 56(84) bytes of data.
^C
--- 192.167.0.52 ping statistics ---
17 packets transmitted, 0 received, 100% packet loss, time 16368ms
So why is the code reporting that it is connected? And why is changing the second octet different to the third?
Any IP address of the form 192.168.xx.xx is a non-internet-routable network. This means no internet routers will route it. So the only way packets get routed off your subnet is if you configure a route on your own router or host. 192.167.xx.xx is an internet routable network, Presumable there is a host out there on the internet that uses the address you specified. So if you can connect your host to the internet, some internet router will get your packet to the address specified.
It's something related to my VPN. I didn't think it was relevant as the tunnel address is 10.17.0.60/16, but disabling it makes the above code work as expected.
Thanks to a suggestion by #dewaffled, Curl is showing that there is something on the otherside of this connection that is completing the TCP handshake, but after a timeout of a few minutes closes the connection.
$ curl -v http://192.167.0.52
* Trying 192.167.0.52:80...
* Connected to 192.167.0.52 (192.167.0.52) port 80 (#0)
> GET / HTTP/1.1
> Host: 192.167.0.52
> User-Agent: curl/7.74.0
> Accept: */*
>
* Recv failure: Connection reset by peer
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer
I know nothing about how VPNs work, but I suspect this is an implementation detail of my particular provider. Hopefully this 'answer' will limit confusion for anyone else!
I'm using https://curl.haxx.se/libcurl/c/http2-download.html to send mulitple http2 requests to a demo http server. This server is based on spring webflux. To verify if libcurl can send http2 requests concurrently, the server will delay 10 seconds before return response. In this way, I hope to observe that the server will receive multiple http2 requests at almost the same time over the same connection, after 10 seconds, the client will receive responses.
However,I noticed that the server received the requests sequentially. It seems that the client doesn't send the next request before geting the response of previous request.
Here is the log of server, the requests arrived every 10 seconds.
2021-05-07 17:14:57.514 INFO 31352 --- [ctor-http-nio-2] i.g.h.mongo.controller.PostController : Call get 609343a24b79c21c4431a2b1
2021-05-07 17:15:07.532 INFO 31352 --- [ctor-http-nio-2] i.g.h.mongo.controller.PostController : Call get 609343a24b79c21c4431a2b1
2021-05-07 17:15:17.541 INFO 31352 --- [ctor-http-nio-2] i.g.h.mongo.controller.PostController : Call get 609343a24b79c21c4431a2b1
Any guys can help figure out my mistakes? Thank you
For me,
curl -v --http2 --parallel --config urls.txt
did exactly what you need, where urls.txt was like
url = "localhost:8080/health"
url = "localhost:8080/health"
the result was that at first, curl sent first request via HTTP/1.1, received 101 upgrade to http/2, immediately sent the second request without waiting for response, and then received two times 200 response in succession.
Note: -v is added for verbosity to validate it works as expected. You don't need it other than for printing the underlying protocol conversation.
We are using openssl 1.0.2k for our TLS related functionalities.
In one of our deployment the client is able to complete the TLS handshakes using TLSv1.2 and was able to send application data towards server.After some requests the TLS connections closed from the server side with the below error
"error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number"
TLS handshake steps:
1. Client hello
2. Server Hello
3. Certificate,Certificate Request, Server hello done
4. Certificate,Client Key Exchange,Change Cipher spec,Encrypted handshake message
5. Change Cipher spec,Encrypted handshake message
6. Application data exchanges between client and server
7. Encrypted Alert(server to client)
8. Encrypted Alert( client to server
The error logs from server side says "error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number"
Can you please let us know the cause for this issue. If the ssl version is mismatching then the handshake phase should not succeed right?
But in our case handshake is successful and after some application data transfer our server is failing with this error.
If the ssl version is mismatching then the handshake phase should not succeed right?
No. Any TLS packet have header, and header has TLS version inside:
(
byte - record_type
byte[2] - version
byte[2] - length
) header
byte[length] - encrypted or raw data
Header is always in raw, it is never encrypted. Even if during handshake client sent TLS 1.2 version in all TLS packets, he can send another version after handshake is finished. Or someone in between can modify network traffic. In this case OpenSSL throws described error.
In my case, I was using OpenSSL for client functionality.
I was calling SSL_set_connect_state after SSL_connect. It should be called before.
SSL_set_connect_state (for client only) cleans up all the state!
snippet:
void SSL_set_connect_state(SSL *s)
{
s->server = 0;
s->shutdown = 0;
ossl_statem_clear(s);
s->handshake_func = s->method->ssl_connect;
clear_ciphers(s);
}
In my case:
1) Client <-> Server handshake succeeded.
2) SSL_write from client side (client sending message to server) lead to exact same error as mentioned in question (on server side)
I looked at pkt dump on server side.
read from 0x2651570 [0x2656c63] (5 bytes => 5 (0x5)) .
0000 - 16 03 01 01 e2 .....
ERROR
139688140752544:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong >version number:s3_pkt.c:337:
1) 5 Bytes read in the above snipped is the size of SSL record. Server received data, and it attempted reading SSL record.
2) 1'st byte of the record is the SSL record type In this case ===> x16 => '22'
This itself is wrong, as far as server is concerned, handshake was successful and it was expecting application data. Instead it received data with SSL record for handshake, hence it was throwing the error.
A correct snippet of application data is as follows: 'x17' ==> 23
read from 0x2664f80 [0x2656c63] (5 bytes => 5 (0x5)) .
0000 - 17 03 03 00 1c
Since SSL_set_connect_state was called after connecting, client state was lost and SSL_write will attempt handshake if handshake wasnt performed before (client thought so as its state was lost!)
More data on these SSL records can be found here:
https://www.ibm.com/support/knowledgecenter/SSB23S_1.1.0.12/gtps7/s5rcd.html
I am using zmq ROUTER and DEALER sockets in my application(C++).
One process is listening on zmq ROUTER socket for clients to connect (a Service).
Clients connect to this service using zmq DEALER socket. From the client I am doing synchronous (blocking) request to the service. To avoid the
infinite wait time for the response, I am setting RCVTIMEO on DEALER socket to let say 5 ms. After setting this timeout I observe un-expected
behaviour on the client.
Here are the details:
Case 1: No RCVTIMEO is set on DEALER (client) socket
In this case, let say client sends 1000 Request to the service. Out of these requests for around 850 requests, client receives responses within 5 ms.
For remaining 150 request it takes more than 5 ms for response to come.
Case 2: RCVTIMEO is set for 5 ms on DEALER (client) socket
In this case, for the first 150-200 request I see valid response received within RCVTIMEO period. For all remaining requests I see RCVTIMEO timeout happening, which is not expected. The requests in both the cases are same.
The expected behiour should be: for 850 requests we should receive valid response (as they are coming within RCVTIMEO). And for remaining 150
requests we should see a timeout happening.
For having the timeout feature, I tried zmq_poll() also instead of setting RCVTIMEO, but results are same. Most of the requests are getting TIMEDOUT.
I went through the zmq documentation for details, but didn't find anything.
Can someone please explain the reason for this behaviour ?
I have configured postfix to relay mail to Amazon SES by following their integration guide and sending email is working without issue.
However, I recently wrote a PHP application using a framework which produced a malformed email message.
SES rejects the email with "554 Transaction failed: Expected MIME type, got =" which is acceptable.
However, my local postfix server then attempts to send a sender non-delivery notification with a from=<> which gets pushed through to the relay address.
SES rejects stating "501 Invalid MAIL FROM address provided (in reply to MAIL FROM command))" and postfix removes the bounce message from the queue.
Question is, what is the easier way to ensure I get the original 554 bounce message sent to me? I don't see a way to make the SES relay accept empty from fields, so I believe the solution would lay in configuring postfix to deliver the bounce message directly to me.
Note, I use the term 'bounced mail' perhaps incorrectly. The mail is perhaps rejected but I'm not sure of the correct nomenclature for this scenario. The key point is that the message is not accepted by the SES relay, so it hasn't in fact gone 'out the door' so to speak.
Jun 12 03:11:21 myserver postfix/smtp[6353]: 411BA21795: to=<valid#validdomain.com>, relay=email-smtp.us-east-1.amazonaws.com[54.243.192.132]:25, delay=0.29, delays=0.05/0.02/0.15/0.07, dsn=5.0.0, status=bounced (host email-smtp.us-east-1.amazonaws.com[54.243 .192.132] said: 554 Transaction failed: Expected MIME type, got = (in reply to end of DATA command))
Jun 12 03:11:21 myserver postfix/cleanup[6351]: 93F202179B: message-id=
Jun 12 03:11:21 myserver postfix/qmgr[895]: 93F202179B: from=<>, size=4673, nrcpt=1 (queue active)
Jun 12 03:11:21 myserver postfix/bounce[6354]: 411BA21795: sender non-delivery notification: 93F202179B
Jun 12 03:11:21 myserver postfix/qmgr[895]: 411BA21795: removed
Jun 12 03:11:21 myserver postfix/smtp[6353]: 93F202179B: to=<valid#validdomain.com>, relay=email-smtp.us-east-1.amazona ws.com[23.21.161.144]:25, delay=0.17, delays=0.01/0/0.15/0, dsn=5.0.0, status=bounced (host email-smtp.us-east-1.amazonaws.com[23. 21.161.144] said: 501 Invalid MAIL FROM address provided (in reply to MAIL FROM command))
Jun 12 03:11:21 myserver postfix/qmgr[895]: 93F202179B: removed
If you just need to get the Postfix bounce messages delivered to your inbox just set the next bounce related configuration params (/etc/postfix/main.cf file for Ubuntu):
# The list of error classes that are reported
notify_classes = bounce, delay, policy, protocol, resource, software
# The recipient of postmaster bounce notifications
bounce_notice_recipient = bounceuser
# The recipient of postmaster notifications about mail delivery problems that
# are caused by policy, resource, software or protocol errors.
error_notice_recipient = bounceuser
# The recipient of postmaster notifications with the message headers of mail
# that cannot be delivered within $delay_warning_time time units
delay_notice_recipient = bounceuser
bounceuser is the recipient that will get bounce related messages. If you need to forward the message to non-local recipient just edit /etc/aliases to make postfix forward the message to you:
# /dev/null will just delete the message from local
bounceuser: /dev/null, <YOUR_EMAIL_ADDRESS_HERE>
Don't forget to recreate the alias database and restart the postfix service:
sudo newaliases
sudo service postfix restart
^_^
In order to received the bound message, you must set an envelope sender address which is delivered locally on your postfix installation.
Check
postconf mydestination
to see which domains are delivered locally.
Your application then needs to set the envelope sender address to a valid, locally delivered address. Something like root#name.of.your.machine
You can't convince postfix to fill out the MAIL FROM with anything other than <> because it is hardcoded.
What you can do is enable double-bounce notifications in main.cf:
# enable double bounce notifications (resource, software are the defaults)
notify_classes = 2bounce, resource, software
# Set the sender address for 2bounce
# #myhostname will be appended even if you have an # in the sender
double_bounce_sender = postmaster
# Set the recipient address for 2bounce
2bounce_notice_recipient = bounce.notify#company.com
# (and resource, software)
error_notice_recipient = bounce.notify#company.com
You'll end up with something like this.
PHP app (From: <your-app#company.com>) --> SES (To: <some-offiste#customer.com>)
: 5xx Rejected
Postfix (From: <>) -> SES (<your-app#company.com>)
: 501 Rejected Invalid MAIL FROM
Postfix (From: <postmaster#company.com>) -> SES (<bounce.notify#company.com>)
Whilst this strictly answers the question in that bounce messages will sort of be attempted via SES, it's worth noting that in the situation where e-mail one failed due to configuration problems, this is not necessarily more useful than setting bounce recipient to a local mailbox as suggested in the other answers - the 2bounce mail would be subject to the same configuration issues and would presumably also not be able to be sent.