Attn. postfix users WAS Multiple Postfix smtp instances

Dhawal Doshy dhawal at netmagicsolutions.com
Fri Apr 28 16:54:10 IST 2006


Glenn Steen wrote:
> Anyway, looking at the points Wietse stipulates, I think Jules pretty
> much follow all/most of them already... So for now at least, things a
> alright:-).

I agree and here is a point by point check..

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.

DD> This is being done by introducing the 'hold' interface.

2) All four queues MUST BE in the same file system. Otherwise mail will 
be corrupted or lost.

DD> MailScanner doesn't mess with the postfix queue structure, hence 
this is supported as well.

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.

DD> The modified cleanup server is the header_checks parameter. Looks 
like mailscanner *might* need to talk to cleanup post processing.Can 
some postfix expert comment on this?

4) Mailscanner MUST NOT move queue files except by renaming them between 
Postfix queue directories. Otherwise mail will be corrupted or lost.

DD> Excellent job here by Julian, queue files are renamed as 
original_queue_id.6_digit_random_number

5) Mailscanner MUST maintain the relationship between the file name and 
the file inode number. Otherwise mail will be corrupted or lost.

DD> See reply to point 4.

6) hehe.. there is no point number 6.

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.

DD> MailScanner, from what i understand doesn't move the queue file from 
hold to incoming till it is processed.. in the event of a crash, mails 
in the hold queue will be re-processed.

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.

DD> See points 4,5,7

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.

DD> Not sure about this one, maybe Julian can comment on this.

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.

DD> Not sure about this one too, maybe Julian can comment on this as well.

Finally, the only 'so-called' problem being that MailScanner doesn't 
speak (L)(S)MTP, which though an advantage (with MailScanner) relies on 
undocumented (which is in no way Julian's fault) internals to make 
things work. The are a few options available in this regard.. 
specifically net::smtp and qpsmtpd. Maybe.. maybe Julian could offer 
this as an option.

Julian, if you can comment on points 9 & 10, i'll send a reply across to 
Wietse and hopefully take things forward. We are still unsure of the 
changes in postfix 2.3, which could possibly break mailscanner.

thanks,
- dhawal


More information about the MailScanner mailing list