Re: [exim] A Tight Exim Config

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Heiko Schlittermann
Dátum:  
Címzett: Jon
CC: exim-users
Tárgy: Re: [exim] A Tight Exim Config
Hello Jon,

Jon Hardcastle <jd_hardcastle@???> (Di 15 Sep 2009 15:37:34 CEST):
>
> > I'm not sure why you don't want to rely on exim's retry
> > rules. They're
> > „industry proven“. But of course, you could strip them
> > down to get
> > bounces immediatly if exim faces a temporary problem.
> >
> > Alternativly you could inspect the message spool to get
> > information about
> > *pending* messages: „expick …“ will help you.
> >
> >     Best regards from Dresden/Germany
> >     Viele Grüße aus Dresden
> >     Heiko Schlittermann
> > --
> >
>
> So is that how it is then? you have to check the bounce back? I was hoping that exim could tell my code while the smtp connection was up? What is the standard way of doing this programatically?


If you need a reliable information, you need to check the absence of a
bounce message (provided that you use a working sender address) and an
empty mail queue (or stripped down retry rules).

During the SMTP between your application and Exim you only get
information if Exim(!) accepted the message. You may Exim configure to
do a callout already while it is still talking to you, this way
verifying the destination address, but this does not imply that the
message is really deliverable.

You *may* check the mainlog of exim for „Completed“ - and you may
compare this with the spool ID you got as the response after completing
the DATA command. But you need to really parse the lines with the spool
ID, since „Completed“ just means that Exim cannot do anything else with
the message - it's forwarded or bounced. You could use „exigrep
SPOOL-ID“ to find the relevant lines from the log.

But - If I'd be you, I'd write an LMTP or simple pipeline „receptor“ for
bounces and parse these messages. Because parsing logs, inspecting the
queue, etc, all these actions imply that your application is running on
the same host as Exim does. This kind of solution does not scale very
well.

    Best regards from Dresden/Germany
    Viele Grüße aus Dresden
    Heiko Schlittermann
-- 
 SCHLITTERMANN.de ---------------------------- internet & unix support -
 Heiko Schlittermann HS12-RIPE -----------------------------------------
 gnupg encrypted messages are welcome - key ID: 48D0359B ---------------
 gnupg fingerprint: 3061 CFBF 2D88 F034 E8D2  7E92 EE4E AC98 48D0 359B -