[SC-Help] Attn Deputies: Re: Spam from IANA space or forged

[John E. Malmberg]

In article <d19npj$423$1 at news.spamcop.net>,
  "Mike Easter" <MikeE at ster.invalid> writes:
> David Butler wrote:
>> SC says this is from IANA space and wants to devnull it. WHen I
>> manually parse the IP it is indeed in an IANA range:
>
>> Is this really where the spam came from or is this a forgery that
>> fooled the SC engine ?
>
> It is better to post a tracker instead of the headers so I don't have to
> remove all of the returns from your newsreader's posting to see how SC
> wants to parse it.
>
> www.spamcop.net/sc?id=z742788378z77c3ac6646a270f61820678a271b481az
>
> SC is trusting 212.71.164.106  rDNS  jiruse5.jar.gin.cz  to be a
> server/relay.  The server mail.smirice.sten.cz ESMTP Postfix lives
> there.
>
> I would notify
>
> inetnum:      212.71.164.0 - 212.71.165.255
> netname:      AT-NET
> descr:        ATNET network
>
> telekom at telekom.cz and the default PM because...
>
> No abuse address is registered with abuse.net
>
> ... and abuse at gin.cz

I would also recommend notifying a Deputy.  If a "trusted" relay is accepting
e-mail from a "bogon" or unallocated I.P. address space, then that "trusted"
relay should be considered the source, and should lose it's "trusted" status.

There is a problem with always exempting the "trusted" relays that are not
in a reporter's mailhost list from listing in the bl.spamcop.net.  It gives
the operator of the network no incentive to fix long term mulit-hop exploits
on their network.  Apparently some network operators think that is all they
need to do to deal with their outgoing spam problem.

-John
wb8tyw at qsl.network
Personal Opinion Only