I'm looking for a solution to limit rate of e-mails sent to specific e-mail operator (several Top-Level domains, all of them I know) on hourly basis. I also need some way to control the rate on per-mail basis, to allow bigger amount of e-mails sent by postfix during each hour. Limit is global for all addresses maintained by this operator, reseting each full hour.

What I've done so far

I use postfix after_queue custom filter, looking for our custom header indicating priority. Number of mails accepted by filter are kept outside script, within PostgreSQL database. Mails fitting current timeframe quota are passed to postfix as accepted, mails outside quota are deferred using tempfail return code.

SMTP relay used to send e-mails to this specific operator is separate virtual machine, used only for limited e-mails and bounces from the operator. Custom filter efficiency is good enough according to requirements.


Basically, there are two problems:

  1. I couldn't find any way of prioritizing e-mail messages in postfix queue. It would be preferable if I could use our custom header as priority indicator or add another priority mark to e-mail message and be guaranteed it will be filtered and sent before non-priority messages. I thought about using multiple instances (postmulti), but priorities are required to be relative, numeric - those are used as quota modifier for outgoint mail. Basically: email with priority N uses 1/N of quota used by email with no priority. Prioritizing is nice-to-have feature, so we can go away without it if timeframed quotas work correctly.
  2. Due to e-mails going back to queue after applying filter we are not guaranteed e-mail will be really sent in timeframe it was accepted. Postfix queue seems impossible to steer and control real throughput.

My idea of solution

From after-queue custom filter, instead of returning message to postfix queue, just send it directly to destination SMTP using another tool and skipping postfix entirely. I don't know if there is any ready-to-use smtp client available on Linux to achieve such tasks. Also, we need to process bounce messages both synchronous (as response in SMTP communication) and asynchronous (as status e-mails sent to Return-Path address). We also need to control Return-Path for such tool to point the server e-mail is sent from.

As a last chance solution, the idea is to roll out own SMTP server or maybe modify sendmail/postfix source to our needs. It is overkill until no other option is available.


What Linux tool can immediately (without queueing) relay e-mails to recipient SMTP server and provide valid bounce messages? Or, if there is better solution of this problem, what tools should I look at?

  • 1
    Why doesn't use postfix multi instance for last-chain SMTP server? Each instance will have its own queue and configuration file. You can configure that instance to immediately send your email. – masegaloeh Jun 18 '14 at 22:17
  • Thanks a lot, postmulti seems to work as intended. Due to how fast quota is exceeded during each timeframe, we have no problems with second queue, never stepping outside required limit with each email. – BWiatrowski Jun 24 '14 at 15:24
  • I have added above comment as answer. You can consider to accept that because above comment has less visibility than answer. See meta.serverfault.com/questions/1886/… – masegaloeh Jun 24 '14 at 15:58


What Linux tool can immediately (without queueing) relay e-mails to recipient SMTP server and provide valid bounce messages? Or, if there is better solution of this problem, what tools should I look at?

The postfix itself has MULTIPLE INSTANCE feature. It will lets you define separate instance of postfix that have its own queue and configuration file. You can use this instance as last chain of your SMTP processing. And yes, because it has separate queue, this special instance can send your email without waiting and tinkering another queue.


Take a look at the postfix policy daemon. That has quotas that work the way you describe.




  • I tried configuring policyd to do this, but there is one serious limitation which draws policyd as insufficient: no way of controlling quota usage by e-mail header value. We need to have some way of increasing email output by controlling how much quota each message uses. – BWiatrowski Jun 23 '14 at 12:30

To prioritise delivery of a given mail message, you could periodically grep the items in the deferred queue to read your custom header and build a list of the messages that need to be delivered now. For each pending mail in that list run the command below.

postqueue -i queueid

This should cause postfix to attempt delivery of the mail with the given queueid.

This may or may not be practical depending on the volume of mail and the performance of the system. However, you would need to consider the growth of your system and test the maximum throughput that your system needs to handle.

Note. On Centos, the deferred mail content is stored under the following directory.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.