choose MTA

[hruodr]

and you can fine-tune it to ridiculous levels, which in today's world are just not practical.

Yes, it have features for the past. Have you seen how big are the sources? Much more unpractical is to install bloat that do much less.

 

[PMc]

DNS: good experience with https://www.ovh.com

Whats that? The only information I get on that page is that they want my money, and lots of it. They don't even bother to make up a reason why.

 

[rootbert]

Whats that? The only information I get on that page is that they want my money, and lots of it. They don't even bother to make up a reason why.

well ... the website of OVH. Its the largest hosting provider in Europe and owns the worlds largest datacenter surface area. I primarily did some testing with their infrastructure because they appeal to me and my idealism - they hosted wikileaks and are sponsoring letsencrypt. I was very satisfied with their performance, support and price ... and they have had a nice API before having an API was more or less standard.

concerning DNS: you can have a free account and use their DNS for free; upgrade to DNS anycast for 1€ per domain per year.

 

[Lamia]

Actually, the two statistics look remarkably similar. In the last 10 years, on average less than 1 vulnerability per year. I don't think I care what happened in the early 2000s, because I don't run a version from the early 2000s.

And actually, editing the sendmail.cf file is perfectly doable. I personally think that the M4 files are less readable, and you're better of using the m4 framework as a starting point, and then reading, understanding, and editing the .cf files instead. But clearly, sendmail is very hard to configure, because if relies heavily on the .cf language as an actual execution mechanism, not just a configuration mechanism. And that is what makes the .cf files so overwhelming, and complex looking: you're de-facto looking at the source code of sendmail here, and you can fine-tune it to ridiculous levels, which in today's world are just not practical. I mean, who would want to use the configuration for encapsulating uucp addresses over bitnet? While the .cf files are capable of doing that (BTDT), it is just not needed today.

Which leads me to my personal conclusion: I use neither postfix nor sendmail. 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.

Yes, ssmtp was what I meant when I wrote smtpd. It is a perfect drop-in replacement for Sendmail, not on par with Postfix though.

 

[PMc]

Thanks for the explanation.
I am actually quite bored about all those webpages that only tell you what kind of payment they want.

well ... the website of OVH.
Its the largest hosting provider in Europe

Never heard of. But that's maybe because I have no use for hosting, neither would I have money to pay for such.

you can have a free account and use their DNS for free

I happen to have my own DNS, and wouldn't like to have someone else run it, free or not free.
The only thing I would be interested to obtain is reverse-resolving static IPs. And that's a more difficult thing, and seems only available in package with hosting.

 

[Lamia]

Thanks for the explanation.
I am actually quite bored about all those webpages that only tell you what kind of payment they want.



Never heard of. But that's maybe because I have no use for hosting, neither would I have money to pay for such.



I happen to have my own DNS, and wouldn't like to have someone else run it, free or not free.
The only thing I would be interested to obtain is reverse-resolving static IPs. And that's a more difficult thing, and seems only available in package with hosting.

Your ISP can do that for you.

How do manage you DNS entries?

 

[PMc]

Your ISP can do that for you.

Yes, they can, and that might actually work. But then at least they require a business account to do so, and probably a registered domain, so that should cost about 250€ extra per year.
Getting a very small hosting entity that does not much else than run a vpn server to move that IP to a place where I can use it, might be in a similar cost range.
So that is a bit of money, and what I do not have is spare money. Also the issue is not imminent, as currently I happen to have a static IP, but v4 only, and it appears not to be a very good one, i.e. routing my default traffic via that and then doing web shopping can lead to my credit card being blocked.

How do manage you DNS entries?

Currently not at all. Currently that DNS serves my intranet configurations and goes to the responsible servers for anything else. It is configured to do split-horizon, but currently there is no need to do so, and I use that only for some ad-blocking.

 

[Lamia]

Yes, they can, and that might actually work. But then at least they require a business account to do so, and probably a registered domain, so that should cost about 250€ extra per year.
Getting a very small hosting entity that does not much else than run a vpn server to move that IP to a place where I can use it, might be in a similar cost range.
So that is a bit of money, and what I do not have is spare money. Also the issue is not imminent, as currently I happen to have a static IP, but v4 only, and it appears not to be a very good one, i.e. routing my default traffic via that and then doing web shopping can lead to my credit card being blocked.



Currently not at all. Currently that DNS serves my intranet configurations and goes to the responsible servers for anything else. It is configured to do split-horizon, but currently there is no need to do so, and I use that only for some ad-blocking.

Ok. Thanks. The closest I have got is setup a primary nameserver with NSD for a domain name outside GoDaddy's jurisdiction and a domain name seller wanting me to buy the Premium DNS manager like GoDaddy.

It worked well. I always had to go edit the text files and that itself can be tricky. Hence, I was hoping there is a TUI that auto-validate entries.

 

[gpw928]

Yes, they can, and that might actually work. But then at least they require a business account to do so, and probably a registered domain, so that should cost about 250€ extra per year.

That cost seems excessive.

My ISP connects my Internet router to a private enclave (10.x.x.x) and from there NATs my traffic to the Internet. I don't really have a choice, as my Internet connection options are somewhat limited (GPRS or Satellite).

I get a new IP address in the private enclave every time I have to re-dial the connection, and have no permanent presence on the Internet, but I can still get:

• a domain name and DNS services from namesilo for ~US$10/annum; and
• a cheap VPS with static IPv4 for ~US$30/annum (located in Sydney, which is the same city as the routers used by my ISP to connect to the Internet).

All I need for a permanent IPV4 presence on the Internet is to nail up a reverse ssh tunnel from my firewall to the VPS for each port I care to open (and open a port on the separate firewall provided with the VPS).

I have used Namesilo for domain and DNS services some years, and have zero complaints.

The VPS has only to carry network traffic, and can be sized accordingly.

I get all that for US$40 per annum.

 

[Lamia]

That cost seems excessive.

My ISP connects my Internet router to a private enclave (10.x.x.x) and from there NATs my traffic to the Internet. I don't really have a choice, as my Internet connection options are somewhat limited (GPRS or Satellite).

I get a new IP address in the private enclave every time I have to re-dial the connection, and have no permanent presence on the Internet, but I can still get:

• a domain name and DNS services from namesilo for ~US$10/annum; and
• a cheap VPS with static IPv4 for ~US$30/annum (located in Sydney, which is the same city as the routers used by my ISP to connect to the Internet).

All I need for a permanent IPV4 presence on the Internet is to nail up a reverse ssh tunnel from my firewall to the VPS for each port I care to open (and open a port on the separate firewall provided with the VPS).

I have used Namesilo for domain and DNS services some years, and have zero complaints.

The VPS has only to carry network traffic, and can be sized accordingly.

I get all that for US$40 per annum.

I think this implementation is limited to a few services (in-house web hosting, VPN, maybe email and enter&tame&me(-nt) services all bound to one static IP address).

If you need more than one IP, you will be paying $5 or so per each. An ISP would give you a block of 5 usable IPs for $10. And it doesn't ALWAYS have to be a business account to be qualified for it.

 

[Lamia]

This is a million dollar question.
Given that you're just getting started, Sendmail might be a good start. Postfix is quite advanced. You can also take a look at OpenSMTPD.

I just found this -https://prefet.ch/blog/2020/email-server/.

 

[PMc]

That cost seems excessive.

Not really. Its a business account, so you get whatever features telco think a (small) business might need, probably also priority customer service and similar, and optionally the static IP - and it's a real static IP in place of the dynamic one, so full bandwidth and MTU and no VPN, and it will resolve forward and reverse. (At least that's what I would expect.)
And then, while the ordinary consumer tariff is at 35€ (for smallest bandwidth - 10Mbit), that one doesn't exist in smallest and then cost some 55€ (not sure if domain reservation is included).

That was easier maybe 15 years ago - then people who would know what a static IP is good for, might just have asked and got a bunch of them - as for the normal consumers a static IP was considered only more dangerous.

• a domain name and DNS services from namesilo for ~US$10/annum; and
• a cheap VPS with static IPv4 for ~US$30/annum (located in Sydney, which is the same city as the routers used by my ISP to connect to the Internet).

I understand. But the cardinal question is: to what does that IP resolve in reverse, i.e. host nn.nn.nn.nn?

As far as I understand: The 'namesilo' shop can make sure that your reserved domain will resolve to your IP, because they own the zonefile for the domain.
But to do it in reverse, from the IP to the domain, one would need to edit the zonefile for the IP-range.
And I have no real idea how the ownership of these reverse zonefiles is managed, and I doubt that it is easy to find somebody willing to edit them.
If anybody knows how that might work, I am really eager to hear.

In fact, for most things one may not need a correct reverse-resolution. And maybe it is possible to get one, and I just don't know.

 

[gpw928]

I think this implementation is limited to a few services (in-house web hosting, VPN, maybe email and enter&tame&me(-nt) services all bound to one static IP address).

Sure the VPS has one static IPV4 address, and as many services as you wish to attach to that address.

If you need more than one IP, you will be paying $5 or so per each. An ISP would give you a block of 5 usable IPs for $10. And it doesn't ALWAYS have to be a business account to be qualified for it.

Additional IPV4 addresses are US$1.2/month each. You pay the money, you get the address. "Business" is not relevant. [There is a limit of 8 IPV4s per VPS.]

I agree it would not be sensible to run a major Internet presence through reverse ssh tunnels.

My major point was that the DNS infrastructure can exist independently of everything else.

 

[gpw928]

I understand. But the cardinal question is: to what does that IP resolve in reverse, i.e. host nn.nn.nn.nn?

I expect that he reverse lookup zone file would need to be with the VPS provider (which has free DNS services).
So I am obliged to modify my claim and observe that "most of the DNS infrastructure can exist independently of everything else".

 

[PMc]

I expect that he reverse lookup zone file would need to be with the VPS provider (which has free DNS services).
So I am obliged to modify my claim and observe that "most of the DNS infrastructure can exist independently of everything else".

That actually doesn't answer my question, and I am agreeing that DNS should be considered an independent service, where TCP/IP is in no way dependent on (while other services may be dependent on both).
But my question simply was: can you configure that reverse lookup to reflect Your actual domain?

 

[Lamia]

That actually doesn't answer my question, and I am agreeing that DNS should be considered an independent service, where TCP/IP is in no way dependent on (while other services may be dependent on both).
But my question simply was: can you configure that reverse lookup to reflect Your actual domain?

He would a dynamic dns service like noip2.

 

[gpw928]

That actually doesn't answer my question, and I am agreeing that DNS should be considered an independent service, where TCP/IP is in no way dependent on (while other services may be dependent on both).
But my question simply was: can you configure that reverse lookup to reflect Your actual domain?

The registered owner of the IP address block has control (delegation) of the reverse lookups for that "block", in the same way as the registered owner of a domain has control (delegation) of forward lookups for that domain.

How the reverse lookups are managed depends on the owner of the IP address "block".

If you have not got a reverse delegation (which puts you in complete control), then the most sensible approach is to get the ISP who owns the "block" to create the PTR record in the appropriate in-addr.arpa zone file.

I expect you may get some level of control over that (web edit interface), depending on your ISP, or it may be a helpdesk call.

I don't believe you can get a PTR record published unless you have a static address. i.e. no-ip.com can't assist with this problem, and nor can third party DNS providers like namesilo (unless you got your IP address from them).

 

[PMc]

He would a dynamic dns service like noip2.

Maybe - but that's quite certainly not what I want.

This is an example for what I do NOT want:

$ host forums.freebsd.org
forums.freebsd.org has address 204.109.59.195
$ host 204.109.59.195
Host 195.59.109.204.in-addr.arpa not found: 3(NXDOMAIN)

This is good for web servers (and most web hosts will show such or similar, because of the way they are hosted), but it is NOT good for mail. For mail it should look like this:

$ host mx1.freebsd.org
mx1.freebsd.org has address 96.47.72.80
host 96.47.72.80
80.72.47.96.in-addr.arpa domain name pointer mx1.freebsd.org.

 

[zirias@]

For setting up an email domain correctly, you need at least

• a static IPv4 address
• configurable reverse lookup for that address
• a way to configure records (A, MX and TXT for SPF/DKIM) in your domain's zone

You get all this from your typical VPS hoster. In my case, I pay a little less than 100€ per year for it, but the server is capable enough to run some services as well, so I think that's fair.

I don't want to just forward TCP ports to my home server -- the connection could be interrupted for example. What I do is

• my home server establishes a VPN tunnel to the VPS.
• there's a complete mail system on my home server (with exim/dovecot).
• the VPS acts as a mail gateway for SMTP and IMAP, again with exim (where "local" delivery is configured to use remote SMTP with a manual route to my home server plus recipient verification to know which users actually exist, and the home exim has a manual route to the VPS for everything outbound) and dovecot in proxy-mode.
• To route everything correctly with SMTP, I use some overrides in /etc/hosts.
• The VPS does spam scanning (with rspamd) and DKIM signing.

So, in case my internet connection at home will be broken, the gateway will just either temporarily reject mails (if the recipient isn't known) or enqueue the mails for valid recipients it has cached, until my home server is available again.

For services other than mail, it's much simpler -- I just do some DNS updates per script when the VPN tunnel comes up, basically creating my own simple "dynamic DNS" service.

 

[drhowarddrfine]

Which leads me to my personal conclusion: I use neither postfix nor sendmail. 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.

Well, then you're just not one of the cool kids.

 

[obsigna]

I chose Postfix over Sendmail because it can be configured with plain text configuration files consisting of not too hard to understand keyword/value pairs. For me, M4 is already the show stopper of Sendmail. If it weren't, Postfix comes with lots of before-queue filter mechanisms which Sendmail does't seem to have, I see only some throttles, and so I would be forced to do spam fighting after queue - I would happily like to learn otherwise, though.

Before queue means, the mail message was not yet dropped into my camp of responsibility, and I may block it and are done. After queue means, the message has landed, and it is my responsibility to do the right thing about it, i.e. either of forwarding it to the destined receivers or return it to its origin. Therefore, after-queue mail filtering would quickly become a PITA, since I want to do it correctly. Blocking a mail after queue without anything further is only acceptable if the server's admin is the only valid receiver of the system. Already in SOHO installations after-queue filtering would be subject of privacy regulations, while before-queue filtering would usually not come near to this one of the most ugliest of Pandora's Boxes.

Finally, you want to read the opinions about the requirements of a static IP-Address, respective A, PTR records and an open outgoing port 25 only with having mail sending in mind.

While it is true that the SMTP sender's static IP should have valid A, PTR and in addition TXT-DKIM entries, it is not at all necessary that this all belongs to the DNS zone for which you provide your mail service. Huge parts of today's mail traffic goes via mail relays, and not directly from end to end. And this won't work under the requirement that the A and the PTR should belong to the DNS zone of the originating sender.

For receiving mails, all this is not needed. You need valid MX and TXT-SPF records in your DNS zone and the MX might even point to the dynamic IPv4 or IPv6 address of the SMTPd in your home. This is what I do, and for mail sending I use a plain mail package of the domain hoster as a mail relay. My Postfix installation passes outgoing mails on the submission port 587 to said relay, which then takes care of the final delivery. This works perfectly well.

Since many people are confused about the scope of the MX and TXT-SPF records, it is worth to emphasize it again, MX is for INCOMING mails, and TXT-SPF can be the only entry in your zone which tells something about OUTGOING mails.

 

[Jose]

My hosting provider allows me to manage my own PTR record:

Frequently Asked Questions (FAQ) - PrgmrWiki

wiki.prgmr.com

 

[PMc]

While it is true that the SMTP sender's static IP should have valid A, PTR and in addition TXT-DKIM entries, it is not at all necessary that this all belongs to the DNS zone for which you provide your mail service. Huge parts of today's mail traffic goes via mail relays, and not directly from end to end. And this won't work under the requirement that the A and the PTR should belong to the DNS zone of the originating sender.

You're right. If you send a mail to the internet, that sending interface does have an IP address. And then there should be a PTR record resolving that IP address to a hostname. And when then again looking up that hostname, one should get the same IP address.
This is usually even true for dynamic IPs, so one can in principal send mail from dynamic IPs, only one cannot easily receive.

For receiving, the host part of the address needs to be translated to an IP address. And while an ordinary A record should theoretically be enough to achieve that, it does not work in practice, because some mailers do look only for MX records (which is imho wrong, but definitely the case).

So, to receive mail one needs a static IP (I don't think a dyndns-MX does count along "best practice"), and to send mail one needs a PTR record (reverse resolution) on that IP. And ideally the latter would point back to something sensible.

Now I would like to thank all the participants here, because I learned a couple of new things. The last time I was involved in mailers, there was no SPF and DKIM and whatever, and when I heard of that, it appeared to be of concern mainy to contractual spam distributors (aka bulk mail senders).

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.
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.

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.

As it seems, I do currently have neither an idea about how the state of these things is with my sent emails, nor a means to easily configure it, so this might be one reason why my mails are often not reacted upon. (Another is that people nowadays quite openly state that they neither read nor answer their mails, as they have facebook.)

So, maybe, as I have now finished reinstalling my backup software (28 bugs identified in the port), I should setup a new mail system...

Thanks again, this was helpful.

 

[zirias@]

Before queue means, the mail message was not yet dropped into my camp of responsibility, and I may block it and are done. After queue means, the message has landed, and it is my responsibility to do the right thing about it, i.e. either of forwarding it to the destined receivers or return it to its origin. Therefore, after-queue mail filtering would quickly become a PITA, since I want to do it correctly. Blocking a mail after queue without anything further is only acceptable if the server's admin is the only valid receiver of the system. Already in SOHO installations after-queue filtering would be subject of privacy regulations, while before-queue filtering would usually not come near to this one of the most ugliest of Pandora's Boxes.

Completely agreed (except for I have no idea whether it can be done with sendmail in a sane way, having abandoned sendmail a *long* time ago).

I would still add a bit of explanation here, we're getting near the point where this thread becomes a complete mail-exchange FAQ

Normally, an MTA will enqueue a mail as soon as it sends out the final "success" reponse to the sender after receiving the actual mail with DATA. So, correctly rejecting a mail after that would require sending out a bounce message. That's where the problem with spam mail starts, as the MAIL FROM address is typically forged, so your bounce would be sent to some unrelated party -- you would cause "backscatter". Therefore, the other option would be to violate RFCs and just silently drop the mail you already accepted. But then, in the case of some "false positive", the sender will never know his mail didn't arrive. As soon as you provide your mail service to users other than yourself, this is a problem as you could be held reliable for just dropping your users' mails.

Therefore, the only sane way to reject spam mails is to do it before actually accepting them. If sendmail really can't do this, it would be unusable today.

While it is true that the SMTP sender's static IP should have valid A, PTR and in addition TXT-DKIM entries, it is not at all necessary that this all belongs to the DNS zone for which you provide your mail service. Huge parts of today's mail traffic goes via mail relays, and not directly from end to end. And this won't work under the requirement that the A and the PTR should belong to the DNS zone of the originating sender.

Let's break this down a bit, so we're only talking about sending mail:

• Valid A and PTR records are needed for the actual machine sending the mail to the receiver's MX. So, if you use a relay, it isn't your responsibility.
• If you want to use SPF, you still need to create the TXT record for your sending domain (the one that is used in "MAIL FROM:"). You have to allow your sending relay there.
• For DKIM, as far as I understand it (correct me if I'm wrong), you *could* leave that entirely to your relay. The relay will then sign the message using its own domain and key, which should be fine. But if you want to use DMARC as well, the DKIM signature domain must match your sending domain, so you would be required to do your own DKIM signing, which again includes publishing a TXT record on your domain.

For receiving mails, all this is not needed. You need valid MX and TXT-SPF records in your DNS zone and the MX might even point to the dynamic IPv4 or IPv6 address of the SMTPd in your home.

I don't see a need for an SPF record to *receive* mail. An MX pointing to a dynamic IP address will probably work quite well, but there are (minor) 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
• 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

 

[hruodr]

obsigna, Zirias,

see:

Milter - Wikipedia

en.wikipedia.org

An MTA that is milter-capable instead notifies filters to which it is connected about each phase of the delivery of a message, from initial client connection through completion of transmission. At each phase of the SMTP session, the filter is given data about the arriving message and then has an opportunity to terminate acceptance of the message early when appropriate. For very large messages, this can have an enormous impact when a decision to reject can be made as early as possible.

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

Postfix implements support for the Sendmail version 8 Milter (mail filter) protocol. This protocol is used by applications that run outside the MTA to inspect SMTP events (CONNECT, DISCONNECT), SMTP commands (HELO, MAIL FROM, etc.) as well as mail content (headers and body). All this happens before mail is queued.

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.