I am building a mail client and I would like to know if my session is able to support all kind of smtp connections... although I don't really know what can I expect from there
I would like to confirm if the following is correct
1 - For SMTP I will only need the host:
props.put("mail.smtp.host", host);
Don't I need user and pass?
2 - For SMTPS I will need to set the tls or is it always true? What about ssl?
I'm a little bit noob about the mail protocols so I would really appreciate some help on this topics.
I would recommend spending some time with the JavaMail FAQ, which has more resources to help you get started.
To answer your immediate questions...
Whether you need a username and password or not depends on your mail server. Most public mail servers do. Some company-internal mail servers do not.
"smtps" is "smtp over an SSL connection". Officially, "TLS" is just the standard version of "SSL", but in this context when people refer to "TLS" they're usually referring to the "STARTTLS" command. The STARTTLS command allows you to make a plain text (non-SSL) connection, and then switch that connection to use SSL (TLS). You don't need this if you're using the "smtps" protocol since it makes an SSL connection to begin with.
Related
My web application is installed on many customer servers and the app needs to send emails via SMTP. Email smtp server is configured by the customer via a text (Properties) file.
I am having trouble deciding which settings should be included in the file. For some servers it is enough to let customer specify the following:
mail.smtp.host =
mail.smtp.auth =
mail.smtp.user =
mail.smtp.pass =
mail.from =
But which settings will cover vast majority of servers, so I have no worries that some setting will be missing?
An obvious approach would be to look at other mailers like Thunderbird or Outlook and see what configuration options they provide.
You definitely need an option that controls the use of SSL, which has three values:
Make a plain text connection
Make a plain text connection and then switch to an SSL connection using the STARTTLS command
Make an SSL connection to start with
These correspond to various settings of the mail.smtp.ssl.enable and mail.smtp.starttls.enable properties.
If you haven't already, you should look at all the properties described in the javadocs for the com.sun.mail.smtp package.
mail.smtp.auth should always be set to true.
That should get you started.
You may also want to let them specify the port.
Usually the following are used:
25 for SMTP
465 for SSL
587 for TLS
I am working on a site that will be using HTML5 sockets to communicate with other server. At that time our users will be logged in , I can't code on other server . I am using PHP at server side. I don't know whether other server has even PHP or not. Client says PKI is a solution. So if user login on our server then I start their communication with HTML5 sockets towards other server to send and receive data. So how can other server authenticate them? I also think that I can have a userkey (like 32hash format) that is sent with HTML5 socket while communication that other server validate and then start working with that user. So client says that hacker can see data over network so I think SSL can work for it. What you guys suggest in such scenario? Please advise
More details:
There will be connection made between our users and another server using apache thrift(will be using TCP), and scenario is that user will login to our site, then we will connect them via HTML5socket to apache thrift on different domain, so in HTML5socket communication we will be forwarding userid to tell thrift server that which user is this, so it is fine. But there are two problems,
As HTML5sockets are at client side then a hacker can create his/her own socket and connect to that server in same way and use some one's id as these are just simple integers.
If we will append some thing in data then a hacker sitting on the network can get it like some hackers do this for session hijacking.
So that's why I am not sure that whether using a sort of SSL or TLS will solve the problem or some PKI or some other digital certificate. So that's why I am asking that here.
thanks
SSL cannot solve this problem. SSL is about creating a secure link between the client and server, it does absolutely nothing to protect the server from a malicious client. SSL cannot solve the problem of SQL Injection or in your case Insecure Direct Object Reference relating to the user id. Judging by this SSL suggestion you probably have never heard of TamperData, which allows you to read/intercept and modify all HTTPS traffic generated by your browser (Including components like flash and JavaScript), BURP is more advanced but does the same thing.
The right way to do this is to have a shared session store that your collection of servers can access. The client is issued a very large random number or cryptographic nonce that it uses as a verification token, which is kind of like a session id. This verification token is used to look up session state in the data store. The communal session store could be as simple as a PHP page that accepts the verification token as a parameter and tells you if its linked to a valid session.
Having 3rd parties issue a callback to verify the session is really the "right way" to do this. It is possible to do this with cryptography, although it is a misuse of cryptography because it introduces the possibility of an attack, where as a callback is absolute. The PHP server can issue the JavaScript client an HMAC token consisting of the user id, a timestamp and the message authentication code. The tricky part is that both the PHP server and any 3rd party will have to share a secret in order to verify the message authentication code. If done properly you can transmit the client can transmit the token, and 3rd parties can verify that the session hasn't expired based on the timestamp and that your servers issued the token (instead of a hacker's forgery) based on the message authentication code.
I'm running a websocket server and asking myself, if it's planed, that clients authentication will be done with handshake in future... draft xxxx maybe :)
Do you have information? I have heard that with draft07 a session id can be sent to server, so maybe that can help to auth the client...
What I'm doing atm is to wait a maximum of 10 seconds, till the clients sends me a message with login header, username and password. But i think this is not "THE" solution. How do you guys out there doing it?
The WebSockets protocol permits standard HTTP authentication headers to be exchanged during the handshake. If you have a WebSockets server that plugs into an existing web server as a module then existing authentication in the web server should already work. Otherwise if you have a standalone WebSockets server then you may need to add the authentication support.
Update
As #Jon points out, unlike normal HTTP/XHR requests, the browser API does not allow you to set arbitrary "X-*" headers for WebSocket connections. The only header value that you can set is the protocol. This is unfortunate. One common solution is to use a ticket based system that relies on existing HTTP mechanism for authorization/authentication and then this ticket is passed along with the websocket connection and validated that way: https://devcenter.heroku.com/articles/websocket-security
I want to write both client and server sides of sending an e-mail also I should attend to the standard format of SMTP protocol which is specified in RFC 821.
Would you please help and guide me that how can I start it?
Why would you reinvent the wheel? There are many implementations for both sides that do a very good job and are well tested.
What feature do you miss in let's say Postfix (server) and Outlook (client)?
If you still want to start, ask yourself
how to create TCP Sockets and read/write to them
how to do connection and thread pooling
how to implement a state machine
what are you doing with related topics? (SPF, DKIM, mbox storage, Maildir storage)
what are you going to use for user authentication and authorization
(... enter hundreds of other things here ...)
I was wondering if anyone might be able to explain to me why it's taking nearly 30 seconds each time my Java web app sends an email using Gmail's SMTP server? See the following timestamps:
13/04/2010-22:24:27:281 DEBUG test.service.impl.SynchronousEmailService - Before sending mail.
13/04/2010-22:24:52:625 DEBUG test.service.impl.SynchronousEmailService - After sending mail.
I'm using spring's JavaMailSender class with the following settings:
email.host=smtp.gmail.com
email.username=myaccount#gmail.com
email.password=mypassword
email.port=465
mail.smtp.auth.required=true
Note that the mail is getting sent and I'm receiving it fine, there's just this delay which is resulting in a slow experience for the application user.
If you know how I can diagnose the problem myself that would be good too :)
It might be that gmail uses this delay to prevent spammers from using their SMTP server from the "outside": if the SMTP is called from the actual webmail client it would not use this delay.
In order to test this, you could open a telnet session to port 25 and do a manual SMTP session
(Search the web for SMTP HELO for examples)
GMail uses SSL for connection. To validate SSL certificate properly certain time is needed. Exact time depends on complexity of the certificate chain and use and accessibility of CRLs and OCSP checking. It's very likely that Java checks OCSPs for the certificate(s) presented, and this can be slow.
Try running your application on different system (preferably in other subnet) to exclude influence of firewalls. Maybe some part of communication (either SMTP itself, or CRL retrieval or OCSP checking) is slowed down by the firewall.
Depending on your OS, you should have a proper mail system that takes care of actually sending mails outside your network.
For instance, Postfix can do the job nicely. The configuration of Postfix would be on another thread, but typically Postfix would accept mails from your LAN (accepting to be a relay for your LAN) and would transfer the mails to gmail.
This is a exemple as to how setup postfix to have gmail as relay.
Having a mail service taking care of the relay of Gmail mails allows your Java application to be freed almost instantly (Postfix absorbs the mail, store it in its queue and forward it to Gmail itself).