Prev: How to route mail that was on HOLD?
Next: RBL Usage questions
From: Victor Duchovni on 9 Apr 2010 12:26
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.

From: Victor Duchovni on 9 Apr 2010 12:55
On Fri, Apr 09, 2010 at 12:26:47PM -0400, Victor Duchovni wrote:

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

Sorry, this is more clear in the code, indeed you the cred file holds
submission credentials, not per-user credentials. Sorry, ...

The rest of the discussion should probably move to Postfix-devel from
postfix-users.

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

From: Mike Abbott on 9 Apr 2010 12:57
Thank you for pointing out that I did not explain the contents of the submit.cred file well enough. This file contains a single username and password per IMAP server which postfix uses to authenticate to that IMAP server. Typically the username is "submit". It does NOT contain regular users' names and passwords. Here is an example:

submitcred version 1
server1.example.com|submit|password1
server2.example.com|submit|password2
server3.example.com|submit|password3

First field is host name. Second field is user name. Third field is the password for the user name in the second field.

The "submit" user on each of those servers must be able to authenticate using the password shown above (third field) and authorize for any user. So when Postfix receives a BURL command with an IMAP URL for, say, fred(a)server2.example.com, Postfix logs into the IMAP server on server2.example.com with: authz=fred, authc=submit, pw=password2. Postfix does not know fred's password.

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

This is the method it uses. Only, the IMAP server must permit the submit user to reach into any user's mail.

> Which IMAP servers implement the non-standard X-PLAIN-SUBMIT, and which
> (non-standard) document describes this protocol?

The patch Apple contributed to Dovecot today adds support for X-PLAIN-SUBMIT to Dovecot. Patched Postfix can also use PLAIN if available.

> Given support for URLAUTH, why does the Postfix contribution not
> leverage that?

I don't understand this question. The contribution does leverage URLAUTH. BURL logs into the IMAP server specifically to issue an URLFETCH command.

> Is anyone at Apple interested in
> working on a project to gradualy (not everything at once) integrate
> the apple features into the mainstream Postfix?

I will ask.
From: Victor Duchovni on 9 Apr 2010 12:59
On Fri, Apr 09, 2010 at 11:57:17AM -0500, Mike Abbott wrote:

> Thank you for pointing out that I did not explain the contents of the submit.cred file well enough. This file contains a single username and password per IMAP server which postfix uses to authenticate to that IMAP server. Typically the username is "submit". It does NOT contain regular users' names and passwords. Here is an example:

Please join the postfix-devel list, and we can dissect the issues there...

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

From: Wietse Venema on 9 Apr 2010 17:09
Victor Duchovni:
> > + * Copyright (c) 2010 Apple Inc. All rights reserved.
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following conditions
> > + * are met:
> > + * 1. Redistributions of source code must retain the above copyright
> > + * notice, this list of conditions and the following disclaimer.
> > [...]
>
> I am not a lawyer, but it it not obvious that the license terms are
> compatible with the Postfix license. You can and should assert Apple
> copyright, but I think you need to release the code under the Postfix
> (not the proposed 3-clause BSD-like) license. Wietse?

I see this as just another disclaimer/license file that needs to
be added to the list of files that distributors will need to
propagate along with Postfix.

> > +#define LOWALPHA "abcdefghijklmnopqrstuvwxyz" /* RFC 1738 */
....
> > +#define DATETIME_CHARS DIGIT".+-:TZ" /* RFC 3339 */
>
> This looks ugly, Postfix already has a _UCHAR_ macro that is too similar
> to your UCHAR, and runs with a clean environment that specifies LANG=C,
> so using <ctype.h> is IMHO a lot cleaner than all these macros that
> duplicate ctype.h functionality. One or special lists of metacharacters
> would be fine, but this seems excessive.

I think that we can't really ask these people to rewrite the code
to make it satisfy a "spec" that exists only in the minds of you
and me.

I quickly looked over the BURL code and it looks like this will
follow a path similar to the adoption of IPv6 and TLS: add missing
checks and missing assertions to make things bullet-proof, and
adjust the over-all code structure where necessary. I understand
that compatible with the cover letter for this patch.

Adopting this code will take time, and I can't promise that such
time will be available before the 2.8 release. As this code is
sitting in a security critical path, the code will have to be vetted
with great care. I have a reputation to lose.

In the mean time, the authors may want to enforce strict sanity
checks on IMAP server output such as the reply payload length, and
also make sure that their vstream_limit code behaves when reads
are alternated with writes (either refuse to allow read/write/read,
or enforce the limit as promised).

Speaking of Postfix's reliance of ctype macros, this was perfectly
OK in ancient times, but it is becoming a liability, because handling
of SMTP and related protocols cannot not be sensitive to locale
settings. I introduced the default setting LANG=C as a workaround
to buy time for a more structural solution that replaces ctype.

One question I have is why would anyone send an email message that
is 100% identical to a message that is already sitting in an IMAP
store? It would seem that this is useful only when forwarding mail
verbatim. Is this worth the effort to adopt and forever maintain
another 1500 lines of code?

Another question is how this would integrate with Milter support
which currently provides access to a wide range of extensions
for filtering, mail authentication, and so on.

Wietse

 |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Prev: How to route mail that was on HOLD?
Next: RBL Usage questions