Re: [exim] Delay_warning_condition - new default?

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Jethro R Binks
Date:  
À: exim users
Sujet: Re: [exim] Delay_warning_condition - new default?
On Thu, 27 Jul 2006, John Horne wrote:

> In terms of trying to determine if a message came from a mailing list,
> then yes, that's why Exim looks at the Precedence header to decide if a
> delivery delay message should be sent back or not. My point is that
> mailing lists could use the 'List-' headers instead, and as such perhaps
> the delay_warning_condition should take account of that as well as the
> Precedence header.


Well, as I regard it, essentially what exim is trying to do here is not
send a warning message to an address that can't make use of the
information. Which is pretty much everything except a person who by their
own act composed an email personally to someone. No mailing lists (or
their owners), automated senders, newsletters, cron jobs, etc.

In which case, what you want here is the same set of rules that shouldn't
send messages as you would apply in, for example, the circumstance of a
vacation message, or other auto-reply.

I seem to recall Philip very recently changed the default for
delay_warning_default to include values for the Auto-Submitted: header
too.

However there are many other conditions that can, and should, be used to
determine, broadly, "should a new message be generated in response to this
message?". They include analysis of various headers, senders (a list of
some of those was posted earlier this week in a different context), and
content relating to auto-reply mechanisms, automatic generators of email,
etc.

I have posted my own list of conditions in the past (it has grown longer
since - I analyse every 'automatic message' I see for tell-tale features).
I almost wrote a page in the Wiki about it but got rather tangled and
withdrew from it for the time being.

> I think I have worked out the condition required to be:
>
>    ${if and { {def:h_List-Id:} \
>               {def:h_List-Unsubscribe:} \
>             } {false} \
>         {match {$h_Precedence:} {(?i)Bulk|List|Junk} {false} {true} } }

>
> The question may be what 'List-' headers should be checked?


For what its worth, my own vacation reply router condition includes the
following:

    { def:header_List-Help: } \
    { def:header_List-Unsubscribe: } \
    { def:header_List-Subscribe: } \
    { def:header_List-Owner: } \
    { def:header_List-Archive: } \


I don't include List-Id:, as you can see, probably through oversight, but
I probably should.

I wonder (if others agree with my feeling that the conditions you would
not want to send an autoreply are probably the same as those for which you
would not want to send a delay warning) if there should be a generic
mechanism somehow for creating a condition with a value that should say
whether an 'autoresponse' should be sent that can be tested in these
different contexts (router conditions, global config settings). Or
perhaps there is a means already.

Jethro.


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Jethro R Binks
Computing Officer, IT Services
University Of Strathclyde, Glasgow, UK