If your real SMTP server is doing fine, nullmailer is possibly the simplest of all smtp relay packages available.
Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
I found a nice Ansible role for nullmailer, but found that it is not packaged for Fedora, but msmtp and ssmtp are. I think I may try ssmtp next. Despite its unmaintained status, somewhow it's packaged and nullmailer isn't.
ssmtp is what I've used before.
@atzanteol @markstos@lemmy.world
ssmtp is unmaintained.
msmtp is the recommended successor. The Arch wiki recommends also considering OpenSMTPD, which I haven't looked at yet.
I just started using OpenSMTPD as a backup relay and it seems to work for that. Very lightweight and easy to set up.
Ah, thanks
ssmtp is also my go-to for this. Or dma (DragonFly Mail Agent) - if available - which provides a queue in case the delivery to the smarthost fails. But as it's not running as a daemon (saving resources), so you have to setup a regular cronjob to process the queued messages.
I use ssmtp as well for a simple sendmail replacement. It takes over the sendmail command, doesn't open any ports. You configure it for the domain you want and tell it what server to send everything to and it works.
msmtp
never failed me
The one problem with msmtp is that it doesn't rewrite headers, like "From: root / To: root". These are not required for SMTP, but they are required by some mail providers who will reject email that doesn't have an "@" sign in these headers. The author or msmtp has said he does not plan to add this feature.
I worked around the issue with my own sendmail wrapper that rewrites local addresses in From and To headers before passing the message to msmtp. Someone else posted such a script in this bug report:
You can definitely replace senders with correct mail addresses for relaying through SMTP servers that expect them (this is what I do):
# /etc/msmtprc
account default
...
host smtp.gmail.com
auto_from on
auth on
user myaddress
password hunter2
# Replace local recipients with addresses in the aliases file
aliases /etc/aliases
# /etc/aliases
mailer-daemon: postmaster
postmaster: root
nobody: root
hostmaster: root
usenet: root
news: root
webmaster: root
www: root
ftp: root
abuse: root
noc: root
security: root
root: default
www-data: root
default: myaddress@gmail.com
(the only thing I changed from the defaults in the aliases file is adding the last line)
This makes it so all/most system accounts susceptible to send mail are aliased to root, and root in turn is aliased to my email address (which is the one configured in host/user/password
in msmtprc)
Edit: I think it's actually the auto_from
option which interests you. Check the msmtp manpage
In the issue I linked, the msmtp author makes a distinction with changing the envelope recipient, which msmtp can do, with rewriting the email headers like “To”, which msmtp does not do.
https://github.com/chriswayg/ansible-msmtp-mailer/issues/14 While msmtp has features to alter the envelope sender and recipient, it doesn't alter the "To:" or "From:" message itself. When the Envelope doesn't match these details, it can be considered spam
Oh I didn't know that, good to know!
The proposed one-line wrapper looks like a nice solution
After testing ssmtp, nullmailer, and msmtp for relay-only outgoing mail on Fedora #Linux. Here's my final report:
- ssmtp is packaged for Fedora and I got it working, but the Ansible role I found for it had been abandoned by the author because ssmtp itself is unmaintained.
- nullmailer might have worked, but is not packaged for Fedora.
- msmtp worked. I used this Ansible role, after patching it to work on Fedora: https://github.com/chriswayg/ansible-msmtp-mailer
Use a postfix satellite setup. Requires minimal config and provides queues/retries/etc.
Tried that. Yes, it has the feature I need. But it has a rather complex feature set and documentation when I just need to to send my mail to an SMTP server. I ran into problems configuring it for this in the past which were difficult to diagnose due to the volume of config options and docs. That’s what led me to explore tools that had only the features I needed and no more, like msmtp or nullmailer.
Deliverability is hard no matter what software you use. You have to spend a while warming your IP addresses. This is one thing I'd call a hassle to self host. I've been using mxroute.com which is diy friendly and cheap.
I’m not trying to send mail directly from the host, only forward it to a host that’s prepared to send. I’m using Mailgun for that.
You want an SMTP relay. You can use a free public SMTP relay, or make one yourself with something like Postfix. If you make one yourself, don’t keep it open, or spammers will abuse it. If you’re sending mail properly, you’ll need to add it to your SPF entry in your DNS. If you’re just sending mail for yourself, you should be able to set up a filter in your email provider so that it doesn’t get rejected.
You also need to know if outbound traffic is blocked on port 25 by your ISP. Most ISPs block it to prevent spam. If yours is blocked, you can request that they unblock it, but they might not do it. If they don’t, you’re kind of SOL. At that point, you need an account somewhere to send mail through. Then you’d be connecting on port 587 to submit mail.
I have an SMTP server. I need a sendmail binary that does one thing well: send the message to the SMTP server.
Can’t you use sendmail? Also, check out my updated message above. You’ll need to make sure you can send outbound traffic on port 25.
Sendmail is a binary provided by a mail system and no mail system is installed by default on Fedora.
I’m looking for a solution that’s as simple as possible: provide a sendmail binary to pass the message to a third-party SMTP server.
I’ll connect to Mailgun via TLS— no port 25 involved.
Not sure if it's in fedora, but I use nullmail as my mta. Simple to config and does just MTA
Thanks. Turns out it's not in Fedora.
Sendmail is provided by the sendmail
package in Fedora. Here’s some instructions on installing and configuring it:
https://tecadmin.net/install-sendmail-on-fedora/
But you might instead be looking for an SMTP client (or a Mail User Agent), which is different:
https://www.baeldung.com/linux/send-emails-from-terminal
If you have SMTP credentials with Mailgun, and you’re using port 465 or 587, you want an MUA, not an MTA (Mail Transfer Agent).
Sendmail can be both, but there are better tools if you’re looking for an SMTP client.
Sendmail is a full-blown MTA released 41 years ago that is notoriously difficult to manage. There are reasons that it's market share has declined from 80% to about 3%. I'm also not looking for a MUA, like mutt. I'm looking for a simple MTA that that only relays outbound mail, like msmtp, ssmtp or nullmailer.
Again, if you are not using port 25, you don’t need an MTA. Period.
MTAs are for sending mail from one mail server to another. That’s not what you are doing. You don’t need to be running your own mail server. You are sending mail to an MSA (Mail Submission Agent). Mailgun is the MSA you are submitting to and the MTA that will handle transferring your message to your destination MDA (Mail Delivery Agent).
If you were submitting mail to your destination server over port 25, you would need an MTA.
But, as you stated, you are submitting mail to an MSA using port 465 or 587. You need an MUA.
This terminology is important, because it determines what role the software you’re using plays and how you need to configure it.
There are plenty of tools that act as both MTAs and/or MUAs depending on how you configure them, because their functionality is very similar. I would guess nearly all tools that can do one can do the other. But if you want to use the right tool the right way, I am telling you, with 100% certainty, you should be looking for an “SMTP client”, “email client”, or “mail user agent” (they mean the same thing). You do not want a relay server, and you do not want an MTA.
What you probably mean by what you’re asking is something that receives mail addressed locally (acting as an MSA or an MDA), and fowards it (important: this is not the same as relaying, because the destination address is changed) to an MSA (therefore acting as a MUA). If something is forwarding mail like this, instead of relaying, and calling itself an MTA, that is not technically correct. But you probably don’t need that, unless you’re using something that won’t let you configure how/where it sends mail. You just need to set up something that provides a binary that acts as an MUA. Then set up your daemons to send mail to your actual email address using that.
I’m speaking from experience because I’ve written both an MTA and an MUA, but if you won’t take it from me, take it from Wikipedia:
An MTA works in the background, while the user usually interacts directly with a mail user agent. One may distinguish initial submission as first passing through an MSA—port 465 (or, for legacy reasons, optionally port 587) is used for communication between an MUA and an MSA, while port 25 is used for communication between MTAs, or from an MSA to an MTA.[5]this distinction is clarified in RFC 8314.
I need a sendmail binary that sends outgoing mail to an SMTP server with as few other features as possible.
It has been a while since I touched ssmtp, so take what I'm saying with a grain of salt.
Problem with ssmtp and related when I was testing it was its behaviour in error conditions - due to a lack of any kind of spool it doesn't fail very gracefully, and if the sending software doesn't expect it and implement a spool itself (which it typically doesn't have a reason to, as pretty much the only situation where something like sendmail would fail is a situation where it also wouldn't be able to write a spool) this can very easily lead to loss of mails.
I already had a working SMTP client capable of fishing mails out of a Maildir at that point, so I ended up just doing a simple sendmail program throwing whatever it receives into a Maildir, and a cronjob to send this forward. This might be the most minimalistic setup for reliably sending out mail (and I'm using it an all my computers behind Emacs to do so) - but it is badly documented, so if you don't care about reliability postfix might be a better choice, or if you don't just go with ssmtp or similar. Or if you do want to dig into that message me, and I'll help making things more user friendly.
Thanks. This is just for forwarding from mail and the like, so occasional loss of mail due to lack of spooling could be tolerated.
Postfix.
I use proxmox mail gateway (PMG) for my homelab, configured to relay through my Gmail domain using smtp auth.
I've also used PMG at the enterprise level. Never had an issue with it.
It's postfix underneath.
I run Mailcow-dockerized for my mail server and internal relay, and it's a postfix based system. Never have any issues with it.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
Fewer Letters | More Letters |
---|---|
DNS | Domain Name Service/System |
IP | Internet Protocol |
SMTP | Simple Mail Transfer Protocol |
SSL | Secure Sockets Layer, for transparent encryption |
TLS | Transport Layer Security, supersedes SSL |
4 acronyms in this thread; the most compressed thread commented on today has 11 acronyms.
[Thread #679 for this sub, first seen 15th Apr 2024, 00:35] [FAQ] [Full list] [Contact] [Source code]