WSO2 Identity Server extensively uses the AXIS2 transport MAILTO that allows sending out of emails, for instance to recover accounts, send one time passwords and so on.
Using the MAILTO transport is simple, just change the MAILTO Sender configuration in the AXIS2.XML file. What is needed to fill in are the regular SMTP settings like the following screenshot shows:
Figure 1 the mailto TransportSender from the AXIS2.XML file
These are of course dummy settings and should be replaced by your own settings. Also be reminded that when you want to receive messages, you need to uncomment the transportListener as well for the mailto transport. As you can see, naming is slightly confusing, the Transportlistener is also referenced as the transportReceiver. But when you search for ‘mailto’ you will send the both quickly.
When correctly configured Identity Server is able to send emails for various purposes as described above. However, there are possible snags that can stop mails being sent out.
Error messages (if any) are not always crystal clear so it is good to know what can cause errors.
Blocking of port 587
At one point we found that McAfee can block the 587 port for fear of misuse (it can be used by spambots), practically blocking sending out emails over that port. Since many organizations offer McAfee as part of the standard deployment (a necessity because of viruses, Trojans and other threats) in some cases individuals are not able to add an exception on the port (e.g. allowing Java to send messages).
Sign In Attempt
However, there are other reasons (apart from misconfiguring) that will throw an error when sending out an email. In a case I had recently, Google blocked the signin attempt because of the fact that ‘an app’ (WSO2 Identity Server) did not meet modern security standards. This resulted in an error in WSO2 Identity Server.
Figure 2 The error message thrown by Identity Server
The problem is in this case Google. As you can see from the mail I received, Google blocks attempts from environments it deems less secure. If you want, you can actually turn this off (unless you have 2 step verification turned on, in that case it is not possible). By doing so you will actually receive the email even though it app (in this case identity server) is considered less secure.
If you do not want to use a real email provider like gmail you can use a tool like DEVNull SMTP. This java program catches the email and basically does nothing with it (i.e. DEVNull). It is an ideal tool to test sending out emails in a development or training environment.
Figure 3 DevNull Smtp
You can download DevNullSmtp from this location. Since it is a .jar file, starting it goes as follows:
java -jar DevNullSmtp.jar
You set the port you want to use (in this case I’ve set it to 2500) and make changes to the AXIS2.xml file in order to point to DevNullSmtp on your local machine (or any other location you want to use.
What you need to change is the host entry in the mailto transport and turn off authentication. Below you see a sample setup for DevNull in conjunction with Identity Server.
If you have any questions about this blogpost contact us via the comments section of this blog. View also our WSO2 Tutorials, webinars or white papers for more technical information. Need support? We do deliver WSO2 Product Support, WSO2 Development Support, WSO2 Operational Support and WSO2 Training Programs.
|Working daily with WSO2 products we sometimes encounter things that even we did not know yet, but in fact are so handy we want to share it with the whole world. We have created a new group of articles called WSO-2-EASY that will show some of best tips and tricks that will help you to either save time or create tidier code.||