Re: [Exim] Temporary defer on callouts

Top Page
Delete this message
Reply to this message
Author: Alan J. Flavell
Date:  
To: Exim users list
Subject: Re: [Exim] Temporary defer on callouts
On Sat, 31 Jan 2004, Ian A B Eiloart wrote:

> --On Saturday, January 31, 2004 12:31 pm +0000 "Alan J. Flavell"
> <a.flavell@???> wrote:


> > [...] that our practice of refusing (with appropriate explanation)
> > bounces *if* they appear to be bogus virus alerts (BVAs) is
> > admissible. We also rate bounces for spam, since some spammers try to
> > get their spam through camouflaged as a bounce, so this is another
> > possible cause for us rejecting a specific bounce (but obviously we
> > wouldn't reject a callout on that basis, since an incoming callout
> > never gets to the spam-rating stage).
>
> I'm not sure whether the RFC permits this, though. As I understand it, you
> must accept mail to postmaster,


Perhaps I should have mentioned that - in all but the most extreme
cases - we *do* accept mail to postmaster and abuse addresses before
applying the other acceptance criteria.

Although, as a consequence of increasing spamming of the postmaster
address, we now finally set up a shortlist of domains which, if they
try to address the postmaster, will be told to address abuse@...
instead.

If/when spammers move to trying to spam the abuse address too, my plan
would be to set up some kind of dynamic reporting address which those
extreme cases will be told to send their reports to.

> and to any known mailbox


Maybe. But we are rejecting as a matter of policy - not for some
protocol violation "per se". I don't think the RFCs aim to deny us
the right, when push comes to shove, to refuse items on a policy
basis. Heck, there's a few extreme offenders from whom we're no
longer even willing to accept an SMTP call, so we have no idea who
they're claiming to be today, nor whom they're trying to address.

> I can't see anything to stop you
> rejecting messages based on the content.


Indeed.

> Arguably it would be better to accept them and then delete them; RFC
> 2821 section 6.1 explicitly says that you can do this in the event
> of a "delivery failure" after acceptance.


It's my fatalistic assumption that in the vast majority of cases they
will in fact disregard our explanation for why their bounce was
considered unacceptable to us. But I feel that in the interests of a
generally trustworthy mail transfer system, the onus is on us to
explain to the peer MTA what we're doing, rather than silently
discarding something that _could_ be significant (even if it _appears_
to be dreck). The explanation might be useful to somebody (although
if they haven't got the message yet about bogus virus alerts, their
skulls must be thick enough that it'll take more than a 5xx from us to
penetrate them...).

all the best