Re: [exim] How to avoid generating backscatter?

Thanks to everyone for their suggestions. I can see I should have provided
some more information ...

In a moment of madness, I wrote:

> Hello, hope someone can help with this hypothetical (at the moment)
> situation ...
>
> - spammer sends email to userA@domainA
> - domainA fails to detect that it is spam
> - userA has set up forwarding to userB@domainB
> - domainA attempts to forward email to userB@domainB
> - domainB detects that it is spam, and rejects it (5xx)
> - domainA sees 5xx, generates NDR, attempts to send it to ... oops, you
> guessed, forged sender.
>
> Is there any way for domainA to prevent the generation, or at least the
> transmission, of the NDR? (Other than improving its spam detection
> rates!!)
>
> For bonus points, can domainA hang on to the original email and/or the NDR
> (eg by freezing it/them), for later inspection?
>
> Marks will be deducted for mentioning SPF ;-)


On Wed, 2 May 2007, ROGERS Richard wrote:

> Assuming you know (or can find out) the forwarding address at SMTP time,
> you could do a recipient verification call-out. Might get contentious if
> you're going to be doing a lot of it though (see the various discussions
> on sender verification call-outs which I hope we won't re-hash again...)

Mea culpa. I didn't make clear that these would be two specific domains,
with limited numbers of users, and I would "know" that the forwarding was
correct and legitimate.

In any case, a call-forward for recipient verification would not help -
domainB is not going to reject the message until the DATA phase.

(Thinking about the whole things some more, it is clear that it is much
like a border gateway forwarding to an internal mail-store, except that
the latter does not normally do spam-checking, but might still do things
like reject on over-quota etc)


On Wed, 2 May 2007, Jeremy Harris wrote:

> domainA could rewrite its forwarding MTA from the common
> store-and-forward model into the nonexistent synchronous
> cutthrough model.

... which is a non-starter because domainA will be running Exim. Sorry,
nice idea!


On Wed, 2 May 2007, Marco Wessel wrote:

> I don't see a way that would distinguish between spams and legitimate
> e-mail. In fact, as far as server A is concerned, the e-mail /is/
> legitimate and a bounce should thus be generated. The only way would
> be for server B to accept spam mails and silently drop them instead
> of rejecting, thus avoiding generation of a bounce anywhere.

Good points. However, in my particular scenario, domains A and B are "sort
of" cooperating, so should treat all emails equally, but I will have no
control over domainB's spam policies. (Yes, I think I just redefined
"cooperation" ;-)


On Wed, 2 May 2007, Kjetil Torgrim Homme wrote:

>
> you'll need to use some rewriting, like SRS, on the return-path. you
> can then handle bounces to these addresses in any way you like,
> including delivering them to BSMTP files for manual handling.

OK, that brings me onto something I've been wondering about. When bounce
messages are generated, are they submitted through the normal mechanisms
or by some back-door route? If the former, I've presumably got the full
power of the (relevant) ACLs at my disposal? And then, provided I can
identify the messages in question, I can indeed do pretty much what I
like.

> unfortunately, this means your server becomes SPF compliant.

Heaven forfend!


Richard