Alexander Falb created GERONIMO-6713:
----------------------------------------

             Summary: Mail with multiple recipients get sent multiple times
                 Key: GERONIMO-6713
                 URL: https://issues.apache.org/jira/browse/GERONIMO-6713
             Project: Geronimo
          Issue Type: Bug
      Security Level: public (Regular issues)
          Components: mail, specs
            Reporter: Alexander Falb


When sending a mail with javamail to multiple recipients, the mail is sent 
multiple times with only one recipient each.
h2. Steps to reproduce:

Setup a project with following dependencies:
{noformat}
org.apache.geronimo.specs:geronimo-javamail_1.4_spec:1.7.1
org.apache.geronimo.javamail:geronimo-javamail_1.4_mail:1.8.4
{noformat}
Call JavaMail:
{code:java}
Properties props = new Properties();
props.setProperty("mail.smtp.host", "localhost");
props.setProperty("mail.smtp.port", "1025");

Session session = Session.getInstance(props);
MimeMessage message = new MimeMessage(session);
message.setFrom(new InternetAddress("[email protected]"));
message.setRecipients(Message.RecipientType.TO, new InternetAddress[] {new 
InternetAddress("[email protected]"), new InternetAddress("[email protected]")});
message.setSubject("Test Subject");
message.setText("Some Mail Content");

Transport.send(message);
{code}
h2. Actual Result (SMTP log):
{noformat}
SMTP connection from 127.0.0.1/127.0.0.1, new connection count: 1
Server: 220 localhost.local ESMTP SubEthaSMTP null
Client: EHLO localhost
Server: 250-localhost.local
250-8BITMIME
250-AUTH LOGIN
250 Ok
Client: MAIL FROM: <[email protected]>
Server: 250 Ok
Client: RCPT TO: <[email protected]>
Server: 250 Ok
Client: DATA
Server: 354 End data with <CR><LF>.<CR><LF>
Server: 250 Ok
Client: QUIT
Server: 221 Bye
SMTP connection from 127.0.0.1/127.0.0.1, new connection count: 1
Server: 220 localhost.local ESMTP SubEthaSMTP null
Client: EHLO localhost
Server: 250-localhost.local
250-8BITMIME
250-AUTH LOGIN
250 Ok
Client: MAIL FROM: <[email protected]>
Server: 250 Ok
Client: RCPT TO: <[email protected]>
Server: 250 Ok
Client: DATA
Server: 354 End data with <CR><LF>.<CR><LF>
Server: 250 Ok
Client: QUIT
Server: 221 Bye
{noformat}
h2. Expected Result (SMTP log):
{noformat}
SMTP connection from 127.0.0.1/127.0.0.1, new connection count: 1
Server: 220 localhost.local ESMTP SubEthaSMTP null
Client: EHLO localhost.local
Server: 250-localhost.local
250-8BITMIME
250-AUTH LOGIN
250 Ok
Client: MAIL FROM:<[email protected]>
Server: 250 Ok
Client: RCPT TO:<[email protected]>
Server: 250 Ok
Client: RCPT TO:<[email protected]>
Server: 250 Ok
Client: DATA
Server: 354 End data with <CR><LF>.<CR><LF>
Server: 250 Ok
Client: QUIT
Server: 221 Bye
{noformat}
h2. Comments:

I use [https://github.com/Nilhcem/FakeSMTP] to record the SMTP log. 
Unfortunately the server strips the actual content of the message from the log. 
It would be between each "Server: 354 End data with <CR><LF>.<CR><LF>" and 
"Server: 250 Ok".

The expected result is produced with {{javax:javaee-api:7.0}} instead of the 
above mentioned {{org.apache.geronimo.*}} dependencies.

I'm not 100% familiar with the allowed SMTP command sequences, but I would 
suspect sending a message to 2 recipients should not result in sending the 
entire message body twice over the wire with only one recipient each?

I tracked the problem down to Transport#send(Message message, Address[] 
addresses). This method groups recipients by Transport. The problem is 2 
Transports are never the same, because Session#getTransport(..) uses internally 
Session#getSerivce(Provider provder, URLName name) which in turn instantiates a 
new Transport Object for each call. So the final Transport-to-Address Map looks 
like this: \{SMTPTransport->[[email protected]], SMTPTransport->[[email protected]]}
 javax:javaee-api:7.0 works around this, by grouping by an 
Transportidentifierstring "rfc822", which a map like this: \{"rfc822": 
[[email protected], [email protected]]}

I tried upgrading to the latest versions of {{org.apache.geronimo.*}} with no 
success.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to