choose MTA

Well, if sendmail can do that, that's great I guess -- it means it's still viable for a complete mail-domain setup. Whether you want to use it is a different question and mostly a matter of personal taste regarding how you configure it.

I never used milters, as exim doesn't support them (unless that changed recently, but I don't think so?). You might count this as a shortcoming of exim, as milters seem to be a very flexible mechanism allowing all sorts of complex setups.
 
I do not understand from where come the doubts. From all those trying to make it bad?
For all those who moved away from it after realizing other MTAs can avoid the huge PITA sendmail configuration is, there's nothing to "make" bad. Yes, this is a matter of taste, and there's nothing wrong with actually liking the way sendmail is configured, just be aware many people don't like it ;) Then of course, if you stopped following sendmail's development, how should you know there are solutions for more recent issues like e.g. rejecting spam during SMTP dialog? As I said, it's of course a good thing this is possible with sendmail.
 
...
I don't see a need for an SPF record to *receive* mail.

Me neither. Perhaps it was not clear enough what I said, so I try again. The TXT-SPF record may be the only entry related to mail-sending in the DNS zone of our mail service. We could even omit this, however, I found out, that big mail providers like gmail use the TXT-SPF entry of your zone for sender validation. For example, I got a backup gmail account, and Test-E-mails to this one without SPF (Subject = Test, and body = Test) land directly into the spam box. Test-E-Mails without SPF and containing some expressive phrases have a bigger chance to go into the inbox, yet not 100 %. Mails with a SPF entry in my DNS zone come through by 100 %.

Now, chances are that one of your peers got a gmail account, and it is usually much quicker to set up the SPF for your zone compared to explain to all of your peers that gmail is evil and wait until they switched to another service (hopefully not hotmail). Your customers, the future girl friend, etc. won't respond in that way, but instead would respond to somebody else who is able to send mails to their gmail account.

An MX pointing to a dynamic IP address will probably work quite well, but there are (minor) risks:
Actually it works very well, and the benefits outweigh the risks.
  • If your MX isn't reachable (either the line is down or the DNS update hasn't reached the sender yet), a sender can't connect to it. This should be treated as a temporary error and the sender should try again later, but I wouldn't count on every sender behaving correctly here. If it's treated as a permanent error instead, some mails might not arrive

No higher risk than is imposed anyway to my mail service because of grey listing. My policy is, not to accept mails from misbehaving senders.

  • Worse (and, of course, much less probable) would be a scenario where an SMTP service is actually reachable on the IP address you owned earlier, and this service accepts unencrypted connections, and the sender accepts that as well. In that case, a mail addressed for your domain could end up on an unrelated system.
Therefore I'd argue the best solution is using a server with static addresses for receiving as well -- this server *could* just act as a gateway, like in my setup :)

I thought about it, however my risk assessment told me that this one is negligible. My dynamic IP changes only on power outages for more than 15 min, which rarely happens. Nobody can count on this. If somebody else got by accident a mail service running on a dynamic IP in my region, which is not secured against relaying arbitrary mails to local receivers, then he anyway won't find the message to me in the thousands of spam mails in his box. Or even worse, if that service is not secured against relaying to a wider audience in the internet, then the message would finally reach me :cool:

The benefits are:
  • this is the most cost-effective way of hosting the own mail service that I can think of:
    - the SMTP receiver (incoming mails) is listening on my home server and without extra costs on a connection which is payed anyway.
    - the SMTP relay (outgoing mails) is part of the domain hosting package at quite a low cost.

  • its is quite easy to obtain a let's encrypt certificate for an IP of a server which is under your control and where you can run the certbot, e.g. no DNS fiddling before and after is necessary.

  • all local transactional mails (intra domain) are truly end-to-end encrypted even though only transport encryption is involved.

  • all mails are stored on your server in-house, and we may securely use IMAP instead of POP3+Removing mails from the server.

  • most incoming business e-mails are secured from eavesdropping as well, because bigger companies use their own outgoing mail services and these do contact directly my incoming mail service (I can see this in the server log).

  • In my case, the only point left of possible interception is the mail relay at the domain hosting service. I know this and I act accordingly.
In 2018, I wrote a BLog post about my setup with all the details, including webmail:

Home Mail Server with TLS and non-Plaintext Authentication
 
Last edited:
obsigna, Zirias,

see:
Or here: http://www.postfix.org/MILTER_README.html

Milters were introduced by sendmail, not by postfix or something else. And also something like "FEATURE(dnsbl, `zen.spamhaus.org')dnl" in the mc file causes rejection connection level.
OK, I appreciate that Sendmail is capable of filtering mails before-queue by the way of milters. With respect to Postfix, milters belong to the Sendmail compatibility layer, and Postfix users without Sendmail history don't need it. I acknowledge that milters are executables which we may choose from the now dead list (www.milter.org - mostly perl) or need to program ourselves using the milter API. Since p5 is right after m4 the second least language which I would choose for programming, I know from milters nothing more than these do exist.
 
obsigna Maybe there's still a bit of misunderstanding as from the benefits you list, only the one about cost counts when compared to my solution :)

The MTA on my VPS acts as a spam-scanning (inbound) and DKIM-signing (outbound) gateway only. I have a second MTA in house that handles all local mail without ever reaching out to the gateway, and mailboxes are stored locally as well. My local DNS will resolve the name of the mail machine to my local installation, but if you're outside, you can still access IMAP through the gateway (which also has a dovecot in proxy-mode), using the same DNS name.

Yes, you're right, the risks I talked about are very small ;) So, in a nutshell, receiving mail on a "dynamic" IP-address still works (as opposed to sending from, which didn't work any more for many years). Just saying it might not be the perfect approach :)
 
Now looking a little bit closer into that, it appears to me there is no functional benefit in these, there may only be reputational benefit.
SPF seems to prohibit your employees from sending unauthorized mails from their machines, or other people from impersonating your shop. I'm not sure where the benefit would be for an individual - e.g. if somebody tries to impersonate me, it would probably be rather to their own detriment. ;)
SPF records also help prevent the fun afternoon you'll have if a spammer with a list full of hundreds of thousands of stale email addresses decides to use one of your domains in a forged From: header.

And DKIM seems to establish message integrity on the server-to-server link. Now, traditionally, mail is sent in cleartext, and it can be read and tampered with while in transit. So if you don't like that, use an end-to-end encryption.
FWIW, I ran with only an SPF record for years. I took it upon myself to implement DKIM on the fun afternoon when a spammer cracked one of my five users' password and used my little server to send 60K SPAM emails. Google started hating on me pretty hard after that. You're dead on when you say:

The problem here is with the reputational aspect, which means, if you have these features implemented, your sent mails might less likely end in the receiver's spam folder.
Unfortunately, DKIM was not sufficient to restore my reputation. I had to be a good netizen for some weeks. Yahoo! didn't hate on me, for some reason. I've since implemented outgoing mail metering with Policyd2. I don't love it and wonder if it's actively maintained. Do tell if you've found a better alternative.

Edit: Typo
 
obsigna Maybe there's still a bit of misunderstanding as from the benefits you list, only the one about cost counts when compared to my solution :)
...
Of course, and without any doubts most benefits apply also to your setup. Perhaps we can agree on the following statement, which I wrote in my BLog post:

"A fixed IP address is not needed, but doesn't harm either."
 
Last edited:
...
FWIW, I ran with only an SPF record for years. I took it upon myself to implement DKIM on the fun afternoon when a spammer cracked one of my five users' password and used my little server to send 60K SPAM emails. Google started hating on me pretty hard after that.
...
I've since implemented outgoing mail metering with Policyd2. I don't love it and wonder if it's actively maintained. Do tell if you've found a better alternative.

Perhaps not exactly an alternative, but this reduces the attack surface quite a lot. I set up my Postfix MTA to not allow SMTP authentication on port 25, but only on the submission ports 465 and 587, and on which I require TLS encryption while best practices on port 25 is still to only offer TLS. Since my users live in one country only, I also got geo-blocking in place for ports 465, 587, 993, 995 and others by the way of ipfw(8) employing my sysutils/ipdbtools, s. ipdbtools(1).

I frequently check Postfix's server log, and I see tons of authentication attempts on port 25, which are disconnected right away, but I didn't recognize yet any attack attempt on said submission ports.

PS:
I don't allow my users to choose their passwords. Strong passwords are generated by me and informed to the users.
 
PS:
I don't allow my users to choose their passwords. Strong passwords are generated by me and informed to the users.
Yeah, I was lax about that and paid the price. I'm still working on a way to let them change their own passwords, and implementing password complexity checks.
 
I acknowledge that milters are executables which we may choose from the now dead list (www.milter.org - mostly perl) or need to program ourselves using the milter API. Since p5 is right after m4 the second least language which I would choose for programming, I know from milters nothing more than these do exist.

If you google, you find a lot of milters. In the source of sendmail you find a description of the C api for writing your own milters. Perl is a well known and wide used language. Or should sendmail offer the API for the language(s) you like?
 
If you google, you find a lot of milters. In the source of sendmail you find a description of the C api for writing your own milters. Perl is a well known and wide used language. Or should sendmail offer the API for the language(s) you like?
I don't expect anything from Sendmail. I won't use it anyway.
 
Whatever you should use depends on your Requierements.
We have plenty of choices in the Ports.

I have used Sendmail for decades without any major issues.
Maybe I will write a up to date Tutorial for a full MTA setup with FreeBSD.

I was using Postfix only for a year, till I encounter loss of mail in 2006 when spool disk run full.
Modern Postfix should be better. But I did no stress tests on that.

Most milters are written in C, some in Perl, some in Ruby, some in Python.

There are a good number of milters available as ports.

Code:
mail/libmilter
mail/antivirus-milter
mail/archivesmtp
mail/batv-milter
mail/dcc-dccd
mail/dk-milter
mail/enma
mail/mimedefang
mail/milter-bogom
mail/milter-callback
mail/milter-greylist
mail/milter-manager
mail/milter-regex
mail/milter-skem
mail/mimedefang
mail/noattach
mail/opendkim
mail/opendmarc
mail/py-milter
mail/raysfilter
mail/rbl-milter
mail/rmilter
mail/scam-backscatter
mail/sentinel
mail/sid-milter
mail/smfsav
mail/smfsav-devel
mail/spamass-milter
mail/spamilter
mail/spfmilter
mail/vbsfilter
security/amavisd-milter
 
I just found this -https://prefet.ch/blog/2020/email-server/.
Make sure you use a very recent version of Opensmtpd!
021: SECURITY FIX: February 24, 2020 All architectures
An out of bounds read in smtpd allows an attacker to inject arbitrary commands into the envelope file which are then executed as root. Separately, missing privilege revocation in smtpctl allows arbitrary commands to be run with the _smtpq group.
 
I try to use my own mail server few years ago.
But the concept is too over engeneering for me.
I really don not understand how this can be that hard.
A lot of concept in MTA/MUA exist in our favorite OS.
I do not see why no mail server use user OS for authentification, ssh for network auth and encryption, db for database, linking an output to a filter script is basically a |.
It seems like an old race to features that end with complexity...
I mean if you only want to use a mail server for 10 users in a «family» domain name, why proposed tools are multiplateform, multi configurable, multi... complex ?
I understood the need of complex things. But I do not find a light mail server that use OS features when the paradigm exist in OS.
 
I try to use my own mail server few years ago.
But the concept is too over engeneering for me.
I really don not understand how this can be that hard.

Email is very old, older as internet and uucp, and it is something simple. I think the (not completely satisfactory) adaption to modern use makes it complicated. It is too late to invent a secure and viable alternative.

UW imap server, that was in the source of pine mail client and still is in the source of alpine client, ran out of the box and the authentication was the one of the system. Ideal for small installations. You had client and server for reading remote mail. Unfortunately the server is since years not anymore mantained. It would be nice to awake it.

The authentication in the MTA is for relaying mail, and who relays is normally not necessary a system user. sendmail uses cyrus sasl that offers many authorization mechanisms and may use plugins for getting the password, for example from pam or getpwent and hence the system. But yes, configuration of MTAs is not trivial, not out of the box. To understand sasl needs a little of study.
 
Setting up a mail server is fairly easy. Learning how to set one up can be hard. Even then, the most difficult parts are two things: handling spam and getting your mail accepted by other mail servers.

You can liken setting up a mail server to setting up any other server. You can get it to just work or you can get it to work properly. Some study and thinking and time will be involved but it shouldn't be to the point where one needs to never try or just throw in the towel.
 
Dovecot uses system users quite happily. The following works nicely on Freebsd:
Code:
userdb {
  driver = passwd
}
passdb {
  driver = pam
}

Don't be confused by the "BSDAuth" password database. It's only needed for Openbsd. There are no scary suid binaries now that you can use LMTP for mail delivery.

I used UW-IMAP years ago, and it started having trouble once my mailbox grew to tens of thousands of messages. I suspect it was because of the mbox format it uses (used?) for mailbox storage. All your messages are stored in a single file. Every folder gets its own file, though.

I agree that running your own Mail Transfer Agent (MTA) is probably too complex for most people. You could take the approach Ralphbsz recommends upthread
I use a very simple MTA on my home server, namely ssmtp, which is minimally configured to send all mail to a real commercial mail host outside, done.

Here's the entire Jinja2 template I use to configure Dovecot on Freebsd, in case you're interested:
Code:
ssl = yes
ssl_cert = </usr/local/etc/ssl/mail.{{ domain_name }}.cert
ssl_key = </usr/local/etc/ssl/private/mail.{{ domain_name }}.key
mail_location = mdbox:~/mdbox
userdb {
  driver = passwd
}
passdb {
  driver = pam
}
auth_mechanisms = plain login
service auth {
  unix_listener /var/spool/postfix/private/auth {
    user = postfix
    group = postfix
    mode = 0660
  }
}
service lmtp {
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
    user = postfix
    group = postfix
    mode = 0600
  }
}
protocol imap {
  mail_max_userip_connections = 100
}
protocol lmtp {
  postmaster_address = postmaster@{{ domain_name }}   # required
  auth_username_format = %Ln
}

You'll have to replace {{ domain_name }} with your domain, and make whatever changes are necessary for ssmtp(8).
 
When I installed Dovecot, I do not want mysql or psql db installation, so I found a way to use a sqlite db instead..
But I miss this simple way to use the OS users (if a use has the same id in two jails, it is the same user, as I know. I will test that).
I have to experiment that and retry to have my own mail server ... (as I pay the domain with my familly name... )
 
I used UW-IMAP years ago, and it started having trouble once my mailbox grew to tens of thousands of messages. I suspect it was because of the mbox format it uses (used?) for mailbox storage. All your messages are stored in a single file. Every folder gets its own file, though.

Out of the box it supported the mbox that you have in the system. But uw imap had support for many kinds of formats for storing email, including it own, it is perhaps the imap server that supported the most formats.
 
You shouldn't have had to install any SQL database at all. The Freebsd package has no dependencies beyond base, AFAICT.
 
I know its an old thread but i have to say that i have installed Sendmail/Dovecot for my home mail server and i am happy with the result, the sendmail configuration can be tricky at first but it works.
I have used since years Postfix at work and the documentation is simply awful, different configuration parameters that seems to make the same functionality, you can be reading some parameter documentation for 30m and you dont know what is talking about, finally you have to search for an example in Google to figure out how it works, its so confusing and frustrating.

I have some articles about Postfix/Sendmail and milters in my webpage, but there are in spanish language, sorry.
https://alfaexploit.com/es/tags/smtp/
 
Please suggest some reputable outbound smtp servers.

There is no need opening a new thread for this request; it's also an MTA.
 
Back
Top