Re: [exim] sender verify and greylisting

Jakob Hirsch wrote:

> Quoting W B Hacker:
>
>> http://conducive.org/threading.tiff
>
>
> You miss a very effective way to read mailing lists. See how it could
> look like: http://plonk.de/stuff/threading.png
>

Thanks - but that is exactly the sort of artistic but useless eye-confusion I
need to avoid, and the primary reason I use threading ONLY to check the point.

Why would I want things to walk off to the right side of the page when the
subject already says all one needs? And pure descending date order is even
faster to read.

This is not source code.

>> And, again, will someone kindly tell me what headers leave alone so as
>> to help *others*?
>
>
> um... I told you a while ago per private mail, others here on the list:
> at least In-Reply-To, preferrably also References.
>

Thanks again - done already.

> regarding your other post:
>
>> Those seemed to be the ones giving rise to 'thread stealing' accusations.
>> Never did figure out how hitting 'reply' to a specific post I had open
>> in the window could arbitarily switch to some other thread, so we
>> applied the BFBI solution.
>
>
> It was me that rised that. I thought it was clear what happens...
> You hit reply, your MUA automatically puts the Message-Id of the message
> you are replying to into the In-Reply-To header, and adds it to the
> References header.
> (At least that's what I think what happens, without having read the
> relevant RFC, it seems to me the natural and logical way...)
>

Moz MUA does *preserve* these if present, a view source show it so, anyway.
Haven't looked at how it manipulates them, as we do the header stripping in an
Exim transport. Moz DOES have a filter that moves incoming list traffic from
inbox to into a local folder, but that alters neither headers, body, nor
attachments.

> By hitting reply, the message should never be shown in another thread,
> unless your newly created message has no In-Reply-To, in which case
> other's MUAs have to solely rely on the Subject, which you could have
> changed.

That's true if a subject were changed.

But the original situation arose when creating a NEW subject, not on a reply.

That should have become a new thread if based on the unique message-ID my MUA
would have created - transformed on the way back out to the References, etc.

What seems to have happened instead is that the mesage-ID was new, but also that
prior headers were left over. Perhaps in the composer's buffer from an earlier
post that *was* a reply or an aborted one.

That WOULD 'steal a thread'.

If that happens again I'll know where to look.

Regards,

Bill


I suspect that

I now suspect that the compaint
>
>