--On 22 May 2008 23:30:19 +0100 Tony Finch <[EMAIL PROTECTED]> wrote:
> On Thu, 22 May 2008, Ian Eiloart wrote: >> >> I was having a look at lemonade >> <http://www.lemonadeformobiles.com/index.html>, and it seems to me that >> one of the components - BURL. "Message Submission BURL Extension" (RFC >> 4468) - would have similar message body manipulation requirements. > > Not so much. BURL just requires the MTA to concatenate data from the SMTP > session with data from an IMAP session. It doesn't require modification of > that data after it has been spooled, which is the question that started > this thread. Well, the questioner wants to replace a MIME part with a URL. BURL does the reverse, doesn't it? Oh, actually no, it doesn't. In its most simple form, it simply replaces the entire message with an IMAP url. However, if the SMTP server supports CHUNKING, then the client can interleave BDAT and BURL commands to specify several parts of a message. I guess either could be achieved by piping through a suitable program, and Exim's routers are smart enough to decide which messages require treatment. So, "support" would simply be a matter of providing: (A) a switch to advertise the support (only when receiving on port 587), (B) a "BURL" application, and (C) documentation. But this might not be so great if an error occurs. >> BTW, I thought I'd have a look at which Lemonade features Exim supports, >> and have documented this - with a more general feature list on the wiki. >> <http://wiki.exim.org/EximIntroduction> > > Exim doesn't support ENHANCEDSTATUSCODES and I don't think ACL hacks can > be made to do the job correctly let alone sensibly. Oh, I guess it it won't advertise ENHANCEDSTATUSCODES so it doesn't support rfc2034. I've updated the wiki. However, custom SMTP messages can include rfc1893 enhanced status codes. And, Exim will panic if the first digit isn't correct. So, there is some support for rfc1893. All my custom messages include codes, and all my ACLs use custom messages, but perhaps there are some replies that aren't susceptible to customisation. However, rfc2034 para 4 says that "Servers supporting the Enhanced-Status-Codes extension must preface the text part of ALMOST ALL response lines with a status code." [my emphasis]. It's not clear what is meant by "almost all", but it could be that para 3(4) is intended to enumerate the exceptions - replies to the initial greeting and to HELO and EHLO. I suppose the minimum work required to support enhanced status codes would be: (A) a switch to advertise the support - off by default, (B) include a valid X.0.0 code for default messages, were X is the first digit of the error code, (C) require Exim to panic (or revert to B) when the switch (A) is on AND an custom message doesn't include a code. After that, it would be desirable to work on improving the default messages, but I don't think any of the above would be retrograde. > Tony. > -- > <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://dotat.at/ ${sg{\N${sg{\ > N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\ > \N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}} -- Ian Eiloart IT Services, University of Sussex x3148 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
