Data

Tools

Indexes

Applications

Experiments

Awesome

An open API service indexing awesome lists of open source software.

https://github.com/tlinden/qpsmtpd-plugin-router

qpsmtpd general purpose policy mail router / spooler
https://github.com/tlinden/qpsmtpd-plugin-router

Last synced: about 2 months ago
JSON representation

qpsmtpd general purpose policy mail router / spooler

Awesome Lists containing this project

README 

          
=head1 Qpsmtpd-Plugin-Router



qpsmtpd general purpose policy mail router / spooler



=head1 Status



nothing useful implemented yet.



=head1 DESCRIPTION



This plugin acts as a general  purpose smtp routing queue. It tries to

deliver mails  queued into it  to an external  target, which can  be a

mail  server, an  external delivery  agent, a  script or  even another

queue plugin.  If this doesn't  work, it puts  the mail back  into the

queue (on disk, that is) and tries again later.



For this to work, a queueing daemon  will be forked on startup, but it

can be  started independently as well.  This daemon will take  care of

mails residing in the various sub queues (see below).



In fact, the queue/router plugin call from qpsmtpd will just throw new

mails into the incoming queue and  exit, the daemon will then process

the new mail.



Therefore  it  is  reallly  important, that  your  filter  and  plugin

configuration is setup properly. Better make sure, that mails entering

the queue are wanted. Any unwanted mails must be kept away from it.



It supports the following delivery methods:



=over



=item static relay host



Just send all mails to this smtp server.



=item mx via smtp



Do dns mx lookup and send mails to whoever it belongs to.



Will  be used  if either  none  of B  or B  is

configured or if B is configured but no entry matches.



=item mail delivery agent



Send mail to a local delivery agent (MDA) like maildrop or procmail.



=item pipe



Pipe mail into stdin of an external program (useful to implement robots).



=item rule-set based



Different   delivery  methods   can  be   configured  in   a  rule-set

(policy). Any  of the above  listed methods can be  used, configurable

for domains, subdomains, regexes or email addresses.



=back



The plugin maintains a bunch of sub-queues which it creates on startup

if they don't exist yet:



 +------------+----------------------------------------------------+

 | incoming   | new mails enter this queue first                   |

 | active     | contains mails currently being delivered           |

 | deferred   | temporary undeliverable mails                      |

 | archive    | final undeliverable mails, if archiving is enabled |

 +------------+----------------------------------------------------+



Beside  delivering  mails,  the  plugin  can also  be  used  for  mail

rewriting.  Sender  and/or recipient  domains can be  rewritten.  It's

possible to rewrite the canonical addresses as well as the mail header

addresses (From: and To: header fields) if you want.



On startup  the plugin forks a  queueing daemon which will  run in the

background maintaining mail queues and delivering mails. If a new mail

arrives, the following things will happen:



1) the queue/router plugin will be  called by qpsmtpd and get the mail

as function argument.



2) if rewriting is configured, the rules will be applied, e.g.

".*.foo.bar" => "foo.bar".



3) plugin will  then put  the  message into  the C  queue,

return the queue-id and exit.



4) the queue manager  will pick up the queue file by  moving it to the

C queue.



5) it  will then  hand it  to a delivery  agent (one  of SMTP,  MDA or

Plugin) according to the transport policy.



6) if delivery  was a success, remove the queue  file. If the delivery

error was temporary move it to the C queue, otherwise remove

the  mail from  the  queue (or  move  it into  the  archive queue,  if

enabled).



7)  if delivery  failed, mark  the transaction  as failed,  append the

error to a transaction specific log of the transaction object (we just

occupy the  object and add an  array ref with log  entries), increment

the retry count and put it into the C queue.



8)  step  5-8 will  repeat  for  every  mail  in the  C  and

C  queues.  However,  if  a   mail  failed  to  deliver  for

B days, remove  the queue file, unless  archiving is enabled,

in this case the queue file will be moved to the archive dir.



=head1 CONFIG



The plugin accepts the following parameters:



=over



=item B



Always  use this  server  as relay.   Separate  multiple servers  with

comma. Add  the port with  :port. When using ipv6  addresses, surround

them with brackets (only required if a port has to be specified). When

using  hostname,  use fqdn,  otherwise  the  plugin assumes  the  host

resides under $me domain (that is, the domain after config/me).



If multiple servers are configured, they will be used in a round robin

fashion.



Examples:



 relayhost 172.10.1.1

 relayhost 10.1.1.1:2525

 relayhost [::1]:2425

 relayhost mx.foo.bar,mx.backup.foo.bar



The  B  variable has  precedence  over  the other  delivery

methods   configured,  if   any.  So,   either  use   B  or

B.



=item B



Transport policy text  file containing rules how to  deliver mails per

destination  pattern.   You  can  specify  domains,  email  addresses,

wildcards or regexes.



Target  can  be  one  or  more mail  server  (same  notation  as  with

B), a pipe, an MDA or another qpsmtp queue plugin.



Top entries have precedence, that is:  order in the file matters. If a

rule matches, no further checks will be made.



Format:



 destination    next-hop



Destination examples:



 foo.bar

 *.foo

 /blah/



Next-hop examples:



 172.10.1.1

 queue/maildir

 |my-mail-robot.pl

 /usr/bin/maildrop



=item B



To make  it easier to maintain  the transport policy, you  can specify

variables, which can be used in the transport policy. The format is simple:



 name value



Variables can be used in the transports policy file, e.g.:



 /.*spl-[0-9]{6}\.foo.bar/       $splunkmta



=item B



How many  days a mail  is allowed to be  queued. After this  time, the

mail will be discarded. If  B is true, a non-delivery report

will be  sent to the canonical  sender, otherwise drop the  message or

put it into the archive queue, if B is set to true.



=item B



If set  to true, mails which  cannot be delivered will  not be dropped

but archived to an archive queue.



=item B



If  you  want  to  use   another  spool  directory  as  qpsmtp  itself

uses.  Directory  must exist  and  be  writable  to the  user  running

qpsmtpd.



=item B



Text file which contains rules how to rewrite mail sender or recipient

addresses or both.  Rewriting - if  enabled - will be the first action

done,  that is,  it  happens  before any  delivery  attempt. Rules  in

transport or aliases have to match on rewritten addresses.



Format:



 direction   old-value    new-value



Direction can be:



 from

 to

 both



Old-value can be:



 domain     (eg: foo.bar)

 wildcard   (eg: *.bar)

 regex      (eg: /[0-9]*.foo.bar/)



New-value must be a domain.



=item B



If set to  a true value both canonical and  mail header addresses will

be rewritten. Example:



 from    *.servers.company.foo      company.foo



=item B



If set to true, a non-delivery  response will be sent to the canonical

sender of  mails that cannot  be delivered after B  days. The

sender of these NDRs will be <> (none).



=item B



Filename  containing  recipient user  to  unix  user mapping,  without

domains. This  file is  B if local  delivery (using  the MDA

agent) is being used.



Format:



 virtual-user    unix-user



There  B be  an entry  for root,  since the  MDA agent  will NOT

deliver mails to  the root user directly, e.g.:



 root    max



Also there must be an entry for EVERY valid recipient, however you can

use regular expressions on the virtual side, e.g.:



 .*master    admin

 .*www.*     phpgroup



=back



=cut