wbh at conducive
May 19, 2011, 5:35 AM
Post #19 of 41
Ian Eiloart wrote:
> On 19 May 2011, at 11:24, W B Hacker wrote:
>> Ian Eiloart wrote:
>>> LEMONADE compliance
>> I don't see that what has been published so far has any interaction
>> with an MTA-only such as Exim at all. Integrated MTA+IMAP,
>> Otherwise, the LEMONADE features proposed appear to me to be all in
>> the IMAP daemon's realm:
>> - IMAP IDLE for low b/w& virtual 'push'? Old stuff.
>> - Forward w/o downloading body/attachments? See Courier-IMAP's 'out
>> tray', VERY old stuff.
>> What have I missed?
> The SMTP components listed at
Thanks, thats' more useful...
> These items are implemented already. But, their relationship to
> LEMONADE isn't in our docs:
> SUBMIT PIPELINING SIZE START-TLS SMTPAUTH
> These are sort of implemented:
RFC dated JUL 1994
> - this is implemented, but off by default. 5.0 (or 4.8)
> could enable it by default, perhaps.
ACK. Noting also Phil's recent 'roadmapish' comment.
Living in a high percentage of Chinese-encoding environment, I rely on
what we already have, do all composition with MUA that can either force
or auto-select UTF-8.
Not a hundred-percenter, especially with reply-to's, and we may still
have to select from among another 5 or so common encoding for Chinese
alone (but not all 20+).
Most interested in progress on that front, happy to test, and not
limited to Chinese.
RFC dated OCT 1996
> - these aren't implemented by default, though
> they are configurable.
ACK. No show-stopper...
> ... Ideally, they'd be in the default
> configuration, and perhaps an ACL option would specify a status code.
> Version 5.0 might make an ACL invalid if it didn't specify an
> enhanced status code.
Uhhhh . .rather see it default to SOMETHING, as most now do..
> These aren't implemented at all, as far as I can see:
> * BURL
RFC dated MAY 2006.
> part allows integration with an IMAP server, a message is submitted
> with a an IMAP url to allow forward without download, etc.
IF the content is already located at a URI, all that is needed is the
URI. We all get such - mostly as advertising.
ELSE content is IN local MTA/IMAP mailstore OR an auxiliary
storage/location known to its Mother, and can be SENT to or linked to by
.. a URI, at which point the Luser still needs ... only that URI.
MLM archives & digests sound familiar?
Otherwise, I'm still missing the point of what and how wants changing.
> * CHUNKING
RFC dated DEC 2000
> - allows large messages to be split into chunks.
> * BINARYMIME
> rfc3030 - optimises bandwidth
RFC dated DEC 2000
> * DSN - an SMTP extension defined in
RFC dated JAN 2003
> which allows the sender to specify conditions under which
> DSNs should be created.
> Perhaps a starting point would be a wiki page - or a chapter in the
> documentation - explaining Exim's LEMONADE compliance.
Looking just at the ages of RFC's from six to seventeen years old - it
seems what was found useful enough to gain traction, did so ... and has
Seems the world has been in no hurry to drink that kool-aide, er scratch
Looks like yet-another a big-corp sponsored job-security exercise to
me... check out the players...
## List details at https://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/