
wbh at conducive
May 19, 2011, 5:35 AM
Post #19 of 41
(1192 views)
Permalink
|
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, >> perhaps.... >> >> 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 > http://www.lemonadeformobiles.com/detail.html 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: > > 8BITMIME 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. > ENHANCEDSTATUSCODES 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. >- this > 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 > rfc3030 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 > rfc3461 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 been actioned. The rest? Seems the world has been in no hurry to drink that kool-aide, er scratch that ...'LEMONADE'... ;-) Looks like yet-another a big-corp sponsored job-security exercise to me... check out the players... Bill -- ## 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/
|