# Default Deny Applied to Email (postfix)



## dkovacevic (Jun 12, 2012)

I worked at a place in the past that used Outlook and Thunderbird rules to move all received email into "junk" unless the sender was on the recipient's address book. That organization had a lot of spam, and users did have to go diving into their junk boxes every once in a while (some much more than others). The system did work, though.

Would it be possible to set up postfix with the same functionality? Have all email placed in a "delete" queue unless on a whitelist, then make the whitelist accessible via a browser?

A better question: would this be effective or a bad idea?


----------



## kpa (Jun 13, 2012)

Bad idea in my opinion, look instead into a blocklist solution like the Spamhaus Block List, it's very simple to use with mail/postfix.

http://www.spamhaus.org/faq/section/Spamhaus%2520SBL


----------



## ecazamir (Jun 13, 2012)

It's a better idea to combine RBL check with greylisting and amavisd-new. 95% of SPAM messages will be filtered. Look what mailgraph is telling me about one server:


----------



## dkovacevic (Jun 13, 2012)

Consider a social network system, such as Facebook. They have done something like a default deny policy in place for accepting "friends": there must be an initial request and a returning accept before a "friendship" is established. The system does not allow a friendship to be established with just the initial request (default allow).

Consider caller ID: the person at the end of the ringing line has the choice to pick up the phone based on the identity of the caller. Typically, when the identity of the caller is unknown, the person does not answer (default deny).

If all previous biases towards email were completely removed, and it was re-considered how to build the email system, it seems to me that the best way to handle email would be to use a default deny system, in which all emails received and not on a user managed whitelist would be placed in a user accessible rotating trash bin.

The difficulty would be in making the two systems (whitelist and trash/junk bin) easily accessible and manageable by an average user.

The problem with using blocklists is simple: constant management. A blocklist either must be maintained by me, or by another entity (such as Spamhaus). What if I do not want to spend my time managing blocklists? What if Spamhaus shuts down tomorrow?

Ecazamir, assume that your organization or company grows without bounds. Your system catches 95% of all spam. The remaining 5% is successful at coming through. Now, that 5% might not be a tragedy, but your system does cost more resources than if you had a 0% spam rate. Assuming you grew without bounds, more and more resources must be devoted to that 5% of spam.

Maybe this is just knitpicking, but from an engineering perspective, it seems to me that it would be better to have the 100% effective system than the 95% effective system, especially as the one that has the 100% success rate is simpler and more efficient than the 95% effective system.

There is a flip side of the coin: using a default deny email system would cause legitimate emails to be junked. This same point came up in a discussion about NoScript and "playing minesweeper" before being able to use newly visited web pages: some (poorly built) web pages do not function correctly without scripting enabled. Therefore, the user is forced to open up NoScript and allow scripts on the page in the hopes of using said page.

As a user of NoScript, I have noticed something interesting: the better quality sites are much easier to "fix" when using NoScript than the poorer quality ones. The better quality sites tend to have a NoScript entry that matches the root site domain name, with a variety of other entries that tend to give away their purpose (googleapis.com). Allowing the root entry typically enables the needed functionality on these pages. Poor quality sites have entries like "buttonfix" and "processcode" which make it very difficult for a NoScript user to determine which entries are needed for the page to function and which are not.

My point is that just like using NoScript when visiting a well designed web page, a user has little issue with whitelisting when the given whitelisting system is designed well. Yes, a default deny email system would trash legitimate emails. I would be counting on it to do so, as I would be counting on the whitelisting process to be effective and simple.

Now, it is clear that there will always be spam. It is also clear that it is possible to identify the worst of the spam sources and blacklist them without losing too much time and effort. A blacklist is a good idea from the efficiency perspective: if certain entities are known to always produce spam, it is efficient to simply discard their traffic immediately rather than process it in a junk system. By using a blocklist in a default deny system, users have less garbage to search through when trying to find legitimate messages.

I am of the opinion that a blocklist alone should never be the sole guard against spam. It is default allow at its root. Admittedly, a great deal of time, effort, and resources have been put into these systems to make them effective for the most part.

Firewall admins seem to have the default deny idea worked out quite nicely; what is holding back applying the idea to email?


----------



## ecazamir (Jun 14, 2012)

'NoScript' and 'email default deny' requires constant management, which is not too easy to do if the users have IT knowledge below 'very skilled'. Anyway, not only 'poor written' web pages require scripting, because not everyone relies on HTML and/or Flash only. Where dynamic content is needed, Javascript is a very powerful tool, sometimes requiring good scripting knowledge. The users of NoScript will not be able to use those sites without prior manual 'permission', which is a wasted time. I think it's a better idea to use a squid proxy with a list of permitted sites and a 'default deny' policy instead of 'access the whole internet' and let users manage NoScript. 

The e-mail system was built for communication, a 'default deny' combined with a whitelisting mechanism will only increase the time amount spent on management, something which is not always desirable. Try to imagine how much time will take to tell every user how to whitelist a sender in an organization with more than 500 users.

The graps above don't tell the most important part: my mailbox is receiving less than 1 SPAM message per week, some of the other users may receive a little bit more. Before using postgrey, every user received more than ~4 SPAM messages / day.

If your target is to not receive ANY SPAM message, then whitelisting MAY help (but not for forged addresses), at the cost of list management time. Your users will soon need to receive mails from Yahoo or GMail users, and I'm not sure if you will allow the whole domain or individual mailboxes.

Firewall admins are usually skilled IT specialists, they need to change on a very small amount of routers/block/permit lists. This is not true for every PC user.


----------



## dkovacevic (Jun 14, 2012)

Ok, so you are saying that the main barrier to building this kind of system is essentially the difficulty of management on the side of the end user (rather than the IT dept). I understand that, and I do not disagree: there is more management required on the end user side, that is certain.

I do not consider a web page that uses Javascript, flash, or other scripting languages to be poorly written because the page uses those languages. On the contrary, I think that Javascript, flash, and others are terrific tools to enhance the web site user experience. Note the use of the words "enhance" and â€œtoolsâ€. There are many cases in which I browse to a web site and it comes up as a blank white page because the site admin decided to code the entire thing in Javascript. Sure, NoScript users are a minority in the big scheme of things, but what about other users that simply do not have Javascript functionality? Javascript and others were meant to enhance the already existing functionality of a web page, not replace it.

I do have a problem with your assertation here:



> 'NoScript' and 'email default deny' requires constant management, which is not too easy to do if the users have IT knowledge below 'very skilled'.



My mother and my grandfather use NoScript. At first, I had to do a lot of teaching and explaining (and convincing!) before they were able to use their computers by themselves. Now, both of them cruise right along without even thinking about it. Niether of them are "very skilled" with regards to IT. I have not had to "fix" their computers from issues related to browsing for about a year, and I never had to re-teach anything about NoScript after the initial lessons. Both are still happy users of NoScript.

I mentioned at the beginning of this post that I worked at an organization that practiced this idea of "default deny" with email. It was a university that I worked at. Academia is not typically very accepting of things like this. However, 40+ year old men and women with no "skill" were able to understand that if they received an email and it was not from a source that they had added to their address book, it would go in their "junk" folder.

My point is that from prior experience, if the system is set up properly, it works without much (noticeable) management from the end user. In fact, in each case, I would say that users of NoScript and that email "system" were happier with the level of control that they had over their systems than the system that was in place before: if the browser allows a Javascript (or other) exploit, IT removes the virus, and if the inbox receives spam, just delete it manually. Everybody is better off when the end user receives some level of control in a default deny system.

Is there some level of wasted time? A learning curve? You bet. But from the way I see it, the time initially invested pays off immensely in the end.

Incidentally, I considered a proxy with a default block mechanism. Here is the problem with such a system: in situations in which the end user is not able to modify the whitelist for the proxy, management bureaucracy inevitably will take over and destroy the system. Think of those large companies or government agencies that employ such systems. Two main groups of people exist in such systems: one group which must submit to the system and either work around it or choose to go to a different system, and the other group, which is not controlled but is monitored. In order for a default deny system to work well, it absolutely must have end user controls, else it becomes a pain for everyone. I have worked in government, and I know this from experience.

Here is how such a proxy would function according to default deny but with end user control: each IP has a whitelist in the proxy (which could be made accessible to management). When a page is blocked, the end user can whitelist it and proceed. Eventually, the end user hardly ever sees the block page, and the company can begin building a "default" whitelist for new employees based on other employee whitelists.

Basic economics apply to computing as well: hands off government. NoScript and default deny email puts control in the hands of the end users. Complicated blacklisting systems put control in the hands of IT/management, the result being lost efficiency.



> "Try to imagine how much time will take to tell every user how to whitelist a sender in an organization with more than 500 users."



Once one user (a manager) knows how to use the system, the news spreads like wild fire. Not to mention that if the system was already intuitive, the problem of lack of understanding is almost self correcting: if there is a big button next to every email in your junk/spam box that says "Not Spam!", people will eventually put 2 and 2 together.



> "Before using postgrey, every user received more than ~4 SPAM messages / day."



I have seen statistics for a user at a company that I worked for regarding spam/junk. He had a great deal more spam than 4 messages per day. Perhaps your users are more careful about giving out their email address than he was. Either way, the system should work well regardless of the type of user (social butterfly vs quiet shut-in).

A default deny email system would work with individual email addresses: one email address at a time, you build your whitelists. Whitelist all of yahoo? Oh my.


----------



## ecazamir (Jun 15, 2012)

I'm not sure it's a good idea to hand over the control of the accessible web page directly to the users, unless you have a strong audit scheme AND a method to make users sorry about their mistakes regarding the list and their behaviour on-the-net. The 'bureaucracy' option looks like a more acceptable option for me, it works fine if there is a method of sharing ACLs fast between all subsidiary sites / offices.



> Once one user (a manager) knows how to use the system, the news spreads like wild fire.


It depends. Maybe one-two managers know. But you should expect some opposition and many complaints from the users. If the manager gets stuck, the users will break your door, not managers'.



> Perhaps your users are more careful about giving out their email address than he was.


Actually, my users aren't more careful or careless than others. They don't need to provide the address to web sites to receive SPAM, it's enough to have their address on a infected partner's PC address book, victim of some mail addresses collector viruses.

Amavisd-new (and variants) is the answer to your question, if it's used with a database backend (required to store user's preferences) and a web interface accessibile to the users where they can manage the personal whitelist. This personal whitelist may include all yahoo, on a per-local-user basis ;-)
Running with the default configuration, amavsd-new does not have a 'match-all blacklist', you need to change the configuration. 

If you want to fight SPAM, use postgrey. Using the 'match-all blacklist' you will fight against your users.


----------

