greenmail-mail-test / greenmail Goto Github PK

Currently the search command only supports search on flags. We also want search on other header fields

Suggestion : pull request for every contribution. Every request is merged by a member of the team that did not create it (peer review)

Due to a missing class (sun.security.ssl.SSLSocketImpl) I am unable to build GreenMail Core using Oracle JDK 6.

This class only exists in OpenJDK installations. I understand why the SSLSocketImpl class is being used (e.g. to avoid slow reverse DNS lookups) but this change prevents Oracle JDK/JRE users from using/building this library.

We're using GreenMail as a test server for our QA/Staging. For our purposes, what would be ideal is GreenMail would just accept any credentials as valid. It would just completely ignore the password and if the username did not exist, would just return an empty mailbox.

We need to be able to test arbitrary mailboxes as part of a workflow system, so for us just always accepting credentials as being valid would be ideal.

Given @camann9 comments in PR #9 I thought it would be a good idea to have a code contribution guideline.

These should detail:

• Code line policy (branching etc)
• Code style policy
• Testing policy

I saw you guys closed a bug for licensing confusion. Is GreenMailUser.java covered in the license as well? Or Do I need permission.

There should be a deployable version of Greenmail

The Javadocs link at http://www.icegreen.com/greenmail/ and the link in the README.md of this repo point at http://www.icegreen.com/greenmail/javadocs/index.html, which is currently returning a 404.

+Get rid of Sonar violations

The README.md file has a typo in the upstream config.

just got an email from a user:

One minor issue I would like to mention in case you are not yet aware of it. The message body in multipart messages does not properly work with encodings other than us-ascii. I see 'us-ascii' hardcoded at various locations. First I tried rewriting getWholeMessage, but it did not solve my issue with utf8 chars. I presume this is not the only point where the encoding gets broken.

public static String getWholeMessage(Part msg) {
try {
ByteArrayOutputStream bodyOut = new ByteArrayOutputStream();
msg.writeTo(bodyOut);
return bodyOut.toString("US-ASCII").trim();
} catch (Exception e) {
throw new RuntimeException(e);
}
}

Regards

Marc

Looks like the sar is the wrong format for jboss 7. In the documentation it should list which versions of jboss it supports.

It looks like the old XMBeans support was dropped.

I get the following error

10:08:34,896 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.deployment.unit."greenmail-jboss-service-1.4.0.sar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."greenmail-jboss-service-1.4.0.sar".PARSE: JBAS018733: Failed to process phase PARSE of deployment "greenmail-jboss-service-1.4.0.sar"
    at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:123) [jboss-as-server-7.1.3.Final.jar:7.1.3.Final]
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_76]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_76]
    at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_76]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS017224: Failed to parse service xml ["/C:/devtools/jboss/jboss-as-7.1.3.Final/bin/content/greenmail-jboss-service-1.4.0.sar/META-INF/jboss-service.xml"]
    at org.jboss.as.service.ServiceDeploymentParsingProcessor.deploy(ServiceDeploymentParsingProcessor.java:102)
    at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116) [jboss-as-server-7.1.3.Final.jar:7.1.3.Final]
    ... 5 more
Caused by: com.ctc.wstx.exc.WstxParsingException: Received event DTD, instead of START_ELEMENT or END_ELEMENT.
 at [row,col {unknown-source}]: [3,16]
    at com.ctc.wstx.sr.StreamScanner.constructWfcException(StreamScanner.java:606)
    at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:479)
    at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:464)
    at com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1143)
    at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:67)
    at org.jboss.as.service.ServiceDeploymentParsingProcessor.deploy(ServiceDeploymentParsingProcessor.java:95)
    ... 6 more

Two issues encountered when using java mail + IMAP protocol:

1. Received date using Message.getReceivedDate() is wrong, for me it is behind by 12 hrs. Example: Received date Thu Oct 30 06:37:14 PDT 2014, Sent date Thu Oct 30 18:37:14 PDT 2014
2. When subject is Subject?<>/|\\.%\"*?:, Message.getSubject() causes the following exception: javax.mail.MessagingException: Failed to load IMAP envelope

Hopefully both can be verified with the following modification to ImapServerTest.testImapsReceive().

@Test
public void testImapsReceive() throws Throwable {
    assertNotNull(greenMail.getImaps());
    final String subject = "Subject?<>/|\\.%\"*?:";
    final String body = GreenMailUtil.random();
    String to = "test@localhost";
    GreenMailUtil.sendTextEmailSecureTest(to, "from@localhost", subject, body);
    greenMail.waitForIncomingEmail(5000, 1);

    Retriever retriever = new Retriever(greenMail.getImaps());
    Message[] messages = retriever.getMessages(to);
    assertEquals(1, messages.length);
    assertTrue(messages[0].getReceivedDate().after(messages[0].getSentDate())); // Issue 1
    assertEquals(subject, messages[0].getSubject()); // Issue 2
    assertEquals(body, ((String) messages[0].getContent()).trim());
}

Thanks!

Greenmail was written with JavaMail as the primary client. Nonetheless it would be nice if users would be able to connect to Greenmail using a mail client of their choice. We should check/improve support for major mail clients:

• Thunderbird
• Outlook
• Apple mail

UserManager.getUserByEmail incorrectly uses UserManager.getUser (which retrieves by logon, not by email).

SmtpManager#enqueue: Receivers are added to the list of receivers again even if they are already in it. This leads to duplicate receiver addresses.

http://stackoverflow.com/questions/21471726/squirrelmail-with-greenmail-error-bad-or-malformed-request

The greenmail-core/src/test/java/com/icegreen/greenmail/test/commands/SMTPCommandTest.java uses raw sockets to test mail commands against GreenMail's SMTP server.

We should use JavaMail's SMTPTransport.sendCommand() instead as this is cleaner than using raw sockets.

Given that GreenMail is a Java project and it wants to continue support for Oracle Java 1.6 I suggest we migrate GreenMail's CI from TravisCI to BuildHive by CloudBees.

Search for an API that allows test mail creation in an easy way or create one. Example:

mail().withHtml("<html></html>").withText("test").withAttachment("file.txt", "test")

There should be a way to describe events (e.g. reception of an email from an unknown user) and actions that happen when the condition is fulfilled. Example:

when(mailReceived()
  .to(".*@test.com")).createUser("${mail.to}");

Using rules we could get rid of some of the special logic like automatic user creation for SMTP. It could also be used to simulate faults:

when(mailReceived()
  .withAttachmentLargerThan(10000)).abortWithError("too large");

This is related to #39

When running an email simulator based on GreenMail for too long (or rather when it has received too many messages), it will invariably die with an OutOfMemoryError. Is it possible to change e.g. the ImapHostManagerImpl to only store a maximum number of messages and when it's supposed to receive more, it will purge its oldest entry?

Unit tests in my Spring Intengration project are failing (using Greenmail 1.4.0) due to the fact that SearchKey.NOT is unimplemented =/

08:32:46.308 [task-scheduler-1] INFO o.s.i.mail.ImapMailReceiver - attempting to receive mail from folder [INBOX]
08:33:06.381 [Thread-6] ERROR c.i.greenmail.imap.ImapHandler - Can not handle IMAP connection
java.lang.IllegalArgumentException: No enum constant com.icegreen.greenmail.imap.commands.SearchKey.NOT
at java.lang.Enum.valueOf(Enum.java:238) ~[na:1.8.0_20]
at com.icegreen.greenmail.imap.commands.SearchKey.valueOf(SearchKey.java:92) ~[greenmail-1.4.0.jar:na]
at com.icegreen.greenmail.imap.commands.SearchTermBuilder.create(SearchTermBuilder.java:22) ~[greenmail-1.4.0.jar:na]
at com.icegreen.greenmail.imap.commands.SearchCommand$SearchCommandParser.searchTerm(SearchCommand.java:112) ~[greenmail-1.4.0.jar:na]
at com.icegreen.greenmail.imap.commands.SearchCommand.doProcess(SearchCommand.java:48) ~[greenmail-1.4.0.jar:na]
at com.icegreen.greenmail.imap.commands.SearchCommand.doProcess(SearchCommand.java:39) ~[greenmail-1.4.0.jar:na]
at com.icegreen.greenmail.imap.commands.CommandTemplate.process(CommandTemplate.java:48) ~[greenmail-1.4.0.jar:na]
at com.icegreen.greenmail.imap.ImapRequestHandler.doProcessRequest(ImapRequestHandler.java:98) ~[greenmail-1.4.0.jar:na]
at com.icegreen.greenmail.imap.ImapRequestHandler.handleRequest(ImapRequestHandler.java:51) ~[greenmail-1.4.0.jar:na]
at com.icegreen.greenmail.imap.ImapHandler.run(ImapHandler.java:94) ~[greenmail-1.4.0.jar:na]
at com.icegreen.greenmail.server.AbstractServer$1.run(AbstractServer.java:101) [greenmail-1.4.0.jar:na]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_20]

Most SMTP implementations by default will deny an inbound email addressed to a user on the local domain (or within the relay path) if the user's mailbox does not exist.

GreenMail accepts an incoming email and returns a status code of 250 to the mail client even if the user does not exist on a local mailbox. The status code of 250 in this case is a red-herring especially when code is written to fetch/retrieve the email.

One could argue that this is to expected with an in memory solution but GreenMail should at least log a warning (INFO level) letting a developer know that this happening. Documentation should also be updated accordingly.

The website is being rewritten based on Bootstrap. First prototype ready.

GreenMail unit tests are currently using JUnit 3.x style tests. Update the JUnit dependency and all unit tests accordingly. This will give us some additional flexibility in test method names and the ability to use Hamcrest if needed.

I think we should consider using Gitter as a communication tool for the team and as an area where we can provide some "minimal" support for GreenMail - in case anyone has questions about it.

(migrated from http://sourceforge.net/p/greenmail/bugs/7/)

If I send a test email to GreenMail, containing a Message-ID containing a quoted address, e.g.

<11111.22222.3333.JavaMail."FOO\BAR"@HOSTNAME>

and then I retrieve it from GreenMail's IMAP server, JavaMail's ENVELOPE class, which is reading the response, throws

javax.mail.MessagingException: Failed to load IMAP Envelope
JavaMail generated the legal quoted Message-ID when calling MimeMessage.saveChanges() prior to sending it.

The IMAP RFC3501 (section 9) says that the envelope's message-id will either be a quoted string, or a literal surround by braces.

GreenMail is correctly quoting around the entire Message-ID. But in doing so, all quotes inside the Message-ID must be escaped prior to sending the response.

Since these quotes are not escaped in GreenMail's envelope response data, the JavaMail reading code (ENVELOPE.java) rejects the invalid response.

FetchCommand:224: Should be len = Math.min(len, bytes.length-start); Otherwise message size is limited to 16kb with the default settings of JavaMail

The change I made in pull request #14 should really live under the EscapingTest class. I'll relocate it and the GreenMailMimeMessage inner class to that package.

Can we create a package called com.icegreen.greenmail.test.utils for test utility classes like GreenMailMimeMessage? I'd rather do that than pollute the test classes with inner classes.

There are various forks of greenmail on Github. We should look at the improvements they contain and merge them into our repo (after asking :-P).

The GreenMail website should be updated with the GitHub project link to prevent users from submitting issues/bugs on Sourceforge.

Wondering how often GreenMail is released and pushed to Maven Central. I'd like to use the changes I made in PR #14

I guess I can maintain my own fork temporarily but I'd rather get an official release from the project.

The current .gitignore file only filters a set of basic filetypes and directories. It should be updated to remove files generated by common IDE's like NetBeans, Eclipse, IntelliJ etc. Additionally it should ignore any OS generated like OS X .DS_STORE

(Migrated from http://sourceforge.net/p/greenmail/bugs/8/)

The included license.txt file says that GreenMail is licensed under the Apache License 2.0, but copyright notices in every file (including those forked from Apache James) claim LGPL licensing, which is more restrictive than Apache 2.0. Could you clarify which license the project is meant to be licensed under and remove the conflicting information?

(migrated from http://sourceforge.net/p/greenmail/bugs/6/)

My application reads a POP3 mailbox and resends the messages it reads after processing. When this fails, it needs to generate and send a bounce message. GreenMail cannot receive these bounce messages, as it doesn't recognize <> as MAIL FROM: argument.

Example SMTP session:

220 BOLNL-W7453/10.10.132.14 GreenMail SMTP Service Ready
EHLO BOLNL-W7453.local.nl.bol.com
250 BOLNL-W7453/10.10.132.14
MAIL FROM:<>
501 Malformed email address. Use form email@host

Alfresco patched GreenMail for various issues.

Evaluate and reintegrate the patch patch.

Add possibility to do server side processing using Sieve (see http://tools.ietf.org/html/rfc5228 ) . This conflicts/augments to a certain degree #40

We just set up GreenMail to do some testing and we delete messages by their UID. Unfortunately, when pulling messages from POP3, the messages contain an empty UID.

Any chance of getting this changed?

Create asserts that check mail reception. Could be similar to Wiremock.

verify(mailReceived()
    .to("[email protected]")
    .from("[email protected]")
    .withHeader("Message-ID", matching(".*@MYSERVER")));

Implement UIDFolder interface for ImapSessionFolder.

See JavaMail UIDFolder for details.

(migrated from https://sourceforge.net/p/greenmail/bugs/1/)

Hi
The expunge method doesn't work when there are multiple deleted mail (deletes every second mail).
This is because the loop checks the list size, but the loops body changes the list.

Something like this:

public void expunge() throws FolderException {
    // get size outside of the loop
    int size = mailMessages.size()
    for (int i = 0; i < size; i++) {
        SimpleStoredMessage message = (SimpleStoredMessage) mailMessages.get(i);
            if (message.getFlags().contains(Flags.Flag.DELETED)) {
                expungeMessage(i + 1);
            }
        }
   }

Regards,
Peter ( Peter.Perenyi ird.govt.nz )

CommandParser uses SimpleDateFormat("dd-MMM-yyyy hh:mm:ss zzzz", Locale.US) but should use javax.mail.internet.MailDateFormat instead.

There's been a lot of issues related to enhancements and such but I think it would be beneficial to have a published roadmap.

Where do we see GreenMail going for the 1.x series and what's in store for 2.x?

There are various issues in thread synchronization that are uncovered by the MultiRequestTest (execute multiple times and look at command line output). Those should be fixed. While doing this it might be useful to do a general refactoring of the protocol code.

• Separate message creation, sending and checking
• Should be backwards compatible (deprecate GreenMailUtil with reference to new classes)
• Think about integrating another API for creating messages

I brought up issue #11 previously and it was closed out since BuildHive doesn't support Java 1.6. It looks like SnapCI has support for Java 1.6,7 and 8.

We use only one method from it

Migrated from https://sourceforge.net/p/greenmail/bugs/5 :

We are using greenmail within Alfresco and have seen some memory usage that do not seem to be as efficient as possible. With each connection and synchronisation of the email client, the base heap memory consumption of the repository increases, despite the client being disconnected / logged out properly.

If needed we can provide a neutral heap dump for analysis. When looking at the "shortest path to GC root" we can see that 46 instances of com.icegreen.greenmail.imap.ImapHandler (80 MiB of retained memory) are kept in memory by deactivated handlers referenced from the ImapServer.
Attached is a patch generated from a previously patched version of greenmail. Applying this patch resolves the issue for our test case.