[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: More then 2800 spams from the list...

On Mon, 19 Mar 2018 18:31:48 +0000
Karol Augustin <karol@augustin.pl> wrote:

> On 2018-03-19 12:58, Michelle Konzack wrote:
> > Hello and Listmaster/owner,
> > 
> > I have send on "Date: Mon, 19 Mar 2018 07:17:40 -0400" a message
> > to the list and now I got already 2800 Spams on one go!
> > 
> > The EMail responsabble for this shit is <helm7722@gmail.com>.
> > 
> > Please can you remove this EMail from the list?
> > 
> > The message is:
> > 
> > ----8<------------------------------------------------------------------
> > Hello, this is the mail server on frash.longvieace.com.
> > 
> > I am sending you this message to inform you on the delivery status
> > of a message you previously sent.  Immediately below you will find
> > a list of the affected recipients;  also attached is a Delivery
> > Status Notification
> > (DSN) report in standard format, as well as the headers of the
> > original message.
> > 
> >   <helm7722@gmail.com>  delivery failed; will not continue trying
> > ----8<------------------------------------------------------------------
> > 
> > All servers have exactly the same message...
> >   
> > 
> > While writing this EMail, the spam increased to 3118.
> > 
> > Thanks in advance  
> It looks like you are hit by backscatter bounces. Someone uses your
> e-mail (in prepared message) as sender and spams the misconfigured
> servers which send you bounces as they can't deliver spammers message
> to the recipient.
> This is precisely why e-mail server should never send bounces to
> non-local senders. When sender is spoofed as in this case then is hit
> with thousands of DSNs.
> As most of the time people want to get DSNs for emails they sent it is
> hard to mitigate using spam filtering software. You just have bad
> luck/you are targeted.

You do it by never accepting email for non-existent users. The problem
is the use of a mail server which accepts absolutely anything for the
domain, then finds that the end user rejects the rubbish. Having
accepted it in the first place, the receiving mail server is then
required to admit that it can't deliver it, by means of an NDR. It does
this using the reply-to address, which is easily forged.

The fix is that *all* incoming SMTP servers for the domain, primary and
backup, have a list of valid users (spammers often target
lower-priority MX records, as a backup server often doesn't have a user
account list). They must reject all other recipients at SMTP handshake
time, completely ignoring whatever has been forged in the headers. Spam
filtering doesn't do the job at all, the mail has already been accepted
by the time that sees it.


Reply to: