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
