--On 22 May 2008 23:30:19 +0100 Tony Finch <dot@???> 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.
> --
> <fanf@???> <dot@???> 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
