SMuTPea is a Java framework for constructing RFC-compliant Simple Mail Transport Protocol (SMTP) agents, SMTP testing tools or to lean about the SMTP protocol.
- Why a SMTP framework
- Modules
- Examples
- Write your own MTA
- Testing Applications that Email with SMuTPea
- License
There are available numerous SMTP implementations in various programming languages and technologies out there on the Internet.
Having been asked for ideas on how to test an application that sends emails, I began looking for, not a complete SMTP implementation, but a simple MTA that would dump messages rather than send them, and one that would work without requiring much if any configuration. I didn't locate what I needed, instead finding typically feature-complete SMTP implementations that would work only after substantial configuration effort.
I decided to write what I needed. I read the RFCs for SMTP, and thinking about what I had hoped to find but did not see, what came to mind was a framework that embodied the structure of the SMTP RFC in Object Orientated form, validating the SMTP dialogue, but giving the implementer free reign as to how to process email passing through.
Thinking about the infrastructure to hand and the way the testing was going to happen, I choose Java and Maven.
SMuTPea is a built around Apache Maven. To build the project, from the project top-level directory:
mvn package
This will compile the classes, run the unit-tests, and build .jar files for each module with an uber .jar repleat wit dependencies under smutpea_all/target.
Core embodies the SMTP RFCs as Objects, enforcing the RFC rules, defining the role of the MTA while leaving it implementation up to you. This allows implementors to write their own MTA without having to write the defined dialogues or rules around it, leaving the enforcement of that up to SMutPea-Core.
MTA provides an abstract MTA that can be extended by the MTA writer. This abstract MTA provides some basic functionality and breaks out the choices the MTA implementor has to consider into well-defined abstract methods. Also provided here is a Sink MTA: An MTA that looks and acts like an MTA but requires no configuration, no network connection and sends no email. Having a MTA that requires no set up and will not send email is useful for testing applications that do expect a MTA to be available.
Servers provides abstract servers that manage the MTA lifecycle. There are two abstract servers, one that manages the MTA lifecycle on standard input/output streams, and one managing the MTA lifecycle on network sockets. There are also example server implementations that put a Sink server on the command line (allowing the user to practice SMTP interactively themselves) and on TCP sockets. Transcripts Transcripts for each Client connection can be collated, formatted and output, to System.out, a File or via HTTP PUT, after the connection ends. Transcripts are configured via System parameters: System.out requires the use of -DtranscriptPlain with no value, and JSON requires the use of -DtranscriptJSON with a value of a FILE or HTTP URI.
All is an assembly module that take SMuTPea and it dependencies and puts them in a single jar for distribution and execution.
Using the MTA interface, implement the methods as you wish, processing the SMTP commands as you wish, and SMTP will validate input and output for protocol and tell you when you're out of step with the SMTP RFC.
It was the need to test email producing applications that sparked the creation of SMuTPea. Setting up an SMTP server for unit testing and ensuring that all testing be leak-proof is easy... until it fails. SMuTPea's SinkMTA can be stood-up without configuration and will not, cannot leak email. SMuTPea can also provide you with stats on the email dispatches requested.
Included are a couple of example SMTP server implementation servers that utilize the sink MTA. One server is the command line server,CLISinkServer, that opens up as a connection to the MTA. It can be executed thus:
java -cp smutpea-all-0.0.6-SNAPSHOT.jar com.github.technosf.smutpea.server.example.CLISinkServer
And with a transcript output to transcript.out so the dialogue can be reviewed:
java -DtranscriptPlain=transcript.out -cp smutpea-all-0.0.6-SNAPSHOT.jar com.github.technosf.smutpea.server.example.CLISinkServer
And with debgging on so the program flow can be examined:
java -DtranscriptPlain=transcript.out -Dorg.slf4j.simpleLogger.defaultLogLevel=debug -cp smutpea-all-0.0.6-SNAPSHOT.jar com.github.technosf.smutpea.server.example.CLISinkServer
The other example server is a socket-based sink server SocketSinkServer, which runs on the standard SMTP port, 25.
-
0.0.6 Added Transcriptions for each client connection. Trancsripts can be plain or JSON formated and output to System.out or, in JSON format, deposited accourding to a File or HTTP URI.
-
0.0.5 Updated to RFC5321 & RFC7504, implementation of a Dummy server. Cleaned up project structure, return code validation. Updated to JAVA 17.
-
0.0.1-0.0.4 First cut at RFC2821, implementation of Refuse and Sink MTAs and servers
SMuTPea - Copyright 2013 technosf [https://github.com/technosf]
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.