Using postfix aliases as a simple mailing list without sending mail to sender

Question

Context

I have a handful of system users having each one a company email address, handled by postfix. Every week, we send a status email to keep everyone up to date with current developments. Until now, this was only a few people, so it was ok to write their addresses as cc.

Now that company begins to grow, I would like to setup a virtual address for which I can add new aliases in a list, so that we can, for example, mail [email protected] to mail everybody.

I would rather not set up a mailing list system like mailman for that, because :

• it's a bit overkilled
• it's a minor feature. That means that, in the long run, I will probably not pay much attention to update and inspect a mailing software - and such a low priority service with a public facing interface is the perfect recipe to have a vulnerable server.

So, my first thought was to use virtual_map and add everyone in the virtual hash for this address :

# main.cf
virtual_alias_maps = hash:/etc/postfix/virtual

# virtual
[email protected] [email protected], [email protected], # etc

It works pretty well, except for one annoying issue : if user1 send a mail to updates, he receives a copy of that mail.

I've read a post on linux gazette presenting such a method and recommanding to use alias database. I've tried to implement that, but had the exact same problem.

Maybe worth noting, users usual mail addresses are already aliases, so that everyone can use his first name in mail address while still preventing bruteforces to be too easy, so my alias table looks something like that :

john:   john.Ed2
robert: robertFoo
alicia: alicia_bar

Question

I've searched for a postfix setting that would prevent sender to receive mail, but can't find any. Does such a setting exist ?

If not, what would be the simplest way you go to implement internal mailing list ?

Solution

No, such a setting does not exist.

But as commented, it could be done if one were so inclined. But it will be quite a hack, with negative consequences for the future. You'll accumulate technical debt.

When it comes to simple solutions, at literally all places I worked at, the mailing lists (to be more exact; this is a distribution list) were implemented exactly the way you did; so that a sender received a copy of his own mail.

This is not bad, quite the contrary, as with modern MUA's this enables them to display a threaded view in case of a discussion (granted, this shouldn't be too frequent on distribution lists, but happens still and is of some use). And frankly, people are used to it. Some even go as far as automatically CC each mail they send (it might sound crazy to others, but some people function differently and use their inbox for all kinds of stuff..ask the GMail guys).

If someone does not like this behaviour, he or she should set up an according filter rule on his own MUA.

This is the simplest way I would implement it. For other cases, I use mailman (which is very easy to setup) or the facilities provided by the mail server software.

Comments

[84104]

While it may be possible to do what you're asking, this generally isn't considered a problem.

[kik]

Ok, thank you, I'll stay on this. My /etc/skels/ contains basic maildrop config already, I may actually just use it if a specific user complaining.

[kik]

(and good point about threaded discussions, I have set my mua to put sent messages in my inbox for so long I just forgot this is not usual in non-gmail interfaces)

[kik]

Also, to be clear, and for further people reading this, I want to avoid using mailman mainly because I think having such a non critical service (read : that I don't care enough to pay great attention on the long run) with a public facing interface is the perfect recipe to have a vulnerable server. I'll edit my question to add this in, actually.

[c4f4t0r]

send the mail from one mail don't included in the mailing list

[Roman]

I have to object to the issues you name with mailman; it poses neither an unusually higher security risk than other SW, and you don't have to nag the users. We're using one instance to send bulk mail to 500+ addresses, and none of them know that mailman is used, nor can they do anything with it. But I do agree with you that it's simple overkill in this situation, and furthermore not an ideal fit.

[kik]

I have no issue with mailman itself, mostly with the fact I know I won't be as focus on its traffic and its updates than other more critical apps. User knowing we use it is not really an issue too - what is (additionally to risk of long due updates) is public facing software signature. For example, it's easy to find mailman apps searching for "List administrators, you can visit".

[kik]

(of course, this may sound paranoid, since mailman pages should not be indexed in first place if no one knows we actually use it, but again, I know I will install and forget, so better be paranoid in the first place :) )