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

Mox's sendmail compatibility requires a Mox account, running into some limitations/issues #266

Open
Robby- opened this issue Dec 28, 2024 · 8 comments

Comments

@Robby-
Copy link

Robby- commented Dec 28, 2024

Hi, I'm trying to use the sendmail functionality to send out transactional emails, but I'm kind of stuck on trying to make it work the way I want to (or rather the way I am used to, before I started using Mox). I'll try to explain this as best I can.

I used to have the actual MX setup on a separate machine, and on another one I had Postfix and a program calling Postfix's sendmail but it would send out mail directly on its own from [email protected], bypassing the MX. And then in that MX setup, I had configured [email protected] as a forwarder to my address/account within the same domain, simply so I could do a little bit of monitoring on it for the people that did end up replying to it anyways. But, due to this setup I always had the option of removing that [email protected] forwarder, so that any emails to it could just simply bounce (or even be blackholed) and truly be unmonitored. Now I have both the MX setup (Mox), and the program that is using sendmail, on one server.

Now, the way sendmail compatibility works in Mox is that it requires an account (and thus authentication) to even be able to use it, this seems to add some limitations I did not have when using Postfix's sendmail the way I was, namely:

  • requires having an account in Mox
  • cannot send from any sender address I want (using -f option or otherwise) within the same domain because Mox enforces the address associated with the account to be the sender address
  • due to now needing a full-fledged account to use sendmail, the associated account address is now able to receive email on it, which I do not want to happen, as that account would essentially be unmonitored and will use up more and more disk space as time goes on, and so on

So, lets say I name this new Mox account that is meant for use with sendmail: sendmail/[email protected], and I also add an alias to this account called [email protected] so that it can be used as a sender address by the program that is calling sendmail.
Then I'm left with a few questions:

  • how can I reject (or accept and delete) incoming emails to [email protected] (the real account address)? (1)
  • how can I send mail using this alias as a From address? when I try it I get:
    • in the logs: "submission with unconfigured mailfrom"
    • and this from sendmail to stdout: submit failed: submit message: remote smtp server sent unexpected response status code: got 550, expected 2xx, permanent: 550 5.7.1 must match authenticated user
    • I can only use the real address [email protected] as sender, only then the email gets accepted and goes through
    • I have now tried this with Thunderbird and am running into the exact same issue there, maybe I found a bug? the alias is configured correctly: Allow messages to use the alias address in the message From header is enabled in the webadmin UI
  • how can I reject (or accept and delete) incoming emails to [email protected] (the alias) and still have sendmail be able to use it as a From address?
  • how can I have incoming emails to [email protected] forwarded to my (and only my) account and still have sendmail be able to use it as a From address?

(1): I'd honestly rather have the real account address behave as if it doesn't exist at all, since its sole purpose for existing is facilitating outgoing transactional emails from sendmail anyway.

@mjl-
Copy link
Owner

mjl- commented Dec 29, 2024

Hi Robby-, thanks for reporting!

As for rejecting incoming message for noreply@, that's not currently
possible. There is at least one other open issue for implementing this. It
may be in the context of people having a catchall for their domain, but where
they want to reject message addressed at certain addresses. I've been
thinking the right solution may be a config option for account addresses that
cause incoming email to be rejected (perhaps with a configurable error code,
like "user does not exist" or "temporary error"). It isn't implemented yet,
but once it is it may solve this part of the problem.

About sending with another address: It seems you added the sendmail@ address
as an alias, not as an additional address. The name "alias" is a bit of a
misnomer, and there has been a commit that isn't in a release yet that
attempts to clarify that the alias is more like a mailing list. If you want
the authenticating account with the noreply@ address to also send with a
sendmail@ From address, you need to add the sendmail@ as an additional
address to the account.

It is a bit surprising that you're getting the error message when sending with
the address in the From header though. Will look into that.

Btw, accounts don't have a primary address. They just have one or more
addresses. And you can authenticate with any of them as username, and use any
of the addresses as From address.

If sending with configured additional address instead of alias helps, would
being able to configure addresses to be rejected solve your use-case?

@Robby-
Copy link
Author

Robby- commented Dec 29, 2024

As for rejecting incoming message for noreply@, that's not currently...

Yes, I think that would solve this part of the problem indeed.

About sending with another address: It seems you added the sendmail@ address
as an alias, not as an additional address.

I created an account called sendmail, and then added noreply@ as an alias, but indeed not as an additional address.

The name "alias" is a bit of a misnomer...

That would explain it.

It is a bit surprising that you're getting the error message when sending with the address in the From header though. Will look into that.

Thank you. Btw, you mean when trying to use an alias address even though the appropriate option is indeed enabled? Yes, its odd, unless the description is also off and this option does something else than what I think it does?

And you can authenticate with any of them as username

Ah, that's good to know.

If sending with configured additional address instead of alias helps, would being able to configure addresses to be rejected solve your use-case?

Yes, I believe so.

But now I have the following question: can I add multiple identical additional addresses to different accounts? For example, can I add help@ to different accounts? Because I need to be able to have multiple people send out emails as coming from help@. The way our previous MX handled this was I added the alias in it (or forwarder, or list, however you want to call it), then added the actual addresses to where emails to help@ were supposed to be delivered to, and then I could select specific accounts that were authorized to send out emails with help@ as the From address. This prevented the need to send out emails from our own personal addresses, causing any replies to it to still correctly go to help@.

@Robby-
Copy link
Author

Robby- commented Jan 1, 2025

In the meantime I've done some testing myself and concluded it is not possible to add multiple identical additional addresses to different accounts, you get an error if you try. Figured this would be the case, especially since they can be used as a username to authenticate, so that makes sense.

So, I guess this is kind of turning into a feature request and also a bug report, which I'll try and summarize below.

Bug report:

  • Cannot send out emails using an alias as a From address even though Allow messages to use the alias address in the message From header is enabled in the webadmin UI.

Feature requests:

  • Ability to use aliases as From addresses and ability to configure permissions to use these as From addresses on an account-per-account basis so that not just anyone can do this. Use case for this is so that multiple people can receive email for an alias/list address on their own personal accounts, but can still send out email using an alias as From address, so that any replies still arrive at the right place, eliminating the need to resort to creating a separate (shared) account for it and having to give everyone the authentication credentials to it.
  • Ability to send out transactional emails from a noreply@ address (noreply account) but optionally pretend the address doesn't exist by rejecting incoming emails to this address while still delivering/forwarding these emails to a different account or even to an alias/list. I would use this for mox sendmail (as the noreply account purely exists for being able to send out email) and to restore the behavior we had with our previous setup.

mjl- added a commit that referenced this issue Jan 13, 2025
…as as smtp mail from during submission

mail clients will use these message from addresses also for smtp mail from, so
sending over smtp would fail for these cases. for the webmail and webapi they
already succeeded since we just took the "message from" address as "smtp mail
from" address.

for issue #266 by Robby-, thanks for reporting!
@mjl-
Copy link
Owner

mjl- commented Jan 13, 2025

@Robby- The commit just now should fix the problem of not being able to send over SMTP. I think it worked for the webmail & webapi, but the smtpserver didn't allow the "message from" address to be used as smtp mail from address. But that is what mail clients, like thunderbird do.

As for the first feature request: I think that is already addressed with the AllowMsgFrom setting in the alias: It only allows members to use the address as message from. See https://www.xmox.nl/config/#cfg-domains-conf-Domains-x-Aliases-x-AllowMsgFrom

The second point about the noreply is not possible yet. I want to implement it, but need to find the time...

@Robby-
Copy link
Author

Robby- commented Jan 22, 2025

Thank you for that fix, I'm using it now and it works. :) I made an account with a not so obvious name/address and then added the noreply@ alias to it and to my own account.

Having thought about this a bit more, is it actually a good idea to bounce mails to a noreply@ address? For reputation purposes, that is.

Also, how do separate email servers handle a case where 2 email addresses bounce off each other? A quick internet search seemingly yields no useful results.

Wondering because I am considering to just disable PostPublic for the noreply@ alias as normally no incoming mail should come to this address anyway but on occasion people do make typos in their address that we should send to, and if that bounces back, and we bounce that back again...

@mjl-
Copy link
Owner

mjl- commented Jan 23, 2025

Having thought about this a bit more, is it actually a good idea to bounce mails to a noreply@ address? For reputation purposes, that is.
Also, how do separate email servers handle a case where 2 email addresses bounce off each other? A quick internet search seemingly yields no useful results.

I don't think machines will commonly use signals like this for reputation purposes.
As a human, when I get messages with noreply@ senders, that does lower the reputation of that party a bit for me personally. It's funny, because many organizations (also with "noreply" approaches) often try hard in other ways to get into contact with their users/customers.
For normal sending, you indeed need to accept email on your address to receive bounces. At least to receive DSN messages with delivery failures coming from some other mail server along the way. If mox can't get the message out of its queue, it will just put the DSN into the mailbox of the sending account, not doing a normal delivery.
However, when you send a message to an alias (list), your address is used as SMTP MAIL FROM address (it will be different from the message From header). And remote systems that need a bounce message (DSN), will send it to that SMTP MAIL FROM address, i.e. to your inbox. It's just that newly composed messages by the recipient of the message with the "From: noreply@"-header wouldn't be accepted.
Btw, there is also no risk of getting into loops of bounce messages. The bounce is sent back to the original "SMTP MAIL FROM" address in the "SMTP RCPT TO" address, but that SMTP transaction itself uses the empty address as SMTP MAIL FROM, so any bounces of bounces would be dropped instead.

So, once it's possible to configure this in mox, you could still send with a message From header with noreply@ address, you would receive bounces, but replies by receivers will come back to the receivers. But it may be better for users if they can just reply to messages. I'm wondering what your experience is with unwanted replies. Are they accidental? Do they raise many nonconstructive questions? Do you get more spam on your address because it is present in so many accounts (that get compromised)?

@Robby-
Copy link
Author

Robby- commented Jan 23, 2025

Are they accidental?

Yes, it happens once in a while from people who haven't got a clue what they're doing.
And sometimes they are bounces due to nonexistent email addresses (either due to a typo or intentional).

Do they raise many nonconstructive questions?

From users? Not really. The only concern I myself have now is that any replies to noreply@ will now fill up disk space on that separate account I had to make. I did not want to outright add noreply@ to my own account as that would have required me to setup /etc/moxsubmit.conf with my own account credentials. I now have to remember to log in to that other account once in a while to delete the emails there.

Do you get more spam on your address

Luckily no.

@mjl-
Copy link
Owner

mjl- commented Jan 24, 2025

Thanks.

I am considering to just disable PostPublic for the noreply@ alias

Yeah, this should solve the problem. People will get an error like this:

550 5.7.2 not allowed to send to destination

As mentioned earlier, any bounces should still make it to you as actual sender.

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

No branches or pull requests

2 participants