Re: [exim] More embedded Perl functionality

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Tore Anderson
Dátum:  
Címzett: David Brodbeck
CC: exim-users
Tárgy: Re: [exim] More embedded Perl functionality
* David Brodbeck

> Sounds like a configuration problem. I don't know why anyone would
> route failed bounce messages to postmaster. Here they get flushed
> out of the queue after a couple hours if they can't be delivered. I
> learned very quickly that a failed bounce is almost always triggered
> by spam. It's unlikely to contain any useful information.


That's Exim's freeze_tell_mailmaster option. Once upon a time, this
was very useful. I guess you're right, though, these days enabling it
could easily be looked upon as a configuration error because of the
unbearable signal-to-noise ratio. I certainly haven't used it a while.
(Just checked, seems like it was removed after Exim 3 as well...)

But as I've said, I don't like it, and even though the problem has
grown so huge it's unfixable, I do not intend to help make it even
worse.

> I consider refusing mail at SMTP time a far better solution than the
> other two options: Accepting it and then bouncing, or sending it to
> /dev/null. The former creates far more backscatter spam,


Agreed, this is even worse than SMTP-time rejections.

> the latter means that sooner or later a real message is going to get
> trashed and no one will hear about it.


Who'll hear about it in the latter case? The sender? Unlikely, I
belive - anecdotal evidence suggests that normal users' perception of
bounces are the same as yours as postmaster: They're junk. Or, to put
it your way: «[They're] unlikely to contain any useful information.»
And even if this wasn't the case, most bounces aren't very readable for
the average user - the 550 message text is usually buried in an ocean
cryptic technicalities, if they're included at all. Which is, of
course, not something you're able to control.

All of this is of course just IME and IMHO.

For my own personal e-mail I /dev/null junk detected by SpamAssassin
(using a rather conservative threshold) and ClamAV. Those mails spend
two weeks in a purgatory before actually being /dev/null'ed though, so
I have some time to recover an email if I get suspicious I am missing
legit email. For the rest of the mail, I use DSPAM, and review+delete
the contents of the spam folder once in a while.

This setup does the job very well for me, with absolutely zilch
collateral damage. I do risk lost mail, but then again, that's no
different from your setup.

Kind regards,
--
Tore Anderson