# Mail server: Restrict Postfix and Dovecot to one user

## m_a_xim

Hi,

I need to restrict login (or authentication or whatever you want to call it) to Postfix and Dovecot to only one or two users, at least for non localhost connections.

I've seen that Dovecot uses PAM but I have no idea how that works and Postfix doesn't have a file in /etc/pam.d/.

If there was a simple feature just like AllowUsers for ssh, that would be great, but there doesn't seem to be.

----------

## depontius

I believe you want to look in the docs for both for "virtual users".  I run both, but only with real users in /etc/passwd.

----------

## M

Actually, if you only need one or two users "virtual" is maybe too much, I would just add unix users with /bin/false shell. You need something like this in main.cf :

```
local_recipient_maps = unix:passwd.byname, hash:/etc/postfix/aliases
```

For dovecot configure userdb and passdb. You have a large choice with dovecot, and it can check all of auth methods you configure, not just one of them, passwd, shadow, pam, ldap, sql, even passwd-file.

----------

## m_a_xim

Thanks, 

I noticed that I could even send mail as a non existing user just by putting something_random@my_domain in the "from" email field in my client (Thunderbird).

I tried looking up virtual users and followed the instructions here:

http://www.linuxmail.info/postfix-dovecot-static-db/

but it made no difference.

I also tried your method, M; and I wasn't sure what to do with the aliases file.

I put this in /etc/postfix/aliases:

```

testmail@my_domain testmail

```

where testmail is a valid account and I replaced my real domain with my_domain for the purpose of secrecy (don't want all the spammers to know about my insecure mail server).

And I entered this command: 

```
sudo postmap /etc/postfix/aliases
```

but still no difference.

I checked /var/log/mail.warn but it had nothing new in it.

I've spent hours and hours on this. I don't get why it has to be so complicated.

PS: I did of course do "sudo /etc/init.d/postfix restart" every time.

----------

## magic919

This may not be as complex as it seems.

I presume you want the user to authenticate before Postfix will allow them to relay mail?  Are you saying this did not happen?  Did you try this from the same network as the Postfix machine perhaps?

----------

## m_a_xim

Actually, I found out that I can't send emails outside when I'm not authenticated so that's one good thing at least.

However I still haven't managed to restrict who can login. Could you please be more explicit about your method, M?

----------

## cach0rr0

 *m_a_xim wrote:*   

> Actually, I found out that I can't send emails outside when I'm not authenticated so that's one good thing at least.
> 
> However I still haven't managed to restrict who can login. Could you please be more explicit about your method, M?

 

users on the same local network as the Postfix box will be able to send regardless, assuming you've set up $mynetworks and have permit_mynetworks set in either smtp_client_restrictions or smtp_recipient_restrictions 

from outside, postfix should require auth via SASL (which will be backended either to its own db, or to your passwd users, whatever you've set up). Ideally you should only allow this if the user is connected via TLS (e.g. smtpd_tls_auth_only = yes )

Finally, you want to configure postfix to reject unknown recipients (actually I think the setting may be named just that - reject_unknown_recipients ), so that it rejects mail to non-existent users. 

that should take care of the postfix side of things (again, keeping in mind the caveat about $mynetworks)

As far as Dovecot goes, to backend this to pam, a config like so should do the trick (obviously adjusting paths and file names as necessary)

```

base_dir = /var/run/dovecot/

protocols = imap imaps

listen = *

disable_plaintext_auth = no

shutdown_clients = yes

log_path = /var/log/dovecot.log

ssl_cert_file = /etc/ssl/dovecot/gentoob0x.crt

ssl_key_file = /etc/ssl/dovecot/gentoob0x.key

login_dir = /var/run/dovecot/login

login_chroot = yes

login_user = dovecot

login_process_size = 64

login_process_per_connection = yes

login_processes_count = 3

login_max_processes_count = 64

login_greeting = IMAP ready.

login_log_format_elements = user=<%u> method=%m rip=%r lip=%l %c

login_log_format = %$: %s

mail_location = maildir:~/.maildir 

mail_log_prefix = "%Us(%u): "

mail_log_max_lines_per_sec = 10

protocol imap {

}

  

protocol pop3 {

}

protocol lda {

  postmaster_address = postmaster@whitehathouston.com

}

auth default {

  mechanisms = plain

  passdb pam {

    args = "*"

  }

  userdb passwd {

  }

  user = root

}
```

(I allow plaintext auth, but I block 143 at the firewall, allowing only 993 - internal users I don't care if they go on 143/unencrypted)

the auth{} block is what you need to pay attention to above. Should "just work"

----------

## m_a_xim

Thanks for all your answers.

I now decided to make it all run in a virtual machine (VirtualBox) and it seems to be working although I can't get SSL/TLS to work with postfix for some reason but as long as I can use STARTTLS, I suppose that's okay.

The virtual machine uses 5% CPU constantly; I don't really mind but if there's a way to make it use even less when idle, I wouldn't mind hearing of it. 

Also, when I send an email to a gmail or hotmail account, it gets put in the spam box. I've made an MX domain and everything; so is the behaviour of considering as spam all non well known smtp hosts common amongst the big hosting companies or is there anything I can do about it?

Just a thought: wouldn't it be possible to create some kind of software that automates the creation of a virtual machine that is ready for common tasks such as email, web/blog hosting, xmpp,... that any user could install? This could provide an easy and secure environment for self hosting thus encouraging some people to quit using extremely centralized services such as Google and encouraging a more decentralized Internet more prosperous for net neutrality. (oops... I think I've gone somewhat off-topic here)

----------

## cach0rr0

 *m_a_xim wrote:*   

> 
> 
> I now decided to make it all run in a virtual machine (VirtualBox) and it seems to be working although I can't get SSL/TLS to work with postfix for some reason but as long as I can use STARTTLS, I suppose that's okay.
> 
> 

 

You've lost me on this part. If you can do STARTTLS, then SSL/TLS is working. 

Note that if you're testing via telnet, you have to issue an EHLO to see STARTTLS - a regular old HELO will not show STARTTLS. 

To test? openssl s_client -connect x.x.x.x:25 -starttls smtp where x.x.x.x is your IP address

If STARTTLS doesn't show, please strip the comments from your main.cf and post (doing grep -v ^\# /etc/postfix/main.cf |grep -v ^$ should do the trick)

 *m_a_xim wrote:*   

> 
> 
> The virtual machine uses 5% CPU constantly; I don't really mind but if there's a way to make it use even less when idle, I wouldn't mind hearing of it. 
> 
> Also, when I send an email to a gmail or hotmail account, it gets put in the spam box. I've made an MX domain and everything; so is the behaviour of considering as spam all non well known smtp hosts common amongst the big hosting companies or is there anything I can do about it?
> ...

 

No idea about the CPU issue. 

As far as the spam issue goes, yes, this is to be expected - actually normally I would expect hotmail, gmail, yahoo, etc, to reject the message, because if you are hosting this on a residential broadband connection, they do not allow these to connect directly (you will be on blacklists, for example, Spamhaus PBL - not because you've done anything wrong, just because it's their policy not to allow residential end-user IP's to connect to their MX directly)

It helps to think for a bit what their system has access to see. They cannot see that you have set up an MX record just by looking at your IP. They can do a reverse lookup, check your PTR record, and see if this matches the hostname, but they do not see any MX. Now, they could do an SPF lookup and all that, but that's still not going to be enough for them to allow you to connect directly. This is just somewhat expected running a mail system on a residential broadband connection. 

So how do you get around it? Well, realistically there's no way to do so, aside from routing either some or all of your outbound mail through your ISP's smtp server. I chose to do this on a selective basis (before i started paying for business class!), by setting up transport_maps in postfix. Basically, for yahoo, gmail, etc, I routed it to my ISP's smtp server (again, via transport_maps), for everything else I went direct. 

 *m_a_xim wrote:*   

> 
> 
> Just a thought: wouldn't it be possible to create some kind of software that automates the creation of a virtual machine that is ready for common tasks such as email, web/blog hosting, xmpp,... that any user could install? This could provide an easy and secure environment for self hosting thus encouraging some people to quit using extremely centralized services such as Google and encouraging a more decentralized Internet more prosperous for net neutrality. (oops... I think I've gone somewhat off-topic here)

 

a number of companies provide this. But for hosting it at your house, the main issue will still be that this is a residential connection, and because there has been so much abuse from compromised end-user machines on dynamic IP's, these will always still be blacklisted. 

Part of the issue is that when a host is misbehaving, with a business class connection, there is accountability. When it's a dynamic IP, holding the misbehaving host/person accountable is relatively difficult. So the dynamic provisioning still has that serious pitfall outside of a commercial environment. I'm all for decentralizing services such as this, but at the same time if someone is trying to abuse one of my servers, I want to be able to take action and have the person stop. 

Tons of folks offer self-provisioning of VM's. GoDaddy does it (CentOS and Fedora only I think), Rackspace does it (loads of OSes, including Gentoo actually), loads of folks do it, but of course these are not free. Basically, you are paying to not have to maintain your own hardware, and paying for an IP that's not blacklisted. 

For a long time I've thought about creating a hardened Gentoo template VM, something where someone could go through a basic command-line wizard and get mail set up. Two things have stopped me: 1)too lazy, too busy, 2)it would be of minimal benefit to people on residential broadband connections, given the whole blacklisting issue. 

oh well, im typing too much, and i lost my train of thought.

----------

## m_a_xim

Wow, this is one big response, cach0rr0. Thanks.

Ok, so here's my main.cf (it's kind of messy, I know) :

```

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)  <-- Yes, I'm using Debian for the VM (easier to set up)

biff = no

append_dot_mydomain = no

readme_directory = no

smtpd_use_tls=yes

smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

smtpd_tls_auth_only = no

tls_random_source = dev:/dev/urandom

smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

smtp_use_tls = yes

smtp_tls_note_starttls_offer = yes

smtpd_tls_key_file = /etc/ssl/certs/smtpd.pem

smtpd_tls_cert_file = /etc/ssl/certs/smtpd.pem

smtpd_tls_CAfile = /etc/ssl/certs/smtpd.pem

smtpd_tls_loglevel = 1

smtpd_tls_received_header = yes

myhostname = *CENSORED DOMAIN*

alias_maps = hash:/etc/aliases

alias_database = hash:/etc/aliases

myorigin = /etc/mailname

mydestination = *CENSORED DOMAIN*, localhost.*CENSORED DOMAIN*, localhost

relayhost = 

mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128

mailbox_command = procmail -a "$EXTENSION"

mailbox_size_limit = 0

recipient_delimiter = +

inet_interfaces = all

   

smtpd_recipient_restrictions = reject_invalid_hostname,

   permit_mynetworks,

   permit_sasl_authenticated,

        reject_unknown_recipient_domain,

        reject_unauth_destination,

        reject_rbl_client sbl.spamhaus.org,

        permit

smtpd_helo_restrictions = reject_invalid_helo_hostname,

        reject_non_fqdn_helo_hostname,

        reject_unknown_helo_hostname

smtpd_sasl_type = dovecot

smtpd_sasl_path = private/auth

smtpd_sasl_local_domain = $myhostname

smtpd_sasl_auth_enable = yes

broken_sasl_auth_clients = yes

smtpd_sasl_security_options = noanonymous

inet_protocols = ipv4

```

 *Quote:*   

> If you can do STARTTLS, then SSL/TLS is working. 

 

When I say SSL/TLS, I'm talking about a completely encrypted session through the ssmtp port whereas by STARTTLS, I'm talking about an encrypted session started through the normal smtp port. (this is the Thunderbird terminology)

And STARTTLS through the smtp port (port 25) is working fine.

 *Quote:*   

> and because there has been so much abuse from compromised end-user machines on dynamic IP's, these will always still be blacklisted. 

 

My IP is static as is often the case in Europe.

 *Quote:*   

> They cannot see that you have set up an MX record just by looking at your IP. They can do a reverse lookup, check your PTR record, and see if this matches the hostname, but they do not see any MX.

 

Hmm... I don't see why they would need to do a reverse DNS since the source domain is clearly accessible in every sent email. All they have to do is check that the source domain and source IP match, don't they?

 *Quote:*   

> So how do you get around it? Well, realistically there's no way to do so, aside from routing either some or all of your outbound mail through your ISP's smtp server. I chose to do this on a selective basis (before i started paying for business class!), by setting up transport_maps in postfix. Basically, for yahoo, gmail, etc, I routed it to my ISP's smtp server (again, via transport_maps), for everything else I went direct. 

 

I tried setting the"relayhost" option before and that worked just fine and was really easy:

 *Quote:*   

> relayhost = [smtp.*MY ISP*]

 

I suppose I could do that as a last resort.

 *Quote:*   

> Part of the issue is that when a host is misbehaving, with a business class connection, there is accountability.

 

What do you mean by "accountability"? Can you get sued for being misused by spammers or do you just mean being blacklisted?

 *Quote:*   

> 
> 
> For a long time I've thought about creating a hardened Gentoo template VM, something where someone could go through a basic command-line wizard and get mail set up. Two things have stopped me: 1)too lazy, too busy, 2)it would be of minimal benefit to people on residential broadband connections, given the whole blacklisting issue. 

 

Well, since many more people than you seem to think actually have a static IP and are thus less likely to be blacklisted, this might be a good idea if the targeted audience was  geeky people who aren't computer savvy enough or too lazy to set up a mail server or who are scared of doing it for security reasons.

And I'm not sure Gentoo would be the most appropriate distribution for this since it tends to have lots of packaging problems, when you want to update for instance. Furthermore, everything needs to be compiled so at each software update, you would have the CPU running full power and if people would be interested in running it in low power computers such as plug computers, the compiling process would be pretty slow.

No, I think something more mainstream like some light version of Debian would be more suitable for this purpose.

----------

## cach0rr0

 *m_a_xim wrote:*   

> Wow, this is one big response, cach0rr0. Thanks.
> 
> Ok, so here's my main.cf (it's kind of messy, I know) :
> 
> ```
> ...

 

ah, right. So what you're looking for is this: http://www.postfix.org/TLS_README.html#server_tls

Do a search on the page for "465", should find this section:

 *Quote:*   

> 
> 
> TLS is sometimes used in the non-standard "wrapper" mode where a server always uses TLS, instead of announcing STARTTLS support and waiting for remote SMTP clients to request TLS service. Some clients, namely Outlook [Express] prefer the "wrapper" mode. This is true for OE (Win32 < 5.0 and Win32 >=5.0 when run on a port<>25 and OE (5.01 Mac on all ports).
> 
> It is strictly discouraged to use this mode from main.cf. If you want to support this service, enable a special port in master.cf and specify "-o smtpd_tls_wrappermode=yes" (note: no space around the "=") as an smtpd( command line option. Port 465 (smtps) was once chosen for this feature.
> ...

 

That one's a master.cf change. 

 *m_a_xim wrote:*   

> 
> 
> My IP is static as is often the case in Europe.
> 
> 

 

Nice. When I lived over there mine was dynamic, but it rarely changed (I asked Virgin for a static, but it was too much extra each month  :Laughing:  )

 *m_a_xim wrote:*   

> Hmm... I don't see why they would need to do a reverse DNS since the source domain is clearly accessible in every sent email. All they have to do is check that the source domain and source IP match, don't they?

 

The source domain is not visible until the connecting client has issued the smtp MAIL command. It could in theory be issued in the EHLO/HELO, but if you plug through the RFC's, they basically tell you (summarizing) that the HELO/EHLO is not to be used for, well, much of anything. It should realistically match the PTR record for the host, or be an address literal, and neither of these will contain your domain. 

Now there is one point where they DO look at the domain sent in the MAIL command, and that it DOES become somewhat useful, and that's when you're doing an SPF lookup. When an SPF lookup is done, they take the domain part of the address sent in the MAIL command, do an SPF lookup for this domain, and check to make sure that the host in question is "authorized" to send mail on behalf of said domain. 

However, when it comes to mail filtering, looking at the contents of the SMTP envelope (e.g. MAIL, RCPT) is not particularly useful. I can easily spend the $8 to buy a domain for a year, 'spammingyou.com', set up SPF records for spammingyou.com, connect to your server, issue 

```
MAIL FROM:<awesome@spammingyou.com>
```

And it will pass SPF checks. I can also send a null reverse path, e.g. MAIL FROM:<>, normally used for bounce messages or notification messages, and SPF becomes fairly useless. Either way, the key point, is that the so-called "envelope return path" (the address sent in the MAIL command) is NOT visible to the recipient's mail client, and isn't used for much, so I can easily do 

```
MAIL FROM:<awesome@spammingyou.com>
```

, but then when I go to send the message data, put From: "Your Friend" <friend@trusteddomain.com> as one of the message headers - your mail client shows headers, not envelope data. 

Sender-ID goes one further, and is a bit superior in its approach IMHO since it goes on the data the end-user is going to *see* (e.g. headers, not envelope data), but that takes place *after* the smtp server has already accepted the message. One would ideally like to reject bogus messages, save yourself the processing cycles and disk space. 

Either way, in the e-mail world, even though I can talk to you here and now, and I know you're a normal human sender with a normal mail system, a remote system is not going to be able to see this. There's just no way for you to confirm the legitimacy of your message - an end-user sending spam or attacking my ssh daemon can easily say "hey, I didn't know it was going on, I must have been hacked!" - but with what's seen as "corporate" netblocks, in theory there is a company who can be held accountable for failing to take corrective/preventative action. 

It's not perfect, and it's sometimes annoying, but that's life with the SMTP protocol - a very ancient, antiquated protocol, drafted before the thought of spam even came to mind, but the only one we've got at the moment. 

 *m_a_xim wrote:*   

> I tried setting the"relayhost" option before and that worked just fine and was really easy:
> 
>  *Quote:*   relayhost = [smtp.*MY ISP*] 
> 
> I suppose I could do that as a last resort.
> ...

 

yeah, that does work, but as you've likely found out, that sends *everything* through your ISP. My issue with doing that, is that I don't want my ISP to be able to read the message if I can avoid it. I want as many messages as possible to go ONLY between myself, and the remote host, via TLS. So, I went the transport_maps route, and only sent through my ISP for domains where I knew I would be blocked. 

 *m_a_xim wrote:*   

> 
> 
> What do you mean by "accountability"? Can you get sued for being misused by spammers or do you just mean being blacklisted?
> 
> 

 

I touched on some of this above, but basically, it's easier to confront a company over an abuse complaint than it is to contact a residential broadband customer. Plus, most spam comes from compromised machines on residential broadband connections (I think between the US, China, and Brazil, that's something like 60% of global spam volumes), where the user is connected directly to the net. With most businesses, they will have some manner of proper firewall, and they will deny direct connections from their users' machines to remote SMTP servers, configuring the firewall so that ONLY their mail system can connect outbound on port 25. At least if someone is sending spam through their mail system, it is very easy to track, determine which  machine is compromised, and take it off the network until it is cleaned up. 

 *m_a_xim wrote:*   

> 
> 
> And I'm not sure Gentoo would be the most appropriate distribution for this since it tends to have lots of packaging problems, when you want to update for instance. Furthermore, everything needs to be compiled so at each software update, you would have the CPU running full power and if people would be interested in running it in low power computers such as plug computers, the compiling process would be pretty slow.
> 
> No, I think something more mainstream like some light version of Debian would be more suitable for this purpose.

 

If I were going for "light", I would go for OpenBSD. But, well, they've unfortunately made their views on virtualization pretty well known. 

On the Gentoo side, "Hardened" very, very rarely needs to be updated. Just do a glsa-check every once in a while, and you're good to go. A properly configured machine running hardened-sources with all of the correct grsec/pax settings, running properly configured RBAC, and everything built with the hardened toolchain, you'll be able to go years without any significant updates. I still have a handful of VM's running 2.6.29-hardened that are unaffected by the entirety of even the latest sets kernel vulns. 

Of course, I'd agree that on a low power system doing heaps of compiling is probably not the greatest idea. Mind you, you CAN set up a portage binhost. I can see where Gentoo wouldn't be a perfect fit for some of these scenarios, not to sound like some sort of fanboy. I guess the point I'm trying to get at, is that I think people get so used to the pace of updates on the desktop side of things, when they go to look at servers they think they're going to need a similar level of updates with similar frequency - with a proper hardened-* box, you don't.

----------

## m_a_xim

Well, thanks for all this information!

I'll look up the page about TLS when I have time.

And I think I'll just tell people to check their spam box for the time being especially since most mail providers (for instance those of ISPs) don't seem to consider my mail as potential spam from what I have just noticed. It's just the big ones: Google, Hotmail, and probably the others.

There's just one thing I don't quite get:

 *Quote:*   

> yeah, that does work, but as you've likely found out, that sends *everything* through your ISP. My issue with doing that, is that I don't want my ISP to be able to read the message if I can avoid it. I want as many messages as possible to go ONLY between myself, and the remote host, via TLS.  

 

Yes, that does bother me a lot but wouldn't the ISP be able to intercept the mail anyhow just by looking at everything which has 25 as source or destination port?

Unless of course the connection between SMTP servers is encrypted. Is that the case???

What we really need is for people to start using encryption in their emails with PGP. Many mail clients support it or make it relatively easy to install the appropriate plugin (e.g. Thunderbird's Enigmail plugin) but most people just can't be bothered. *sigh* or worse, they have reactions such as "I've got nothing to hide", "I'm not a terrorist", etc. (although this is probably less common in the US, right?)

 *Quote:*   

> If I were going for "light", I would go for OpenBSD. But, well, they've unfortunately made their views on virtualization pretty well known. 

 

I don't know much about BSDs and I can't seem to find any article about them having an issue with virtualization.

 *Quote:*   

> On the Gentoo side, "Hardened" very, very rarely needs to be updated. Just do a glsa-check every once in a while, and you're good to go. A properly configured machine running hardened-sources with all of the correct grsec/pax settings, running properly configured RBAC, and everything built with the hardened toolchain, you'll be able to go years without any significant updates. I still have a handful of VM's running 2.6.29-hardened that are unaffected by the entirety of even the latest sets kernel vulns.
> 
> Of course, I'd agree that on a low power system doing heaps of compiling is probably not the greatest idea. Mind you, you CAN set up a portage binhost. I can see where Gentoo wouldn't be a perfect fit for some of these scenarios, not to sound like some sort of fanboy. I guess the point I'm trying to get at, is that I think people get so used to the pace of updates on the desktop side of things, when they go to look at servers they think they're going to need a similar level of updates with similar frequency - with a proper hardened-* box, you don't.

 

Nope, I still think if you want to aim at a more general public, Gentoo is just too much bloody hard work. Note that the public that we would be aiming at would mostly consist of Ubuntu users (the most popular Linux distribution) and they would be used to the Debian tools.

Again, thank you very much for your very complete answers.

----------

## cach0rr0

 *m_a_xim wrote:*   

> 
> 
> Yes, that does bother me a lot but wouldn't the ISP be able to intercept the mail anyhow just by looking at everything which has 25 as source or destination port?
> 
> Unless of course the connection between SMTP servers is encrypted. Is that the case???
> ...

 

Bingo. That IS the case, and that's among the key benefits of doing things over TLS. If your ISP is sniffing traffic, all they're going to see is an encrypted data stream.

So, basically, the socket is encrypted, the message is not, whereas with something like S/MIME or PGP, the body of the message is going to be encrypted, and realistically you CAN send this encrypted message over an unencrypted socket without worries. 

 *m_a_xim wrote:*   

> 
> 
> What we really need is for people to start using encryption in their emails with PGP. Many mail clients support it or make it relatively easy to install the appropriate plugin (e.g. Thunderbird's Enigmail plugin) but most people just can't be bothered. *sigh* or worse, they have reactions such as "I've got nothing to hide", "I'm not a terrorist", etc. (although this is probably less common in the US, right?)

 

PGP is pretty easy to deal with. S/MIME, not as easy, but either way this is part of the problem, and part of why doing things over TLS is so handy - no need to bug a bunch of end-users and get them to set up their keys, set up their mail clients, etc. Although, with such messages, you still have access to the header content,so TLS is still going to be preferable.

 *m_a_xim wrote:*   

> 
> 
> I don't know much about BSDs and I can't seem to find any article about them having an issue with virtualization.
> 
> 

 

They seem to be the way to go as far as things like embedded systems are concerned. 

Far as my mistrust of any virtualized BSD, host or guest - http://kerneltrap.org/OpenBSD/Virtualization_Security

 *m_a_xim wrote:*   

> 
> 
> Nope, I still think if you want to aim at a more general public, Gentoo is just too much bloody hard work. Note that the public that we would be aiming at would mostly consist of Ubuntu users (the most popular Linux distribution) and they would be used to the Debian tools.
> 
> 

 

possibly. I think part of the idea is that you put something out there that requires *zero* maintenance, rather than *minimal* maintenance. I suppose you could go and do all of the kernel security patching, gcc patching, etc, with something like Debian, and then prebuild the binaries with a "hardened" type toolchain - IMHO you need these things on anything you're going to use as a server. If you're going to go through that trouble, well...it just depends on which tools you prefer most for being able to pull this off., since you're going to have to do this to pre-fabricate a system regardless of whether it's Debian, Gentoo, Fedora (lol), whatever. For me, on a server, and especially a server maintained by an inexperienced administrator, the less often they have to touch it, the less often you need to update, the better. And, well, like I said, my experience has been that with hardened-* you just never really have to update unless youre bored, or it's Winter and you need the extra cores working to heat up your bedroom. 

who knows, like i said im too lazy to do it  :Smile: 

 *m_a_xim wrote:*   

> 
> 
> Again, thank you very much for your very complete answers.

 

gladly! I'm not useful for much, but e-mail/Postfix and I have a long history together, so, finally something I can answer!

----------

