On Fri, Apr 09, 2010 at 06:36:10AM -0500, Mike Abbott wrote:
> Attached please find a patch that adds support to postfix-2.7.0 for RFC
> 4468 - Submission BURL.
> BURL requires a pre-configured trust relationship between the submission
> server and the IMAP server. This patch adds a new configuration file
> normally named "submit.cred" that contains text entries each specifying
> an IMAP server hostname, a submit username, and a password. The patched
> submission server logs into the IMAP server using:
This is not the security model in RFC 4468. In the RFC the server either
uses its own credentials (recommended username=submit) to access the
IMAP server via RFC 4467 URLs (I would strongly recommend this approach),
or may forward the SASL PLAIN credentials of the SMTP user to the IMAP
server if the IMAP server is believed to be in the same administrative
domain (i.e. is listed in a config file or table for such a policy).
>
> - the user in the URL given to the BURL command as the SASL PLAIN
> authorization ID
> - the username from the corresponding submit.cred entry as the SASL
> PLAIN authentication ID
> - the password from the corresponding submit.cred entry as the
> password
I would not adopt an RFC 4468 implementation in which the SMTP server
has access to a table of IMAP user names and passwords. Why is this
the design?
> The patched submission server logs into the IMAP server using either the
> PLAIN or a non-standard X-PLAIN-SUBMIT authentication method.
Which IMAP servers implement the non-standard X-PLAIN-SUBMIT, and which
(non-standard) document describes this protocol?
> Today Apple also contributes BURL, CATENATE and URLAUTH support to the
> Dovecot open source project. Postfix BURL interoperates with Dovecot
> BURL/URLAUTH.
Given support for URLAUTH, why does the Postfix contribution not
leverage that?
> Please note that all of our changes are commented with "APPLE" not to
> pollute the code but to help us merge in your new releases. Feel free
> to remove those comments or restructure or rewrite the code as desired,
> as long as you preserve our copyright.
It would be good to get the legacy Apple (OpenDirectory and SASL
extensions, the on-demand startup code for laptops, ...) reviewed and
adopted into Postfix, so that apple users are not running a substantially
different server than everyone else. Is anyone at Apple interested in
working on a project to gradualy (not everything at once) integrate
the apple features into the mainstream Postfix?
> We understand that our
> implementation choices may differ from yours; if you see a better way to
> achieve the same goal please do adopt the better way. Some areas we are
> aware could use improvement but satisfy our own needs:
>
> - the hard-coded TLS parameters
Have not looked at the code yet, what does this mean at a high level?
> - submit.cred does not match the format of other postfix config files
Why is this file in the design at all?
With TLS mandatory, the IMAP server could allow the submission server
to use "external" auth, via a suitably pre-configured client cert, or
in any case a fixed password for the "submit" user that is authorized
to fetch messages for submission. With this the submission server
just needs a single submission user id and password per IMAP server,
not per IMAP user.
--
Viktor.
P.S. Morgan Stanley is looking for a New York City based, Senior Unix
system/email administrator to architect and sustain our perimeter email
environment. If you are interested, please drop me a note.
