Attn. postfix users WAS Multiple Postfix smtp instances

[Res]

only confirms what many ppl think, wietse is bernstein 'the second'


On Mon, 17 Apr 2006, Dhawal Doshy wrote:

> Dhawal Doshy wrote:
>> Drew Marshall writes:
>>> On 14 Apr 2006, at 18:28, Mike Jakubik wrote:
>>>> Dhawal Doshy wrote:
>>>>> This mail was also posted by the OP to the postfix-users list and  is 
>>>>> now being discussed by the postfix authors 'wietse' and  'viktor' for 
>>>>> better integration (read: compliant to the postfix  internal 
>>>>> architecture) between postfix and mailscanner..
>>>>> I request all mailscanner+postfix users to follow this thread on  the 
>>>>> postfix-users lists and voice your technical opinions, if any.
>>>> 
>>>> Its sad to see that one of the best MTAs and content scanners, does  not 
>>>> get along so well.. Apparently Postfix 2.3 will make changes  that will 
>>>> break MailScanner functionality :(
>>> 
>>> Very sad indeed. Interestingly I am running the current release (Non 
>>> stable) of 2.3 and it works fine with MailScanner so I await to see  what 
>>> happens with the 'new queue format'.
>>> Drew
>> 
>> No it won't (Julian will find a better workaround) and it shouldn't, i 
>> would request all postfix users to subscribe to the postfix-users list and 
>> convince the developers to document postfix queue internals so that this 
>> matter is resolved once and for all..
>> At the least ensure that someone of use who understands postfix really 
>> well, (i don't) follows up with viktor and wietse on this..
>> - dhawal
>
> We now have postfix+mailscanner working perfectly fine, but is likely to 
> break in future releases due to internal changes in the postfix queue 
> working.. hence i took the liberty of sending this mail to the postfix users 
> list. Constructive comments are welcome from postfix and non-postfix users:
> ==============
> MailScanner currently works in this fashion:
> Internet ==> postfix ==> hold queue ==> MailScanner ==> Incoming queue ==> 
> local delivery or relay
>
> From what i understand, the part where mailscanner re-queues mails to the 
> postfix incoming queue is the questionable part..
>
> So what conclusion do we (the non-programmer postfix users) draw from your 
> discussion? What are the changes expected that i need to communicate to the 
> mailscanner development team?
>
> Finally, what would be required to make mailscanner an approved 
> Content-Scanner for postfix.
> ==============
>
>
> This is the reply from Wietse:
> ==============
> It takes a stable EXTERNAL interface, so that non-Postfix software is immune 
> to changes in Postfix INTERNAL details.
>
> For example, software that speak SMTP is largely immune to changes in Postfix 
> internal details, because SMTP is well defined.
>
> Absent precisely formulated requirements I can't define an external interface 
> for content management.
>
> 	Wietse
> ==============
>
>
> A search on the postfix archive gave me this mail from Wietse:
> ==============
> 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
> ==============
>

-- 
Cheers
Res