[GH-ISSUE #620] Losing mails due to RFC5321 validation

kerem commented

2026-03-15 14:11:44 +03:00

Owner

Originally created by @tcolgate on GitHub (Jan 21, 2026).
Original GitHub issue: https://github.com/axllent/mailpit/issues/620

Hi,
The recent introduction of mail address length verification is causing us to lose messages sent to mailpit via sendgrid. Sendgrid generates an overly long FROM address which goes over the 63 byte local part limit.
I am not sure though that mailpit is responding correctly in this case. The RFC suggests (https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.3.1.9), that the correct response in this case is probably 500 Line too long., where mailpit is responding 501 5.5.4 Syntax error in parameters or arguments (invalid FROM parameter)".
I am not sure if sendgrid would re-send if presented with the correct message, but it seems plausible.

Originally created by @tcolgate on GitHub (Jan 21, 2026). Original GitHub issue: https://github.com/axllent/mailpit/issues/620 Hi, The recent introduction of mail address length verification is causing us to lose messages sent to mailpit via sendgrid. Sendgrid generates an overly long FROM address which goes over the 63 byte local part limit. I am not sure though that mailpit is responding correctly in this case. The RFC suggests (https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.3.1.9), that the correct response in this case is probably `500 Line too long.`, where mailpit is responding `501 5.5.4 Syntax error in parameters or arguments (invalid FROM parameter)"`. I am not sure if sendgrid would re-send if presented with the correct message, but it seems plausible.

kerem

2026-03-15 14:11:44 +03:00

closed this issue
added the
bug
label

kerem commented

2026-03-15 14:12:00 +03:00

Author

Owner

@axllent commented on GitHub (Jan 21, 2026):

Thanks @tcolgate - Sendgrid is obviously using invalid (too long) email addresses, however the error response coming from Mailpit should be fixed. Thanks for reporting, I'll look into this when I get the chance.

@axllent commented on GitHub (Jan 21, 2026): Thanks @tcolgate - Sendgrid is obviously using invalid (too long) email addresses, however the error response coming from Mailpit should be fixed. Thanks for reporting, I'll look into this when I get the chance.

kerem commented

2026-03-15 14:12:05 +03:00

Author

Owner

@axllent commented on GitHub (Jan 22, 2026):

I'm actually not sure about this. It's not so much that the line is too long, it's that the address is too long (501). I don't however believe that SendGrid will use that response to resend anything, in fact they even have documentation which states the same RFC5321 limits as I implemented in Mailpit. If they are sending emails using longer than that, then I think you should complain to them.

The issue with SMTP servers is that there appear to be no actual fixed standards with regards to error messages. The code itself is actually all that matters, and even then it appears to be a general 4**, 5** etc error. Gmail have a huge list of their SMTP return statuses which appear to be completely custom at the best of times.

@axllent commented on GitHub (Jan 22, 2026): I'm actually not sure about this. It's not so much that the line is too long, it's that the address is too long (501). I don't however believe that SendGrid will use that response to resend anything, in fact they even have [documentation which states](https://www.twilio.com/docs/sendgrid/glossary/invalid-email) the same RFC5321 limits as I implemented in Mailpit. If they are sending emails using longer than that, then I think you should complain to them. The issue with SMTP servers is that there appear to be no actual fixed standards with regards to error messages. The code itself is actually all that matters, and even then it appears to be a general 4**, 5** etc error. Gmail have a [huge list](https://support.google.com/mail/answer/3726730?hl=en) of their SMTP return statuses which appear to be completely custom at the best of times.

kerem commented

2026-03-15 14:12:10 +03:00

Author

Owner

@tcolgate commented on GitHub (Jan 22, 2026):

This is definitely a sendgrid problem, no disagreement there. It is probably wishful thinking to thing sengrid would handle a different error message in any other way. One thing I would say though is that the RFC does state that implementations should handle objects of at least the given sizes, but only that larger sizes SHOULD be avoided (rather than MUST). Also:

To the maximum extent possible, implementation techniques that impose no
limits on the length of these objects should be used.

So enforcing the "minimum maximums" as a hard limit doesn't really feel like it is in the spirit of the intent of 4.5.3.1 .

@tcolgate commented on GitHub (Jan 22, 2026): This is definitely a sendgrid problem, no disagreement there. It is probably wishful thinking to thing sengrid would handle a different error message in any other way. One thing I would say though is that the RFC does state that implementations should handle objects of at least the given sizes, but only that larger sizes `SHOULD` be avoided (rather than `MUST`). Also: ``` To the maximum extent possible, implementation techniques that impose no limits on the length of these objects should be used. ``` So enforcing the "minimum maximums" as a hard limit doesn't really feel like it is in the spirit of the intent of 4.5.3.1 .

kerem commented

2026-03-15 14:12:15 +03:00

Author

Owner

@axllent commented on GitHub (Jan 22, 2026):

You raise a valid point. It's definitely not a technical limitation, in fact until I implemented this limitation there wasn't one at all. This restriction came about indirectly in relation to a fix whereby email validation was implemented, and while I was doing that I also implemented those limits as per the RFC.

The question is whether this is a good or bad thing for Mailpit to enforce this limit. I would argue that if software is being tested with Mailpit and it works, then the expectation is that it should work in real life too. If one is allowed to use "unlimited" characters in Mailpit, but other real servers are implementing the limit, then that is going to cause issues.

Based on the Gmail list, I don't think they enforce a limit, but I also wouldn't say that anything Gmail do is necessarily RFC-compliant :) I'll need to sleep on this and give it more thought. I'm also a bit short on time at the moment but I would like to resolve this one way or another and give you a definitive answer.

If you could, would you mind doing a little more research for me please to see if there are any clues how maybe postfix and other OSS solutions do it (whether they enforce anything)? I don't think we'll find much information on other commercial hosted solutions (eg: Office365), but if that does turn up anything in your search then I'd be interested to see what they do too. Thanks.

@axllent commented on GitHub (Jan 22, 2026): You raise a valid point. It's definitely not a technical limitation, in fact until I implemented this limitation there wasn't one at all. This restriction came about indirectly in relation to a fix whereby email validation was implemented, and while I was doing that I also implemented those limits as per the RFC. The question is whether this is a good or bad thing for Mailpit to enforce this limit. I would argue that if software is being tested with Mailpit and it works, then the expectation is that it should work in real life too. If one is allowed to use "unlimited" characters in Mailpit, but other real servers are implementing the limit, then that is going to cause issues. Based on the Gmail list, I don't think they enforce a limit, but I also wouldn't say that anything Gmail do is necessarily RFC-compliant :) I'll need to sleep on this and give it more thought. I'm also a bit short on time at the moment but I would like to resolve this one way or another and give you a definitive answer. If you could, would you mind doing a little more research for me please to see if there are any clues how maybe postfix and other OSS solutions do it (whether they enforce anything)? I don't think we'll find much information on other commercial hosted solutions (eg: Office365), but if that does turn up anything in your search then I'd be interested to see what they do too. Thanks.

kerem commented

2026-03-15 14:12:20 +03:00

Author

Owner

@tcolgate commented on GitHub (Jan 22, 2026):

I can't spend a tonne of time on this, but I'll put a few notes in this comment and update it as I find anything:

checked exim, it does enforce the local part RFC limits for the <> contained address, but has is variously lenient on other elements of the address (github.com/Exim/exim@13835a3c1e/src/src/exim.h (L130))
the postfix code is a bit harder to grok, but I've tested with a simple local setup, created an alias with a very long local part (73 chars). Postfix accepts this via smtp:

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 localhost ESMTP Postfix
EHLO test.com
250-localhost
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING
MAIL FROM: <testing@test.com>
250 2.1.0 Ok
RCPT TO: <aNotStrictlyRFCCompliantOverlyLongEmailLocalPartNameForTestMailpitBehaviour@localhost>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: this is a test

I sent a test.
.
250 2.0.0 Ok: queued as A79C848A1

tested against OpenSMTPD, that also accepts the mail

Escape character is '^]'.
220 malbec ESMTP OpenSMTPD
EHLO test.com
250-malbec Hello test.com [::1], pleased to meet you
250-8BITMIME
250-ENHANCEDSTATUSCODES
250-SIZE 36700160
250-DSN
250 HELP
MAIL FROM: <test@test.com>
250 2.0.0 Ok
RCPT TO: <aNotStrictlyRFCCompliantOverlyLongEmailLocalPartNameForTestMailpitBehaviour@localdomain>
250 2.1.5 Destination address valid: Recipient ok
data
354 Enter mail, end with "." on a line by itself
Subject: This is a test mail

test email to silly address
.
250 2.0.0 b03bfffa Message accepted for delivery

One interesting observation is that the me from 20 years ago was deeply impressive for having had the patience and intellect to understand any of the sendmail documents, far more so than the me from now that simply cannot be bothered (OMG! I used to hand write sendmail configs for a very complex email relay, and now I can't event get through one page of the docs without wanting to tear my eyes out). I wont be testing sendmail 🤣

@tcolgate commented on GitHub (Jan 22, 2026): I can't spend a tonne of time on this, but I'll put a few notes in this comment and update it as I find anything: - checked exim, it does enforce the local part RFC limits for the `<>` contained address, but has is variously lenient on other elements of the address (https://github.com/Exim/exim/blob/13835a3c1e057efad7da269c0f93bf2eac850205/src/src/exim.h#L130) - the postfix code is a bit harder to grok, but I've tested with a simple local setup, created an alias with a very long local part (73 chars). Postfix accepts this via smtp: ``` Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 localhost ESMTP Postfix EHLO test.com 250-localhost 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250-SMTPUTF8 250 CHUNKING MAIL FROM: <testing@test.com> 250 2.1.0 Ok RCPT TO: <aNotStrictlyRFCCompliantOverlyLongEmailLocalPartNameForTestMailpitBehaviour@localhost> 250 2.1.5 Ok DATA 354 End data with <CR><LF>.<CR><LF> Subject: this is a test I sent a test. . 250 2.0.0 Ok: queued as A79C848A1 ``` - tested against OpenSMTPD, that also accepts the mail ``` Escape character is '^]'. 220 malbec ESMTP OpenSMTPD EHLO test.com 250-malbec Hello test.com [::1], pleased to meet you 250-8BITMIME 250-ENHANCEDSTATUSCODES 250-SIZE 36700160 250-DSN 250 HELP MAIL FROM: <test@test.com> 250 2.0.0 Ok RCPT TO: <aNotStrictlyRFCCompliantOverlyLongEmailLocalPartNameForTestMailpitBehaviour@localdomain> 250 2.1.5 Destination address valid: Recipient ok data 354 Enter mail, end with "." on a line by itself Subject: This is a test mail test email to silly address . 250 2.0.0 b03bfffa Message accepted for delivery ``` - One interesting observation is that the me from 20 years ago was deeply impressive for having had the patience and intellect to understand any of the sendmail documents, far more so than the me from now that simply cannot be bothered (OMG! I used to hand write sendmail configs for a very complex email relay, and now I can't event get through one page of the docs without wanting to tear my eyes out). I wont be testing sendmail 🤣

kerem commented

2026-03-15 14:12:25 +03:00

Author

Owner

@gravitroul commented on GitHub (Jan 22, 2026):

Hi, just had the case with our Test team. What is the plan about that: being compliant with RFC or do like all other implementations and cheat on it? :)
Maybe first time would be nice to answer the "500 Line too long" because we had to diagnose to understand what was the problem.
Maybe you could add a check and information about that in the checks juste like html etc...

@gravitroul commented on GitHub (Jan 22, 2026): Hi, just had the case with our Test team. What is the plan about that: being compliant with RFC or do like all other implementations and cheat on it? :) Maybe first time would be nice to answer the "500 Line too long" because we had to diagnose to understand what was the problem. Maybe you could add a check and information about that in the checks juste like html etc...

kerem commented

2026-03-15 14:12:30 +03:00

Author

Owner

@axllent commented on GitHub (Jan 22, 2026):

Thanks so kuch @tcolgate for your research, very valuable information. From what I can see, nobody (so far) appears to enforce the RFC "should" length.

At a quick read, Exim does enforce a character limit of 1024, which is more a security limitation than anything I suspect. In your opinions (@tcolgate & @gravitroul ), if I was to increase the max to 1024 characters and return a "Line too long" (or something along those lines), would that make sense to you both, and do you agree that this would prevent the issues you're running into?

@axllent commented on GitHub (Jan 22, 2026): Thanks so kuch @tcolgate for your research, very valuable information. From what I can see, nobody (so far) appears to enforce the RFC "should" length. At a quick read, Exim does enforce a character limit of 1024, which is more a security limitation than anything I suspect. In your opinions (@tcolgate & @gravitroul ), if I was to increase the max to 1024 characters and return a "Line too long" (or something along those lines), would that make sense to you both, and do you agree that this would prevent the issues you're running into?

kerem commented

2026-03-15 14:12:36 +03:00

Author

Owner

@tcolgate commented on GitHub (Jan 22, 2026):

At a quick read, Exim does enforce a character limit of 1024, which is more a security limitation than anything I suspect. In your opinions (@tcolgate & @gravitroul ), if I was to increase the max to 1024 characters and return a "Line too long" (or something along those lines), would that make sense to you both, and do you agree that this would prevent the issues you're running into?

The specific limit that hit us was the local part limit (chars before the @). Personally I would log the non RFC compliance, but not error (or stu8k that behind a config option).

@tcolgate commented on GitHub (Jan 22, 2026): > At a quick read, Exim does enforce a character limit of 1024, which is more a security limitation than anything I suspect. In your opinions ([@tcolgate](https://github.com/tcolgate) & [@gravitroul](https://github.com/gravitroul) ), if I was to increase the max to 1024 characters and return a "Line too long" (or something along those lines), would that make sense to you both, and do you agree that this would prevent the issues you're running into? The specific limit that hit us was the local part limit (chars before the @). Personally I would log the non RFC compliance, but not error (or stu8k that behind a config option).

kerem commented

2026-03-15 14:12:41 +03:00

Author

Owner

@axllent commented on GitHub (Jan 23, 2026):

Thanks for the feedback. I've decided to just increase the limit to 1024 characters, and return more meaningful responses:

If an address is > 1024 characters 500 The address is too long
If an address is invalid 553 5.1.3 The address is not a valid RFC 5321 address
If the command doesn't match the correct syntax (eg MAIL FROM: [sender@example.com]) 01 5.5.4 Syntax error in parameters or arguments (invalid FROM parameter)

I really do not want to over-complicate this piece (such as configuration options etc), so I think this is the happy medium. I hope to release a new version some time this weekend, unless either of you have any objection to my proposed approach.

@axllent commented on GitHub (Jan 23, 2026): Thanks for the feedback. I've decided to just increase the limit to 1024 characters, and return more meaningful responses: - If an address is > 1024 characters `500 The address is too long` - If an address is invalid `553 5.1.3 The address is not a valid RFC 5321 address` - If the command doesn't match the correct syntax (eg `MAIL FROM: [sender@example.com]`) `01 5.5.4 Syntax error in parameters or arguments (invalid FROM parameter)` I really do not want to over-complicate this piece (such as configuration options etc), so I think this is the happy medium. I hope to release a new version some time this weekend, unless either of you have any objection to my proposed approach.

kerem commented

2026-03-15 14:12:46 +03:00

Author

Owner

@gravitroul commented on GitHub (Jan 23, 2026):

Just to be sure, is this limitation also on TO: field ? And if it is, will you do the same adaptation?

@gravitroul commented on GitHub (Jan 23, 2026): Just to be sure, is this limitation also on TO: field ? And if it is, will you do the same adaptation?

kerem commented

2026-03-15 14:12:51 +03:00

Author

Owner

@axllent commented on GitHub (Jan 23, 2026):

Yes, sorry that I hadn't made that clear - this applies to both the MAIL FROM and RCPT TO.

@axllent commented on GitHub (Jan 23, 2026): Yes, sorry that I hadn't made that clear - this applies to both the `MAIL FROM` and `RCPT TO`.

kerem commented

2026-03-15 14:12:56 +03:00

Author

Owner

@axllent commented on GitHub (Jan 24, 2026):

I have released v1.28.4 which includes the character increase (to 1024). I will close this issue, but please confirm if this resolves both your issues, thank you.

@axllent commented on GitHub (Jan 24, 2026): I have released [v1.28.4](https://github.com/axllent/mailpit/releases/tag/v1.28.4) which includes the character increase (to 1024). I will close this issue, but please confirm if this resolves both your issues, thank you.

Rows
Columns

[GH-ISSUE #620] Losing mails due to RFC5321 validation #388