Re: [exim] Delay_warning_condition - new default?

Top Page
Delete this message
Reply to this message
Author: W B Hacker
Date:  
To: exim users
Subject: Re: [exim] Delay_warning_condition - new default?
John Horne wrote:

> Hello,
>
> The current delay_warning_default in Exim is:
>
> ${if match{$h_precedence:}{(?i)bulk|list|junk}{no}{yes}}
>
> However, looking at RFC's 3834 (Recommendations for Automatic Responses
> to Electronic Mail) and 2369 (The Use of URLs as Meta-Syntax for Core
> Mail List Commands and their Transport through Message Header Fields),
> it seems that the Precedence header is not standard, and that the use of
> 'List-' headers is (optionally) to be used by mailing list software.
>
> A very quick look at some mailing list message headers shows that
> Precedence is still being used, and with (usually) a value of bulk, list
> or junk. Of the 'List-' headers, the List-Id and List-Unsubscribe
> headers seem to always be present. The List-Subscribe header is present
> in some lists but not others.
>
> Would it not be better to change the default of delay_warning_condition
> to say something like "don't send a delay warning if both the List-Id
> and List-Unsubscribe headers are set, or if the Precedence header is set
> to one of bulk, list or junk"?
>
> (Sorry I have no example yet as I'm still trying to work out how to sort
> out the and's and or's such that the condition comes out right!)
>
> Comments?
>
>
> Regards,
>
> John.
>


Questions:

- Does any MLM operator willingly apply a priority of 'Junk'?

- Does anyone have input as to whether 'modern' MTA even bother to pay any
attention to any of these fields? One might surmise that prioritization had more
relevance in the days when servers sat on slower circuits - and/or before MS
products started adding precedence headers w/o the knowledge of most of their users.

I suspect that the more common approach nowadays is to shovel everything through
the chute as quickly as possible, so these headers are seldom looked at, let
alone actioned at MTA level.

Note that MUA and end-user use/not of these fields are a separate issue, as is
anything weird and woderful MS Exchange might do.

YMMV,

Bill Hacker