Category Archives: security

Managing Your SMTP Relay With Postfix – Correctly Rejecting Mail for Non-local Users

Image result for SMTP postfix

I manage a few personal mail relays that I use for relaying my own mail and for experimentation purposes (mail logs are a great source of unique and continuously flowing data that can you use to try out different ideas in GUI, database, or parser development).  One of them was acting up recently.  I got a message from my upstream mail-queue host saying that they’ve queued up quite a bit of mail for me over the last few weeks, and that I should investigate, as they do want to avoid purging the queue of valid mail.

Clearly I wanted to avoid queuing up mail on a remote server that is intended for my domain, and so I set out about understanding the problem.

What I found was that there was a setting in my /etc/postfix/main.cf that, although it was technically a valid setting, was incorrect for the role that mail-server was playing.  Specifically the mail server was supposed to be rejecting email completely for non-local users, instead of just deferring it with a “try again later” message.

In this case, I’m using Postfix v2.5.5. The settings that control this configuration in /etc/postfix/main.cf are as follows:

  • unknown_local_recipient_reject_code
  • local_recipient_maps

local_recipient_maps

local_receipient_maps defines the accounts that this mail server will accept and relay mail for. All other accounts would be “rejected” by the mail server.

However, how rejected mail is treated by Postfix depends on how it is configured, and this was the problem with this particular server.

For Postfix, it is possible to mark a message as “rejected”, but actually have it mean “rejected right now, but maybe not permanently, so try again later”. This “try again later” will cause the e-mail message to be queued on the upstream server, until it reaches some kind of retry time-out and delivery is once again attempted. Of course this will fail again, and again.

This kind of configuration is great for testing purposes, because it allows you to test the same messages over and over again without losing them, or to queue them up so that they can be reviewed to ensure they are indeed invalid e-mail messages. However this is not the state you want your mail server to be in permanently. At some point once things are ready for long-term (production) use, you want your mail server to actually reject messages permanently.

unknown_local_recipient_reject_code

That is where unknown_local_recipient_reject_code comes in. This configuration property controls what the server means when it “rejects” a message. Does it mean right now, or permanently?

The SMTP server response code to reject mail permanently is 550, and the code to reject mail only temporarily is 450.

Here is how you would configure Postfix to reject mail only temporarily:

unknown_local_recipient_reject_code = 450

And here is how you set Postfix to reject mail permanently:

unknown_local_recipient_reject_code = 550

In my case, changing the unknown_local_recipient_reject_code from 450 to 550 is what solved the problem.

In summary, if you ever run into an issue with your Postfix mail server where you believe mail is set to be REJECTED but it still seems to be queuing up on your up-stream mail relay, double-check the unknown_local_recipient_reject_code.

# Local recipients defined by local unix accounts and aliases only
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
 
# 450 (try again later), 550 (reject mail)
unknown_local_recipient_reject_code = 550

References
http://www.postfix.org/LOCAL_RECIPIENT_README.html
http://www.postfix.org/postconf.5.html#unknown_local_recipient_reject_code

Maybe Big Brother Isn’t As Bad as You Think..

Cross-post from LinkedIn, in response to Maybe Big Brother Isn’t As Bad as You Think:

“This is a future Orwell could not have predicted. And Big Brother may turn out to be a pretty nice guy.” I respectfully disagree. As others have noted, there is (and always will be) a huge asymmetry in the information being shared and consumed as far as “Big Brother” and state surveillance is concerned. The “sharing” in this case is one-way. Only those in power would have the ability to view and make sense of the data.

Your argument that we “choose to share data” because we get something in return, is flawed. Most people do not choose to share the kind of data that we are referring to in this regard, otherwise it would be done freely and intentionally, and the secretive information gathering we are witnessing here would not be taking place. Even the information we do share “intentionally”, is done so for the most part by many of us who do not pay attention to, and truly consider the ramifications of the many disclaimers, license agreements, and privacy policies that we agree to on a daily basis. What we get in return, as you suggest, is far from a fair compromise.

This one-way “sharing” means that those who are in power have not only the ability to collect this information, but also the tools and the ability to analyse this data and generate statistics that the rest of us have no choice but to consume as facts. Aside from the ability to collect and “make sense of” the data, on our behalf – those in power also have the ability to limit and restrict infrastructure and resources in order to manipulate the “facts” at the source. For example, the ability to manipulate DNS or shut down ISPs to prevent the dissemination of data – effective censorship. Many people have been detained or persecuted (or worse) simply for “sharing” their thoughts and beliefs.

How can you make an anti-Orwellian argument, a case *for* “Big Brother”, and suggest that this kind of sharing can be good and benefit us all equally, when the vast amount of information we are talking about can be controlled from source to audience by such small percentage of the population? I suggest you pay attention the thoughts and many works of notable individuals such as Noam Chomsky, Glen Greenwald, and Lawrence Lessig, and perhaps reconsider your position on this matter. I am currently reading Greenwald’s latest book “With Liberty and Justice for Some: How the Law Is Used to Destroy Equality and Protect the Powerful”. I am sure you would find it most enlightening.

For those more visually/audibly inclined: “Noam Chomsky & Glenn Greenwald – With Liberty and Justice For Some”

httpv://www.youtube.com/watch?v=v1nlRFbZvXI

Why You Shouldn’t be Sharing “Live” Documents by E-mail

 

If you and your team, in 2013, are still sharing Microsoft Office (Word, Excel) documents via internal corporate e-mail, I’ve got news for you.  You’re doing it wrong.

“Live documents” are documents that are actively being updated and collaborated on by multiple people.  Collaborating on these documents by e-mail is a process that you should avoid.  It is a process that can eat away at your team’s productivity precious minutes at a time, and can severely impede your team’s work-flow and ability to stay synchronised.

I’ve been involved with projects where this method of collaboration was adopted.  Whenever I recognize this to be the case, I would immediately share my concerns, and try to suggest better ways of getting the team organized. There are always better ways to do it.

One of the biggest problems with e-mail document sharing is that there is no tracking or accountability.  There is no way to easily know what version of the document you have in your possession.  Is it the latest?  Perhaps it’s new enough?  Ever had to find an email with a document attachment, and ended up trying to craft clever little search terms to search your inbox?  Even if you find the document you were looking for, there is no way for you to know whether it is the last official revision, unless a system is implemented to allow “official” versions of the document to reside in a central location.

If there is a point-person in charge of managing this kind of set-up (for example, a simple system implemented with shared folders), and the maintainer ends up leaving the company for any reason (vacation, short-term disability, lay-off), then you still end up in a bad situation.  Without someone actively maintaining the structure of the document store, things will end up getting messy very quickly.  Users will begin storing documents in arbitrary locations (whatever feels right at the time), and before you know it, you will have to start yet another document archive clean-up project.

Version control is ubiquitous, and it is here to stay.  Any company (in any industry, not just IT) not seriously considering a process for document revision control should at least make it a point to have the discussion at least once a year.  You may find that your current document handling processes are actually a significant time waster, and that implementing a document management system could save you a lot of time (or money) over the long run.

There are many document sharing and collaboration technologies available today.  Some of the more popular include Sharepoint (if you are a Microsoft shop) or Documentum.  There are also many open source (free) packages, such as Drupal, Joomla, and Liferay.  There are even projects like Etherpad that make collaboration just plain fun.  You can also roll-your-own (if you are so inclined) by developing a custom system on top of foundational version control software such as Git or Bazaar, as I personally have done in the past.

Do your research when considering a content management system.  Some important considerations you might want to make include:

  • Is it easy to set up?
  • Is it easy to use?  Does it blend well with our team’s work-flow?
  • Is it safe?  Is it easy to make backups?
  • What kind of security mechanisms does it have built-in?
  • Is it easy to get our data out of the system (strong import/export functionality), in the event that we decide to move to another system in the future?
  • Is it cross-platform, or does it tie us to a specific platform (operating system)?
  • Is the cost worth the investment for a company our size?

The important thing here is to start thinking about it.  Be open to evaluating multiple products before you decide on a system that blends best with your organization’s work-flow. Software is about solving problems, which includes eliminating routine and time-consuming tasks.  If your company is not continually looking at new ways to improve efficiencies via clever (and practical) software implementations, then it will eventually be left in the dust as more efficient start-ups and entrepreneurs bring their shiny new productivity platforms to the game.