Re: [Exim] How to force SMTP AUTH for certain return-path ?

Página Principal
Apagar esta mensagem
Responder a esta mensagem
Autor: Dave C.
Data:  
Para: Alan J. Flavell
CC: Exim users list
Assunto: Re: [Exim] How to force SMTP AUTH for certain return-path ?
On Mon, 24 Jun 2002, Alan J. Flavell wrote:

>
> Well, I'm not the original poster of this thread, but it's a scenario
> that I recognise only too well...
>
> On Mon, 24 Jun 2002, Dave C. wrote:
>
> > Unless you are an open relay, spammers (who arent your customers)
> > shouldnt be able to send mail through your server anyway.
>
> Correct, but this isn't the problem. The spammers are spamming _our_
> users, they aren't relaying through us.


I'm assuming you've also investigated DNSbls, sender verification,
header syntax checks.. etc..

> > If you are trying to stop just spam coming TO your domain, which also
> > forges a sender address in your domain, this might have some limited
> > use. But surely not a very high percentage of the spam you receive falls
> > into that category.
>
> A nontrivial proportion of the spam that gets past the other defences
> does indeed utilise the trick of counterfeiting a local user as the
> envelope sender.


Really? That is unusual. I get tons of spam, and very little of it has
an address in my domain as the sender.

> And if the spam-rating or anti-virus checks are triggered (this is
> exim v3 with a system_filter), the result (if no further logic is
> used) is to bounce the mail to the envelope sender: in other words,
> the mailer's defence mechanism in this case results in an intended
> _victim_ getting the item anyway (as has been discussed here before).
>
> > If a spammer wants to forge sender addresses in your domain name, there
> > is currently no technical way to stop them from doing so, using servers
> > which are not yours - only legal after-the-fact methods (eg, sue them
> > for forgery)
>
> Oh yes, very practical I'm sure.


Even finding out who to sue would be quite a task. Some companies have
actually pursued this successfully, however.


--