postfix + mailscanner WAS: Missed anything important?

[Dhawal Doshy]

Richard Siddall wrote:
> Julian Field wrote:
>> I have just marked everything in the list as "read". Anything important 
>> I have missed?
>>
> 
> Dhawal Doshy posted a couple of messages from the Postfix list about a
> possible documented queue interface.  It sounds like Wietse is seriously
> considering supporting the pragmatic approach that MailScanner uses, but
> wants some input on developing a secure, robust interface.  (Dhawal's
> posts indicate Wietse has put some thought into what's required, but
> doesn't want to do all the work himself.)
> 
> Dhawal also pointed out that qpsmtpd also uses a queue level interface
> to Postfix, and will also be broken by the upcoming changes to Postfix's
> queue implementation.

A copy of all communication (sorted) regarding postfix support..

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

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 a mail questioning future 
changes to the postfix users list:

My Mail
==============
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, this mail 
was dated 01/15/2004:
==============
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
==============

Also here is what he had to say on the qpsmtpd interface to postfix.
===============
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

> Regards,
> 
> 	Richard Siddall