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?