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
