Re: [exim] Unwanted bounce messages generated locally

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Yves Goergen
Ημερομηνία:  
Προς: Graeme Fowler
Υ/ο: exim-users
Αντικείμενο: Re: [exim] Unwanted bounce messages generated locally
On 21.02.2008 13:16 CE(S)T, Graeme Fowler wrote:
> ...noting that you should *always* accept postmaster@???
> (it's an RFC mandate).


I don't know anybody who really cares about that RFC postmaster account.
Neither me nor my clients need it, so we're not going to open that
standardised spam hatch. If somebody wants to contact the holder of the
domain, they can look up a valid contact address in the domain registry
or simply visit the web site and read the imprint (which is, as opposed
to the RFC, enforced by national law).

> There are a couple of things to note here:
>
> 1. You sent the message to the remote MTA, which rejected it, so you
> have to deal with the error. If you're not applying strict enough policy
> checks on inbound mail (for example, does the remote domain exist?) then
> the frozen messages are something you'll have to live with. You can tune
> the time they remain on the queue - see the docs.


Yes, frozen messages are kept for a week, I've already set that. So I'm
going to contact that person and ask them to have their spam filter on
my system enabled. Shouldn't be a problem as there's already a spam
filter running on the remote host.

>> I have configured my own spam filter (SA) so that it can scan the
>> message during the first-place SMTP session and reject spam without
>> first confirming it and later trying to send back a bounce message. But
>> why does exim still use bounces in the two cases mentioned above?
>
> It does so because in the first instance you're not verifying the
> recipient at SMTP time, and in the second instance because you're
> applying different rules to the remote systems.


My idea was, letting the initial SMTP sender wait a bit shouldn't be too
hard. So can't Exim just get the message and try to deliver it at once
instead of confirming it and delivering later? So when somebody passes
my server a message, an SMTP chain is established with the message going
forward and possible errors passed back. This way no bounce messages are
necessary. It can be problematic for long chains, but usually it's the
common way "sender" -> "name@official-domain" -> "name@private-hoster"
and then it ends.

--
Yves Goergen "LonelyPixel" <nospam.list@???>
Visit my web laboratory at http://beta.unclassified.de