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/
