Attn. postfix users WAS Multiple Postfix smtp instances

[Dhawal Doshy]

Top Posting.. in continuation to my previous mail I searched for some
more stuff from Wietse, this time related to qpsmtpd. My quest here is 
to ensure that postfix and mailscanner play nice with each other from a 
technical (which i believe it does currently but is bound to break with 
future postfix releases) and also from a political point of view, since 
both products will benefit from this (postfix users have an alternative 
to amavis and mailscanner users enjoy official postfix support)..

I haven't seen Julian on the list for quite some time but i assume he'll 
have something important to say on this topic.

- dhawal

Quoting Wietse:
===============

A reasonably MTA-independent submission interface would look like this,
if implemented as (stdin + exit status) which is script-friendly though
not maximally robust (like an SMTP-like interface would be).

First a block of envelope headers:

     protocol_name: SMTP
     helo_name: client hostname
     client_name: client hostname
     client_address: [ipv4address] or [ipv6:ipv6address]
     client_port: port number
     sasl_method: plain
     sasl_username: you
     sasl_sender:
     size: 12345
     ccert_subject: solaris9.porcupine.org
     ccert_issuer: Wietse Venema
     ccert_fingerprint: C2:9D:F4:87:71:73:73:D9:18:E7:C2:F3:C1:DA:6E:04
     encryption_protocol: TLSv1/SSLv3
     encryption_cipher: DHE-RSA-AES256-SHA
     encryption_keysize: 256
     sender: <> or address
     dsn-envelope-id:
     dsn-return-option: full or headers
     recipient: address (<> not allowed)
     dsn-notify-options: never, or comma-separated list of fail, delay,
success
     dsn-orig-rcpt: original recipient

After a blank line, the standard RFC2822 content:

     headers....
     blank
     body...

Where the blank and body... are optional.

The exit status is 0 for success. All other status codes mean that the
operation failed.

We have to do much of this anyway when mail archival support is added,
so I would like to get it right once.

Now this is not the whole story: this submission interface cannot be
exposed to untrusted users of they could bypass all the safety checks
that are built into smtpd, pickup, postdrop and cleanup.

So it has to be implemented as a set-gid helper that checks an
authorization list. If the caller is trusted, then it passes a file
descriptor to a Postfix daemon process that does the actual work.

I don't intend to use set-uid programs within Postfix.

     Wietse
===============

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