Attn. postfix users WAS Multiple Postfix smtp instances

[Glenn Steen]

On 17/04/06, Res <res at ausics.net> wrote:
> 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

Oh yes. And to think that I opted for PF over qmail to not have to
deal with such an opinionated developer:-).

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:-).

--
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se