Re: [exim] Exim 5.x

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: W B Hacker
Dátum:  
Címzett: exim users
Tárgy: Re: [exim] Exim 5.x
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