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 [EMAIL PROTECTED] > - domainA fails to detect that it is spam > - userA has set up forwarding to [EMAIL PROTECTED] > - domainA attempts to forward email to [EMAIL PROTECTED] > - 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 -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
