Environment specific mail auth and Seam’s MailSession

If you are using Seam’s MailSession to send out going e-mail from your Seam application you can run into trouble if you have a mail server in any environment (dev, test, stage, prod) that allows outgoing mail based on the client’s IP address and does not use username and password based authentication.

The standard configuration for the MailSession is in the components.xml file and looks like this (if you’ve used SeamGen to create your project):

	<mail:mail-session host="@mailhost@" port="@mailport@" username="@mailusername@" password="@mailpassword@" />

Then each of your environments has a components-{env}.properties file, which is deployed out and used to populate the @variable@ placeholders in the components.xml file. For instance your components.dev.properties file might look like this:

jndiPattern=YourApp/#{ejbName}/local
debug=true
mailhost=mail.mydomain.com
mailport=25
mailusername=mailus3r
mailpassword=mailp4ss

Which works great. However, if for instance your production environment uses IP based mail authentication for outbound e-mail, you might try to set your components-prod.properties file to look like this:

jndiPattern=YourApp/#{ejbName}/local
debug=false
mailhost=prodmail.mydomain.com
mailport=25
mailusername=
mailpassword=

However, that ends up setting empty strings into the username and password member variables of the MailSession component, and unfortunately the logic which determines whether or not to authenticate with the mail server checks for nulls only. So with empty strings, it attempts to authenticate with the mail server using a blank username and password. Which fails, and causes an unhelpful Faces error (unless you turn on debug on the MailSession component).

I’ve logged a Jira ticket about it here: JBSEAM-4176

You can do a simple workaround by overriding the MailSession component with your own sub-class of the MailSession class. In your sub-class you can override the setUsername and setPassword methods, check for empty strings and set null into the member variable if the parameter is null or empty. Luckily the Seam Install precedence system makes it very easy to override the default Seam component.

package com.myapp.mail;

import static org.jboss.seam.ScopeType.APPLICATION;

import org.jboss.seam.annotations.Install;
import org.jboss.seam.annotations.Name;
import org.jboss.seam.annotations.Scope;
import org.jboss.seam.annotations.intercept.BypassInterceptors;

/**
 * The Class MailSession. This is an overriding class designed to work around
 * https://jira.jboss.org/jira/browse/JBSEAM-4176
 */
@Name("org.jboss.seam.mail.mailSession")
@Install(precedence = org.jboss.seam.annotations.Install.APPLICATION, classDependencies = "javax.mail.Session")
@Scope(APPLICATION)
@BypassInterceptors
public class MailSession extends org.jboss.seam.mail.MailSession {

    @Override
    public void setPassword(String pPassword) {
	if (pPassword == null || pPassword.trim().length() == 0) {
	    super.setPassword(null);
	} else {
	    super.setPassword(pPassword);
	}
    }

    @Override
    public void setUsername(String pUsername) {
	if (pUsername == null || pUsername.trim().length() == 0) {
	    super.setUsername(null);
	} else {
	    super.setUsername(pUsername);
	}
    }

}

Please Stop Using Yahoo Mail

Yahoo mail servers have been consistently delaying or rejecting e-mails for over a year. You can read about it here:

http://www.ahfx.net/weblog.php?article=107

Or just Google for “4.16.50″.

The short of it is that even with a low volume personal mail server, with the correct spf records, without running an open relay, without being blacklisted by ANY blacklist site/service, Yahoo still won’t deliver e-mail from you. And they aren’t responsive about addressing the problem.

So please, if you use Yahoo mail, switch to GMail. You’ll like it more, and more importantly, you’ll actually get e-mail people are trying to send you.

How to cleanout your postfix queues by sender

This post is mostly to help me remember how to do this, if the situation arises again.

I just had a lot of mail backup on my server. The 10MinuteMail inbox was over 300 MB (usually it kept below a megabyte), Postfix’s active queue was maxed out at 20,003 entries (why the 3, I don’t know), and the incoming queue was another 20,000+. Basically everything was all backed up. I’m not 100% sure how this condition gets started. I’ve seen it a few times on my old server when super high volumes of incoming mail deliveries combined with other sites I hope serving up high bandwidth to end users. This is the first time it’s happened on the new server. It may be time to change out the domain that the 10MinuteMail e-mail addresses are using.

Regardless, using qshape I was able to identify a handful of from addresses (presumably either spammers or a cyclic bounce issue) which accounted for over 8,000 of the mail in the active queue. By using the following command I was able to purge out just those messages from the queue:

mailq|awk ' /^[0-9A-F][0-9A-F]*.*error.mag2.com$/ {print $1}'|tr -d '*'| xargs -rn1 postsuper -d

Where error.mag2.com is the domain, or from address you wish to delete. This works pretty well. I may whip up a bash script to handle this in the future.

For reference, the worst offenders are:

  1. magerr.combzmail.jp
  2. prjapanmail.jp
  3. error.mag2.com
  4. accessmail.jp
  5. mayld.net

Why so many from Japan? I have no idea….

What’s up with SMTPS?

Let’s start with SMTP. Simple Mail Transport Protocol. This is how e-mail gets sent. This is how e-mail makes it from you, to your recipient. When you check your e-mail, you use POP or IMAP to get the e-mail from the server. But when you’re sending e-mail, you use SMTP. SMTP is how your mail client communicates with your mail server, and then how your mail server communicates with other mail servers to deliver your precious e-mail to it’s destination.

SMTP has been around since 1982 and is used everywhere. It works, but it’s lacking in many ways, most of which are out of scope for this posting.

Basically the way it works is:

Continue reading

PGP E-mail Encryption conceptual issue

I have a number of thoughts in mind, which will likely turn into posts, and they are all leading up to a bigger unified thought. This is one of them.

PGP / GPG email encryption is a good thing. It’s a pretty secure system, and the public registries of public keys makes it easy to communicate securely with someone new, with a reasonable amount of trust. One major issue, which I think most people identify as the biggest issue with PGP, is that the popular mail programs don’t support it out of the box, or don’t support it well.

Continue reading