[GH-ISSUE #1298] Send-From / Send as ... Auto-Alias #620

New issue

Open

opened 2026-02-25 21:35:31 +03:00 by kerem · 4 comments

kerem commented

2026-02-25 21:35:31 +03:00

Owner

Originally created by @cptsanifair on GitHub (Oct 23, 2024).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/1298

🚀 Feature

It would be great if i can send mails from different alias-adresses.
As next it would be famouse if there is a alias-detection ;)

Generaly i use a catch-all configuration and use different mail-adresses for the most cases.
So if i reply it would realy helpful to write back over a alias.

As ex:

Incoming:
from support@supplier.tld
to supplier.tld@mydomain.tld

If i answer i want to write from: supplier.tld@mydomain.tld to support@supplier.tld.

Originally created by @cptsanifair on GitHub (Oct 23, 2024). Original GitHub issue: https://github.com/cypht-org/cypht/issues/1298 ## 🚀 Feature It would be great if i can send mails from different alias-adresses. As next it would be famouse if there is a alias-detection ;) Generaly i use a catch-all configuration and use different mail-adresses for the most cases. So if i reply it would realy helpful to write back over a alias. As ex: Incoming: from support@supplier.tld to supplier.tld@mydomain.tld If i answer i want to write from: supplier.tld@mydomain.tld to support@supplier.tld.

kerem commented

2026-02-25 21:35:31 +03:00

Author

Owner

@marclaporte commented on GitHub (Oct 23, 2024):

Use case: mail alias for a specific supplier. Ex.: supplierABC@example.org is to deal with all my interactions with that supplier. It is an alias of purchases@example.org. This works fine for receiving email. But if we need to interact with them (ex.: a support ticket by email): our replies from purchases@example.org are not recognized. I typically create different accounts to avoid this issue. And Cypht's unified inbox is very handy to aggregate all these accounts. However, it's annoying to be forced to create accounts to deal with an external party that doesn't have proper web-based ticket system.

So @cptsanifair: I support this feature request :-)

So would this be for the "from" or "reply-to"?
What needs to happen for mail servers to accept a different "from" than currently logged in user?

In Migadu: "This is what the Migadu Wildcard Sending option is for. It grants specific mailboxes the super powers to impersonate any address on the same domain. The user however still has to authenticate with the SMTP using the mailbox credentials. Mailbox identities do not inherit this right."
https://migadu.com/guides/wildcard/

@marclaporte commented on GitHub (Oct 23, 2024): Use case: mail alias for a specific supplier. Ex.: supplierABC@example.org is to deal with all my interactions with that supplier. It is an alias of purchases@example.org. This works fine for receiving email. But if we need to interact with them (ex.: a support ticket by email): our replies from purchases@example.org are not recognized. I typically create different accounts to avoid this issue. And Cypht's unified inbox is very handy to aggregate all these accounts. However, it's annoying to be forced to create accounts to deal with an external party that doesn't have proper web-based ticket system. So @cptsanifair: I support this feature request :-) So would this be for the "from" or "reply-to"? What needs to happen for mail servers to accept a different "from" than currently logged in user? In Migadu: "This is what the Migadu Wildcard Sending option is for. It grants specific mailboxes the super powers to impersonate any address on the same domain. The user however still has to authenticate with the SMTP using the mailbox credentials. Mailbox identities do not inherit this right." https://migadu.com/guides/wildcard/ Related: https://stackoverflow.com/questions/4728393/should-i-use-the-reply-to-header-when-sending-emails-as-a-service-to-others

kerem commented

2026-02-25 21:35:31 +03:00

Author

Owner

@cptsanifair commented on GitHub (Oct 31, 2024):

@marclaporte for me it will be helpful to answer as "to:" from the origin mail.

So i can response as supplier.tld@... if i get a mail to this address.

@cptsanifair commented on GitHub (Oct 31, 2024): @marclaporte for me it will be helpful to answer as "to:" from the origin mail. So i can response as supplier.tld@... if i get a mail to this address.

kerem commented

2026-02-25 21:35:31 +03:00

Author

Owner

@myuseraccount commented on GitHub (Apr 21, 2025):

I would love this feature! I don't have any brilliant ideas for distinguishing or handling whether the server allows arbitrary sender addresses in the email besides the authenticated username; maybe just having to check a box in settings when adding the SMTP server, saying "any sender allowed on this domain" or something to that effect, might do the trick?

I'm not sure this would work with all email services, but it may be possible with most, even if they don't accept an envelope sender to differ from the SMTP authenticated user, to have the X-sender be the actual user but set From: to a different address at that domain. As an example, I know Gmail will let you send as another address once you've validated that you can receive mail at that address, forwarded to Gmail or not. But I think they require you to enter credentials for a different outgoing SMTP server for that to work in Gmail.

@myuseraccount commented on GitHub (Apr 21, 2025): I would love this feature! I don't have any brilliant ideas for distinguishing or handling whether the server allows arbitrary sender addresses in the email besides the authenticated username; maybe just having to check a box in settings when adding the SMTP server, saying "any sender allowed on this domain" or something to that effect, might do the trick? I'm not sure this would work with all email services, but it may be possible with most, even if they don't accept an envelope sender to differ from the SMTP authenticated user, to have the X-sender be the actual user but set From: to a different address at that domain. As an example, I know Gmail will let you send as another address once you've validated that you can receive mail at that address, forwarded to Gmail or not. But I think they require you to enter credentials for a different outgoing SMTP server for that to work in Gmail.

kerem commented

2026-02-25 21:35:31 +03:00

Author

Owner

@marclaporte commented on GitHub (Oct 30, 2025):

I know @circlecode is also interested here :-)

@marclaporte commented on GitHub (Oct 30, 2025): I know @circlecode is also interested here :-)