The tools in the java.util.concurrent package provide very convenient access to complicated structures that can save a lot of development time. The tools all come with a caveat though - their behaviour when accessed by multiple threads concurrently is deterministic, but not necessarily intuitive. In your code you use:
Lists.newArrayList(mailsToSend.iterator())
This converts the elements of the queue to a List... or, does it? What are the elements of the queue? By the definition of this class, the iterator is guaranteed to return all the elements in the queue at the time the iterator was created, but it may also, if it wants, return elements that were added after the iterator was created, and before it completes. Officially, it is weakly consistent:
they are guaranteed to traverse elements as they existed upon construction exactly once, and may (but are not guaranteed to) reflect any modifications subsequent to construction.
When I use tools in the concurrent library I prefer taking point-in-time copies of the data when I need it, unless I have a good reason not to. In your case, a point-in-time snapshot is what you want.
For this purpose, I prefer the toArray(...) call, which guarantees a copy of the data at the time it was called. Because you cannot tell what size the array will be, you should pas it an empty one in the constructor and it will return a bigger one if needed:
MimeMessage[] messages = mailsToSend.toArray(new MimeMessage[0]);
I would normally return this as a raw array - I like arrays. It also makes it clear that it is a defensive copy of the data.
If you want, though, you can wrap that array in a different format:
return Arrays.asList(messages);
or, even:
return Collections.unmodifiableList(Arrays.asList(mailsToSend.toArray(new MimeMessage[0])));
