So I'm trying to utilize the smtp, mime, and tls packages for Tcl to be able to allow my program to send e-mails via external mail servers such as the gmail server (smtp.gmail.com) and yahoo server (smtp.mail.yahoo.com). I have an issue arising:
Sending email via the gmail server gives me the following error:
handshake failed: resource temporarily unavailable
while executing
"::tls::handshake $state(sd)"
I am using the smtp information found here: http://email.about.com/od/accessinggmail/f/Gmail_SMTP_Settings.htm
and my code looks like this:
tls::init -tls1 1;
set token [mime::initialize -canonical text/plain -string $body];
mime::setheader $token Subject "Test Email";
smtp::sendmessage $token -recipients "<my email address here>" -servers "smtp.gmail.com" -ports 587 -username "<my other email address here>" -password "<my password here>" -usetls true -debug 1;
mime::finalize $token;
Google automatically sent my gmail account an email saying:
We recently blocked a sign-in attempt to your Google Account <my email here>
And it gave me the option to change the security settings for "less secure apps" to allow my program to utilize the mail server. So I did, then my code worked just fine. What I don't understand is why gmail is blocking my attempts to send an e-mail; why it considers my attempt "less secure" thereby forcing me to lower the security settings on the e-mail account prior to sending emails from it. Perhaps my understanding is off, but I believe I'm using tls? And isn't tls more secure than ssl? Why does gmail have tls port if I can't connect to it anyway?
EDIT: Also I tried changing tls::init -tls1 1; to tls::init -ssl3 1; and using port 465 instead of 587, still to no avail.
When I try accessing the yahoo mail server (information retrieved from: http://www.serversmtp.com/en/smtp-yahoo), I get the following error:
premature end-of-file from server
while executing
"smtp::sendmessage $token -recipients "<my email here>" -servers "smtp.mail.yahoo.com" -ports 465 -username "my other email here" -password "<my password>" -usetls true -debug 1;..."
UPDATE
I learned that for yahoo, the account you want to use has to be a Yahoo Mail Plus account to let you do smtp mail sending.
Have you considered the possibility that this might not be a technical limitation so much as a policy one? Mail is very heavily locked down these days due to decades of abuse by spammers. There's probably some additional mail header that you'd have to set in order to send a cryptographic token based on some API key, which would allow direct access without that option being enabled. Just a little research leads me to this page, which says:
IMAP and SMTP use the standard Simple Authentication and Security Layer (SASL), via the native IMAP AUTHENTICATE and SMTP AUTH commands, to authenticate users. The SASL XOAUTH2 mechanism enables clients to provide OAuth 2.0 credentials for authentication. The SASL XOAUTH2 protocol documentation describes the SASL XOAUTH2 mechanism in great detail, and libraries and samples which have implemented the protocol are available.
Incoming connections to the IMAP server at imap.gmail.com:993 require SSL. The outgoing SMTP server, smtp.gmail.com, requires TLS. Use port 465, or port 587 if your client begins with plain text before issuing the STARTTLS command.
Now, though there is a SASL implementation in tcllib, and the smtp package uses it by default, there isn't an implementation of the XOAUTH2 mechanism in tcllib (which you can see by inspection of the code — look for ::SASL::register), making things fall back on older mechanisms that Google are less happy with. Fixing that would be outside the scope of this answer (but in general that's where “get coding” is suggested, or at least “file a feature request”).
I've not yet been able to nail down exactly what's required in the Yahoo Mail documentation; it seems harder for me to search…
Related
I want to strictly enforce TLS on all inbound/outbound emails from gmail (gsuite basic) for a particular organization/domain. I did read this article:
https://support.google.com/a/answer/2520500?hl=en
It asks to create an address list to setup inbound/outbound rule to enforce TLS. However I want to have TLS enforced irrespective of address and want to enable following behavior:
Outgoing mail: Mail won't be delivered and will bounce. You'll get a non-delivery report (NDR). Only one send attempt is made (no tries again).
Incoming mail: Mail is rejected without any notification to you, although the sender will receive an NDR.
Any suggestions on how this can be accomplished?
You can’t do that, in fact based in this article at point 6.:
https://support.google.com/a/answer/2520500?hl=en
“You must create a domain or address list to enforce TLS compliance for any inbound or outbound messages”
Gmail by default will use TLS, however, if the destination domain can’t establish TLS connection, Gmail will do an insecure connection. However, nowadays all domains are all by default establishing TLS connection and transmitting data over it. It’s rare you will find a domain that doesn’t support TLS connection.
Therefore, first of all, you should know which domains you usually contact that doesn't support TLS connection, and listed in the TLS compliance rules.
The idea of this policy is not making a long list of domains but only a few that customers already know that they don’t support TLS connection hence list them on the TLS.
There is a feature for a higher message encryption but is available for G Suite Enterprise edition: https://support.google.com/a/answer/6374496?hl=en
In fact what it may be a workaround is to Send and receive your email first to an external server that allows you to achieve this.
If this is the case you should Set up:
Set up an inbound mail gateway: https://support.google.com/a/answer/60730?hl=en
Set up an outbound mail gateway: https://support.google.com/a/answer/178333?hl=en
An consider a third party tool as : https://zix.com/products/email-encryption
I'm coding an SMTP Server here and wondering an issue which I don't know how to proceed.
You know that when you using Outlook, ThunderBird or any email client to send email, we need (the most of times) username and password to authenticate with the SMTP Server. In this case, SMTP Server requires an "AUTH LOGIN" before other commands such as MAIL, DATA...
I completed this stub in my project. But I'm wondering about a case, when another SMTP Client send directly to my SMTP Server. I mean our server is the final destination of the email. In this case, the authentication with AUTH LOGIN should not be required.
How can I organize my code for 2 cases above. How does the professional MTA such as Postfix, PowerMTA, Exim organize for these.
I hope you will help me
Most outgoing SMTP servers do one of the following:
1) Require SMTP Authentication
2) Alllow relaying without SMTP Authentication only from clients within a certain IP range
If you are doing neither of the above, then that means that your SMTP server is basically operating as an 'open relay', meaning that spammers can abuse your server to send outgoing spam mail.
Many ISP-hosted SMTP servers do #2 above, to allow their clients (and only their clients) to send mail through their SMTP server - as long as the client is on their network.
In emacs/wanderlust, if one selects the 'clear' method of password transmission, but enables SSL for IMAP, is the password transmission secured by SSL encryption? Specifically, concern arises from the following para in the wanderlust Info manual:
There are two ways to use SSL. One is to start SSL negotiation just
after the connection establishment (generic way). The other one is to
start SSL negotiation by invoking STARTTLS command in the each session.
So is password transmission done before or after SSL encryption in the first method? If before, then does the second (STARTTLS based) method ensure encrypted password transmission?
The password is secure in either case.
The difference between these methods is in another aspect: The first method starts a TLS connection right after the TCP handshake, and before any IMAP exchange starts. Hence, it uses a different port than regular IMAP, but can be used with IMAP servers that do not have built-in TLS support, by simply tunneling their traffic.
With the second method however, the client connects to the regular IMAP port and starts an unencrypted IMAP exchange. However, before sending any credentials or any other private data it tells the server to upgrade the connection to a TLS connection, and only resumes the IMAP exchange (including password transfer) after this upgrade succeeded. This method allows to serve encrypted IMAP from the default IMAP port, but needs an IMAP server that can handle this IMAP protocol extension.
Nowadays, most servers support STARTTLS, so both methods are mostly equivalent. Use whatever Wanderlust uses as default.
I'm using mod_auth_basic to restrict access to an SSL folder, is the password transmitted as cleartext?
Do I need to use mod_auth_digest?
Depends on what you mean by "as cleartext". In the HTTP basic authentication exchange, passwords are sent as cleartext (encoded as base64). But the whole exchange is tunneled through the encrypted SSL connection, so you can't see them by observing the traffic. (Unless you've successfully compromised the SSL connection itself and can see all the traffic.) When doing basic auth through HTTPS/SSL, the server at the other end can still see your passwords as cleartext, but it's sufficient to protect against man-in-the-middle eavesdropping.
I'm using mod_auth_basic to restrict access to an SSL folder, is the password transmitted as cleartext?
Yes. Its transmitted in the clear within the SSL/TLS tunnel.
Do I need to use mod_auth_digest?
That's usually a problem, too.
The problem is that anyone that answers with a certificate is accepted. More correctly, the tunnel lacks "channel binding", where app authentication is part of the channel setup. So if someone intercepts the communication (i.e., proxy) or impersonates the up the server (phishing), then you send him/her password or MD5(password).
Its better to use a SSL/TLS protocol like TLS-SRP or TLS-PSK. Each use shared secrets like passwords, and each properly bind the channel. And both don't do dumb things like put the password on the wire in the plain text.
You can read more about these problems and solutions in Peter Gutmann's Enginerring Security.
This is our setup - our customers will have a database server with our database on and multiple clients running our frontend. We have some WCF services to allow the clients to request info from the database and each WCF session is authenticated with a username/password stored (encrypted) in the database. This all works fine and has been in use for a couple of years.
We're now adding the ability to sign in using a USB fingerprint reader attached to client PCs. For this we store each users' fingerprint template in the database and then upload them all to the device. The device can then tell us which user has presented their finger.
What is the best way to securely allow our fingerprint client to authenticate over the WCF service without using the user's password and without opening up the system to attack from unauthorised users?
My first thought is to define a secret key that both client and server know, encrypt it on the client with a timestamp and the logged in user id and send it to the server which can then confirm that the request came from our client.
Is this a good idea? Can an attacker just relay the same message to start an unauthorised session?
I'm not a security expert so I'd prefer an existing solution over rolling my own for obvious reasons.
We're using C# and only targetting Windows.
You could use an x509 certificate stored on the Client to provide the client credentials required for the WCF service. This would work in the same way that server security is provided via SSL certificates.
Some info on working with certificates:
MSDN - Message Security with a Certificate Client
MSDN - Working With Certificates
A word of caution would be that you would obviously have to manage the distribution and validity of certificates.
Th other alternative is to use the clients windows account for authentication purposes if the client machine is on the same domain:
Some info on working with Windows Account:
Message Security with a Windows Client