Attn. postfix users WAS Multiple Postfix smtp instances

[Dhawal Doshy]

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
==============