Re: [exim] Exim 5.x

Ian Eiloart wrote:
>>>
>>
*snip*

>>
>> Exim may be odd-man out with 8BITMIME optioned OFF - but it has NOT
>> so far become a global pariah for that behaviour.
>
> Well, that'll be because mobile email is still a minority pursuit,

Meaning mobiles are the main source of 8BITMIME?

For Wot? Photos taken with handhelds?

Not in my ken. Not over smpt, anyway.

But that genre has otherwise been a significant part of our traffic
since well before Blackberry, i-whatever, chrome-whatever.

I went through three HP-200LX that we used with PCMCIA modems before
there was anything lighter or smaller.

> users don't realise that a good proportion of their wait when sending
> email is actually unnecessary, and it degrades gracefully (the email
> still gets sent). That doesn't mean that Exim admins shouldn't be
> looking to improve the user experience.
>

I don't think that part has SQRT Fine Ambitions to do with an MTA.

> It's not just a performance issue, it's a storage issue, too.
>

Basically smtp is simply not the proper tool for that whole class of job.

And smtp - based to a degree on extensions to telegraphy and teletype
networking protocols - is in fact being less and less USED for that sort
of work.

In some parts of the world, SMS overtook smtp in message traffic several
years ago.

And SMS is IN TURN being supplanted. Or paralleled.

IRC, Tweets, file and photo sharing ... yadda, yadda..

Horses for courses.

Turning a McCelland saddle into a motorcycle seat might be *possible*,
but as one who has used both - trust me - also a pain in the anatomy.

As the need changes, so also the technical solutions.

So long as smtp serves, it lives. If not, not.

I gave up my ASR33 and international cable address WBHACKER ages ago.

If/as and WHEN smtp is obsoleted, I'll change again.

>> B) I can't find much in the way of reports as to what real-world
>> app even *creates* 8BITMIME. Or how often.
>>
>> I can't find a sample to test with, either.
>
> The way to find out would be to enable 8bitmime in Exim, and log
> $smtp_command in the MAIL command.
>

Did that.

tailed -f current log 'til my mew acrylic eyes were tired,

grep'ed older logs

grep -R on 10GB and six years worth of what hasn't been deleted from
IMAP mailstore.

This thread and similar aside, such as a few hits from cut and paste of
folks on the list reporting server advertising in general - no traffic,
no rejections, and no complaints.

>>
>> C) Most current MUA even if 'fed' 8 bit-anything seem to be
>> predisposed to ass u me the worst, and wrap it as
>> quoted-printable. In the MUA, not the MTA.
>
> They'll certainly do that when an MTA fails to advertise 8bitmime.
>

Sounds like a cheap and cheerful solution to me...

But the MUA hasn't a clue wot its OWN host is going to offer at
composition time, far less view of the far-end or intervening relays.

So MUA coders must have the problem - or avoidance of problem - already
in-view, factored in, and defaulted 'safe'.

Will turning on *BITMIME on every Exim MTA on the planet change that?

Not that it is a bad idea, but doubt it would change a thing.


>> D) Taken as STIPULATED that QP conversion may or may not suit the
>> recipient's MUA environment, it should still pass transparently
>> THROUGH the bowels of both MTA, if so optioned. Spam filtering
>> against know incidents of abuse remain separate issues.
>
> As for the rest of this, you seem to be arguing that YOU see some
> benefit in not advertising 8bitmime.

Not that at all. Just can't see why it MATTERS. No traffic.

> So don't. But please don't hold
> the rest of us back with virtually the only popular smtp software the
> doesn't support it.
>
>

I'll leave it on. No problem there.

And 'To Be Determined', but I suspect that Exim supports it exactly as
I'd *want* it supported: 'KISS'

Accept. Transfer.

Feel free to send a sample. Even a challenging one. Or 'many' such.

Otherwise, I doubt I'll even see much 8BITMIME.

Regards,

Bill