3

I am not sure what's going on here, I configured claws mail using a video tutorial i saw online, I decided to send a test message to myself after configuring and I got an error message saying I should use the queue option to send, I right clicked on queue and clicked sent and then I got an error message

account '****@openmailbox.org@pop.openmailbox.org' connecting to smtp server:smtp.openmailbox.org.... ssl handshake failed , error occurred while sending the message

I did everything the right way but for some strange reason it just wouldn't work. I would really appreciate some help here. Thanks

Jens Kubieziel
  • 8,630
  • 5
  • 35
  • 116
SteveO
  • 31
  • 2

4 Answers4

1

Although your question lacks a lot of details, the only problem I can spot is that your SSL error comes from an attempt to do STARTTLS over plain SMTP rather than using SMTPS from the very beginning. You can also be a victim of a filtering exit node, then try to change it. Also - it is required to use an explicitly specified security and login schemas always, i.e. set an auth metod as LOGIN, outgoing server with authentication type LOGI explicitly required and via SMTPS(tcp:465)

Alexey Vesnin
  • 6,385
  • 3
  • 15
  • 36
0

If you are using tails/tor then, effectively, you are already using a VPN and automatically bypassing any port blocking from your ISP. Please note that typically when people talk about "port blocking" they are referring to whether or not the connection allows incoming traffic to be initiated on that port (ie for a server); For example, if your ISP has blocked port 80 then that means you can't RUN a web server on port 80, but it doesn't mean that you can't CONNECT as a client to a web server running on port 80. This is what canyouseeme.org is checking and most likely does not relate to your problem.

That being said, when using Tor (as a VPN/tunnel), exit nodes have the ability to do basically anything that your ISP would be able to do if you weren't using tails/tor and it is standard practice for Tor exit nodes to reject/block outgoing traffic on certain ports. Due to the severe spam problem that plagues the design of email, it is very likely that this is your problem: not your ISP, but the ISP of the Tor exit node and/or the Tor exit node itself that is blocking outgoing traffic on SMTP ports.

This is why we created onionmail because ISPs make it extremely troublesome for Tor nodes to connect to email servers. We need hidden email servers to stop the harassment and make it work. Then we only have the problem between email servers (described above) which isn't too bad and only affects email servers that depend on the broken CA model for pub-key infrastructure (instead of .onion address system which fixes this problem among others).

http://en.onionmail.info

http://en.louhlbgyupgktsw7.onion

user9745
  • 1
0

I had the same issues with openmailbox.org. When I changed the SMTP Auth from AUTOMATIC to LOGIN it worked.

user9778
  • 11
  • 1
-1

We have been experiencing a similar issue sporadically when trying to send email to accounts on smtp servers at gmail.com, ruggedinbox.com, and riseup.net from the smtp server at onionmail.info

We don't believe it is an issue with client configuration or a claws bug. We believe it is a structural issue that arises from poor interaction between the CA model of public-key infrastructure and the asynchronous nature of email. You see, unlike the world wide web, email protocols do not require both servers to be online at the same time. Emails can be stored and forwarded by intermediate servers and, as a result, most email servers have not traditionally enforced any kind of encryption to other servers (since they may have to trust a man-in-the-middle server anyway). Fast forward 20 years and, now that most of the email servers people use are online 24-7 so that end-to-end encryption can almost always be used between servers, many email servers seem to being playing games with their DNS records and public-keys as an anti-spam measure.

Now, in the face of mass surveillence, consciencious administrators are setting up their smtp servers to require encryption instead of defaulting to plain text, but this means that they're having connection failures when trying to connect to traditionally configured servers and/or servers playing anti-spam games with the public-key infrastructure (or also, possibly, servers experiencing real man-in-the-middle attacks on their encrypted connections).

https://stackoverflow.com/questions/13437484/why-dont-googles-mx-servers-match-the-ssl-certificate-cn

If we are wrong and it is a client configuration problem or a claws bug then, please, fix our code: http://en.onionmail.info

http://en.louhlbgyupgktsw7.onion

user9712
  • 1