Noncompliance with RFC 5321, Section 4.5.2. Transparency

[TysonMN]

RFC 5321, Section 4.5.2. Transparency says in part

• Before sending a line of mail text, the SMTP client checks the first character of the line. If it is a period, one additional period is inserted at the beginning of the line.

• When a line of mail text is received by the SMTP server, it checks the line. If the line is composed of a single period, it is treated as the end of mail indicator. If the first character is a period and there are other characters on the line, the first character is deleted.

Here is the relevant method in EmbeddedMail. I see two problems with this.

First, EmbeddedMail does not remove the extra period added by mail clients when the line begins with a period.

Second, EmbeddedMail ignores white space when checking for the end of mail indicator. If the email body should contain

aa
 .
bb
cc

then a compliant mail client will send

aa
 .
bb
cc
.

and EmbeddedMail will create two messages, one with body

aa

and one with body

cc

Fixing this is easy, but it would conflict with RPs #6 and #8. I will wait for these PRs to be resolved before creating a fix for this issue.

[jmarnold]

@TysonMN Not sure if you're still using this. I'm going to be open sourcing a new version of this pretty soon (as well as a hosted one). Long story short, it uses AWS SES to deliver emails to s3 and then we have some lambdas that parse it out and store data in S3 and dynamo.

[TysonMN]

Hello @jmarnold. We were using this in a project at my previous company. I think the project is now a commercially available project and still being maintained, but I am no longer involved.

Your efforts sound good though. Good luck with the next version of this library :)