Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update lib.go: Changing mailFromRE and rcptToRE regex #409

Merged
merged 3 commits into from
Dec 14, 2024

Conversation

ThomasLandauer
Copy link
Contributor

I don't know how to rebase so I started from scratch ;-)

Most important change is ( |$) in the middle, this removes the nested parentheses in the end; and therefore the entire regex is more readable I think (if a regex can be readable at all g...)

Anyway, this now fails on foo>@example.com.

I don't know how to rebase so I started from scratch ;-)

2 changes compared to what you said at axllent#406 (comment)
* I did the same for `rcptToRE`
* I replaced the `*` quantifier with `+`, for consistency
@ThomasLandauer
Copy link
Contributor Author

One more question: This is the first time that I'm seeing the SIZE keyword used somewhere (or do you know popular MTA's using it?). Why did you implement it at all?

@@ -27,8 +27,8 @@ import (
var (
// Debug `true` enables verbose logging.
Debug = false
rcptToRE = regexp.MustCompile(`[Tt][Oo]:\s?<(.+)>`)
mailFromRE = regexp.MustCompile(`[Ff][Rr][Oo][Mm]:\s?<(.*)>(\s(.*))?`) // Delivery Status Notifications are sent with "MAIL FROM:<>"
rcptToRE = regexp.MustCompile(`[Tt][Oo]: ?<([^<>\v]+)>( |$)(.*)?`)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The closing ( |$)(.*)? should be just ?$ as we want to account for one possible space, and then the end of the line. Unlike MAIL FROM, I am not aware of any other arguments that are allowed to be passed to RCPT TO (unless you know something I don't?).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Owner

@axllent axllent Dec 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch! OK, leave rcptToRE as you had it, we just ignore any parameters 👍

@axllent
Copy link
Owner

axllent commented Dec 13, 2024

All good. Rebasing is like taking the changes from another branch and then "merging" your changes over the to of them, but in your current branch. Sometimes with mixed results... so no problem, whatever works :)

One more question: This is the first time that I'm seeing the SIZE keyword used somewhere (or do you know popular MTA's using it?). Why did you implement it at all?

MAIL FROM:<sender@example.com> SIZE=1000 - The SIZE parameter is an optional argument that can be appended to an SMTP transaction to get an early rejection because a message is too big, rather than having to send all the DATA first and then be rejected. I cannot say how often it is used, only that it is definitely used, and is the one argument Mailpit cares about. Technically it's more of a guideline from what I read, an estimate of the size (eg: new headers will get appended), but we use it as-is because it will be close enough.

The other one I came across a couple of days ago is MAIL FROM:<sender@example.com> BODY=8BITMIME - coming via the Cloudflare proxy (#407). This was new to me, but it is a perfectly valid argument, and from what I can tell, used to provide the downstream SMTP server with the message encoding in the event of a bounce (I assume for the attached bounce message). Whilst Mailpit doesn't care about this, it was failing to accept the messages because it did not recognize it (hence my changes in develop you needed to pull in).

I have added a comment regarding the updated rcptToRE regexp. I also note that a few of the tests are now failing in your branch:

  • FROM:<> (empty) is actually valid syntax. I'm just not sure how to change the regex to allow for that... 🤔
  • ignore the failing To, I may need to adjust the tests slightly.

On that note, do you know how to test in go? Running go test github.com/axllent/mailpit/server/smtpd should work for you.

rcptToRE = regexp.MustCompile(`[Tt][Oo]:\s?<(.+)>`)
mailFromRE = regexp.MustCompile(`[Ff][Rr][Oo][Mm]:\s?<(.*)>(\s(.*))?`) // Delivery Status Notifications are sent with "MAIL FROM:<>"
rcptToRE = regexp.MustCompile(`[Tt][Oo]: ?<([^<>\v]+)>( |$)(.*)?`)
mailFromRE = regexp.MustCompile(`[Ff][Rr][Oo][Mm]: ?<([^<>\v]+)>( |$)(.*)?`) // Delivery Status Notifications are sent with "MAIL FROM:<>"
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh found it, to allow an empty value: add a pipe symbol at the start of <(|[^<>\v]+)> so we allow nothing OR what you have - seems to work 🥳

@axllent axllent merged commit 2ea92d1 into axllent:develop Dec 14, 2024
6 checks passed
@axllent
Copy link
Owner

axllent commented Dec 14, 2024

I was still waiting on the final change to allow empty MAIL FROM:<> and then realised I could edit this myself in your working branch (it's a Github feature I've never used before) :) So I've done this now and merged in your change, thanks!

@axllent
Copy link
Owner

axllent commented Dec 14, 2024

This has now been released in v1.21.7. Thanks for your efforts!

@ThomasLandauer ThomasLandauer deleted the patch-3 branch December 14, 2024 10:15
@ThomasLandauer
Copy link
Contributor Author

Just wanted to take care of the rest today, but you already fixed it :-)

About SIZE again: I think it comes unexpected that you really support SIZE (with tests and everything), and ignore all the others. Maybe you could document that somewhere (if it isn't already)?

@axllent
Copy link
Owner

axllent commented Dec 14, 2024

The SMTPD supports SIZE and validates the argument syntax if provided, however Mailpit doesn't use or have an option for that (ie: there is no max message size). It just keeps the options open for future development ;-)

As for documenting it what it validates and what it doesn't in this regard, I'd argue it's not important and just adds lots of words to the documentation. Mailpit was been widely used for testing in the last two+ years, and only this last week did an issue arise because of the BODY= argument - clearly a very rare option to use. SIZE on the other hand is far more common I believe a it prevents the mail server having to send the entire message before being rejected for size, so I assume also used in some mobile & desktop email clients (not just servers). I would definitely add documentation for this if I ever implemented a max size option to Mailpit though, but that's very low on my radar as it's not something people test (if your system is generating messages that are larger than mail servers can handle, then you have much bigger issues).

@ThomasLandauer
Copy link
Contributor Author

ThomasLandauer commented Dec 14, 2024

FYI, I was curious, so I took a closer look at the 3 SMTP clients I have at hand:

Thunderbird 115.14.0:

MAIL FROM:<...> BODY=8BITMIME SIZE=3592

Exim 4.96:

MAIL FROM:<...>

Postfix 3.7.11:

MAIL FROM:<...> SIZE=2779

@axllent
Copy link
Owner

axllent commented Dec 14, 2024

That's really good to know, thank you. Interesting how Thunderbird provides two arguments, which answers another thing I wasn't sure about - how they are strung together. I assumed it was either a space or a comma so I catered for both 😄

@ThomasLandauer
Copy link
Contributor Author

Multiple Keywords are separated by a space; multiple values of the same keyword are separated by comma:

NOTIFY=success,delay,failure

And some keywords don't have values at all:

SMTPUTF8

And there's also a semicolon separating the 2 parts of one value:

ORCPT=rfc822;foo@example.com

tmeijn pushed a commit to tmeijn/dotfiles that referenced this pull request Dec 20, 2024
This MR contains the following updates:

| Package | Update | Change |
|---|---|---|
| [axllent/mailpit](https://github.com/axllent/mailpit) | patch | `v1.21.6` -> `v1.21.8` |

MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot).

**Proposed changes to behavior should be submitted there as MRs.**

---

### Release Notes

<details>
<summary>axllent/mailpit (axllent/mailpit)</summary>

### [`v1.21.8`](https://github.com/axllent/mailpit/blob/HEAD/CHANGELOG.md#v1218)

[Compare Source](axllent/mailpit@v1.21.7...v1.21.8)

##### Chore

-   Update node dependencies
-   Update Go dependencies

##### Fix

-   **db:** Remove unused FOREIGN KEY REFERENCES in message_tags table ([#&#8203;374](axllent/mailpit#374))

### [`v1.21.7`](https://github.com/axllent/mailpit/blob/HEAD/CHANGELOG.md#v1217)

[Compare Source](axllent/mailpit@v1.21.6...v1.21.7)

##### Chore

-   Update node dependencies
-   Update Go dependencies
-   Bump Go version for automated testing
-   Move smtpd & pop3 modules to internal
-   Stricter SMTP 'MAIL FROM' & 'RCPT TO' handling ([#&#8203;409](axllent/mailpit#409))
-   Display "To" details in mobile messages list
-   Display "From" details in message sidebar (desktop) ([#&#8203;403](axllent/mailpit#403))

##### Fix

-   Ignore unsupported optional SMTP 'MAIL FROM' parameters ([#&#8203;407](axllent/mailpit#407))
-   Prevent splitting multi-byte characters in message snippets ([#&#8203;404](axllent/mailpit#404))

##### Testing

-   Add smtpd tests

</details>

---

### Configuration

📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.

♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 **Ignore**: Close this MR and you won't be reminded about this update again.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box

---

This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS42NC4wIiwidXBkYXRlZEluVmVyIjoiMzkuNzUuMCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiUmVub3ZhdGUgQm90Il19-->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants