add overrides for: from and to

[brjppru]

Question:

Is it possible to add two new options for handling emails, for example:

MP_SMTP_RELAY_RETURN_PATH
MP_SMTP_RELAY_OVERRIDE_FROM
MP_SMTP_RELAY_OVERRIDE_TO

These options are needed for forwarding emails via MP_SMTP_RELAY_HOST, as some servers reject emails if the From: field does not match the login used for authentication (MP_SMTP_RELAY_USERNAME).

Alternatively, would it make sense to introduce a single setting that automatically sets both the From and To fields to match the MP_SMTP_RELAY_USERNAME?

Thank you!

[axllent]

Hi @brjppru, apologies for the delay (I was taking some time off over the festive season). This type of functionality really doesn't quality as a "relay", it's more a "forward" than anything else.

I understand your point about the From address (although my answer would be to "use a different SMTP server"), but I'm more curious as to why you want to hardcode the To - I am curious as to what you are trying to achieve here exactly?

[brjppru]

Thank you for your message! First of all, Merry Christmas and Happy New Year! 🎄✨

I’m working on debugging my app and email distribution system. I have a user database, and here’s how I want to use it: I have an external SMTP server that requires authentication (the app already handles that), and I want to send unique, legal emails to my users—all of whom are authorized. However, the SMTP server only allows sending emails from the address used during authentication (the "From" field).

What I’d like to do is modify the "To" field so that all emails are sent to my own address (which matches the "From" address) to test how the emails appear across various clients—Outlook, Apple Mail, and multiple Android email apps—before finalizing the design. Let me know if this setup makes sense or if there’s a better way to handle it.

I want to debug by sending emails from myself to myself through my server to check how the email layout displays across different clients. My mailbox is already connected to various email clients via IMAP.

I would be glad if you could add functionality that allows overriding the "From" and "To" fields in emails using variables for different environments.

Thank you!

[bldrdash]

Hi @axllent , I came here looking for the exact same thing.

Use case for me that services such as SES or Sendgrid will reject a message if the FROM domain hasn't already been setup. I may have a system that is sending a message from root@localhost that I'd like to eventually forward on, and SES isn't going to allow me to verify the "localhost" TLD, or localhost.local or gitea.local, etc.

It can be a chore to lookup the documentation for sendmail/postfix/exim/applicationX so that the FROM address is in proper form, and sometimes it isn't even possible.

Without the ability to change the from address, there is no way to forward the email on through one of these SMTP services.

In addition to the original request, I'd have one more: include the original FROM address. For example:
MP_SMTP_RELAY_OVERRIDE_FROM=[email protected]
MP_SMTP_MUNGE_FROM=_

This would take the FROM address "[email protected]" and change it to:
"root_gitea.local <[email protected]>"

The result would be I'd be able to see the original sender in my email client. The MP_SMTP_MUNGE_FROM value would be what to replace the "@" with.

Thank you for your consideration --

[axllent]

@brjppru & @bldrdash - firstly I believe the existing yaml return-path (or MP_SMTP_RELAY_RETURN_PATH environment) may solve your From address" issues. When it comes to SMTP, the return path is what the SMTP client tells the server the email is from, regardless what is actually in the email header itself (ie: mail servers do not read the email itself to decide who to send to, they are told by the sending SMTP client). The return path is also written / updated in the email header, but it really shouldn't matter what the email header From actually says. Are both you able to confirm for me please if setting the MP_SMTP_RELAY_RETURN_PATH solves your sending issue?

@brjppru - assuming what I just wrote above is correct and does sort that part of your question, then this just leaves the To. You want to force everything to go to a single address. Again, like the From address, we don't actually need to modify the email header itself, the SMTP client (Mailpit) just needs to tell the remote SMTP server who to send to during the SMTP transaction (just like with BCC messages). Theoretically this should be simple enough, however this also impacts the web UI (email release) because that currently allows you to set who to send it to. If we are going to enforce the To, then I will need to account for this in the UI to avoid confusion. I'll wait for confirmation about the first paragraph first before deciding how to handle this.

[brjppru]

Unfortunately no, my server only accepts emails if I substitute the from field, even if I specify a valid MP_SMTP_RELAY_RETURN_PATH, I get a reject for relay. That's why I came with such a request.

[brjppru]

I realize that the case with malicious mail servers and from + to substitution for replay is not a common situation. I don't think it should be displayed in the web interface for the mass user, but if you explicitly specify by hand that you auth = from + to, then I would like to see these simultaneous rule matches work

1. rewrite: mail from : [email protected]

2. rewrite: mail to: [email protected]

3. rewrite: auth for: [email protected]

   environment:
   MP_MAX_MESSAGES: 5000
   MP_SMTP_AUTH_ALLOW_INSECURE: true
   MP_USE_MESSAGE_DATES: true
   MP_SMTP_AUTH_ACCEPT_ANY: true
   MP_SMTP_DISABLE_RDNS: true
   MP_SMTP_RELAY_ALL: true
   MP_SMTP_RELAY_HOST: 192.168.0.27
   MP_SMTP_RELAY_USERNAME: [email protected]
   MP_SMTP_RELAY_PASSWORD: mysuperdevpass
   MP_SMTP_RELAY_RETURN_PATH: [email protected]
   MP_ALLOW_UNTRUSTED_TLS: true

+++

MP_SMTP_RELAY_OVERRIDE_FROM: [email protected]
MP_SMTP_RELAY_OVERRIDE_TO: [email protected]

in fact, can say that we are forcing catch-all but for relay

[axllent]

Yeah, I don't think I can solve this (logically) with "relaying" - it's effectively "forwarding". They are fundamentally very different things, and by trying to modify relaying to override From and To, it's no longer relaying. It gets super-confusing when relaying is something that can be triggered manually via the UI.

I need to give this more thought, however my current thoughts are as follows... A new set of configuration options that can be used in combination with relaying or not (ie: they are not linked):

MP_SMTP_FORWARDING_TO=<to-email>                        # required
MP_SMTP_FORWARDING_FROM=<from-email>                    # optional
MP_SMTP_FORWARDING_HOST=<hostname-or-ip>                # required
MP_SMTP_FORWARDING_PORT=<port>                          # optional - default 25
MP_SMTP_FORWARDING_STARTTLS=<true|false>                # optional - default false
MP_SMTP_FORWARDING_ALLOW_INSECURE=<true|false>          # optional - default false
MP_SMTP_FORWARDING_AUTH=<none|plain|login|cram-md5>     # optional - default none
MP_SMTP_FORWARDING_USERNAME=<username>                  # required for plain, login and cram-md5 auth
MP_SMTP_FORWARDING_PASSWORD=<password>                  # required for plain & login auth
MP_SMTP_FORWARDING_SECRET=<cram-secret>                 # required for cram-md5 auth

If From is set, then the original From gets replaced with this, and the old From gets inserted as a new header X-ORIGINAL-FROM or something. The original "To" & CC headers shouldn't need modifying, the SMTP server is supposed to read this from the SMTP client which would then tell it to use the MP_SMTP_FORWARDING_TO instead.

Sorry @bldrdash , I don't like the idea of MP_SMTP_MUNGE_FROM as the From header is very fluid, and to try get this right would be prone to all kinds of potential issues - I'd rather just copy/paste the header into another header ~ I assume that would work for you?

[brjppru]

In fact, if we move away from the application and back to mail, we have two processes

1. mail accumulation in mailpit itself and relay to smtp - already implemented

2. mail accumulation in mailpit and forwarding it to the specified address via smtp server (+from +to +smtp +auth)

The first and the second deliver mail, but the logical component is different. i agree with you completely that what i am asking you to implement from the application point of view is additional forwarding, not delivery (relay) of mail to the box.

As in this case two mechanisms can work 1) accumulation of mail 2) delivery by smtp relay 3) delivery by forwarding settings

If you manage to realize this point, I will be very happy!

[brjppru]

In fact, since this is a delivery, it is probably possible to implement a forwarding mechanism directly to imap, bypassing smtp. (well, we won't consider complex relay via other smtp, but smtp -> imap -> storage for forwarded messages), but this complicates the functionality of the application, and I'm not sure I should ask you to do it.

In fact, I need the mail to end up in the imap mailbox, the settings could be like this, e.g.

cat config.txt | grep imap

imap-email-protocol = imap
imap-auth = True
imap-username = [email protected]
imap-password = superstylin
imap-server = groove.armada.uk
imap-port = 993
imap-ssl = True
imap-mailbox = debuglab

[axllent]

In fact, since this is a delivery, it is probably possible to implement a forwarding mechanism directly to imap, bypassing smtp. (well, we won't consider complex relay via other smtp, but smtp -> imap -> storage for forwarded messages), but this complicates the functionality of the application, and I'm not sure I should ask you to do it.

Yeah, direct delivery to an IMAP server falls well outside of the scope of this project, so that's not a good move as it adds a lot of complexity and doesn't benefit the thousands of other Mailpit users.

As a suggestion - if your goal is simply getting a copy of the messages into another mail server, then my not pull those messages via POP3 (which already exists), or even configure your email clients to fetch the messages directly from Mailpit via POP3?

[brjppru]

We’re moving from a push model, where mail is delivered, to a pull model, where it needs to be fetched. This means I’d have to access Mailpit within the network, open up things in the firewall, and ensure full connectivity. That’s a bit beyond the scope of a straightforward mail delivery task like SMTP push :-(

[axllent]

That's a fair point, although I had no understanding of your infrastructure/network of course. Pushing to IMAP is not an option, so we're back to forwarding via SMTP.

I will add a configuration for SMTP forwarding, which only differs slightly to relaying in that the To address needs to be specified. The From will become an optional flag for both relaying and forwarding to address the SMTP restriction you both have. Forwarding will be a separate configuration to relaying to avoid confusion and complications in the web UI (relaying). Forwarding will not be a manually triggered option via the web UI - it will auto-forward messages as they arrive in Mailpit.

It is worth noting a couple of points about forwarding (the same points apply for relaying): Mailpit does not and will not have any fault tolerance if there is an issue delivering mail. There is no queue, retry, or delivery delays - Mailpit will attempt to deliver the emails immediately as they are received, and it will ignore failures (they are logged in the console though). If Mailpit receives 100 messages per second, it's going to spawn 100 simultaneous SMTP connections per second to the forwarding SMTP server. I'm only stating this so it's absolutely clear that Mailpit is not postfix, it's an SMTP & email testing tool designed for receiving emails, not sending them. If this is going to be an issue then I need to know this now, and you will possibly have to rethink your intended testing routine.

I'm not sure exactly when I'll start on this - hopefully soon, however I am still recovering from shoulder surgery so I don't have a lot of energy or capability at the moment.