|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Mailscanner
From: Wietse Venema (wietse
porcupine.org)
Date: Wed Jan 14 2004 - 20:38:56 CST
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Dan Hollis:
> On Wed, 14 Jan 2004, Wietse Venema wrote:
> > Thomas -Balu- Walter:
> > > after a long time using amavisd-new I thought it should be time to
> > > try MailScanner for virus and spam scanning.
> > > MailScanner requires a setup with two mail spools. One for the incoming
> > > messages and one for the delivered ones.
> > Yes, and it moves files around without playing by Postfix's rules.
> > People have reported both duplication and truncation of email.
>
> If MailScanner played perfectly by postfix's rules would you recommend it
> then?
The question is 100% academic. Like other Postfix internals, Postfix
queue details will not be published until they stop changing.
Until then I want to have the freedom to make changes without having
to jump horrible hoops in order to avoid breaking other people's
software.
To give you an idea of what it would take to make mailscanner safe
with the PRESENT queue implementation:
1) The Postfix queue would have to be changed from a three-state
incoming/active/deferred organization to a four-state organization
of unfiltered/incoming/active/deferred.
2) All four queues MUST BE in the same file system. Otherwise mail
will be corrupted or lost.
3) A modified cleanup server drops new mail into the "unfiltered"
queue and notifies mailscanner, while the unmodified cleanup server
drops locally forwarded mail into the incoming queue and informs
the queue manager as usual.
4) Mailscanner MUST NOT move queue files except by renaming them
between Postfix queue directories. Otherwise mail will be corrupted
or lost.
5) Mailscanner MUST maintain the relationship between the file name
and the file inode number. Otherwise mail will be corrupted or
lost.
7) Mailscanner must be crash proof. Like Postfix, it MUST NOT take
irreversible actions, or actions that may require undo operations
after a system crash. Otherwise mail will be corrupted or lost.
Specifically:
8) Mailscanner MUST NOT modify queue files. If content needs to be
updates, Mailscanner MUST create a new queue file and delete the
original only after the new file has been committed to stable
storage. Otherwise mail will be corrupted or lost.
9) When creating a queue file, Mailscanner MUST adhere to the
convention that the file permissions are set to "executable" only
after the file contents are safely stored. Otherwise mail will be
corrupted or lost.
10) Mailscanner should never touch a queue file that has an advisory
lock (flock or fcntl lock, depending on the system environment).
Otherwise mail will be corrupted or lost.
But again, all this is academic, because I will never support
non-standard interfaces for content inspection in Postfix.
Wietse
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]