Re: why our server got listed?

Mike Easter <[email protected]> wrote:
> RiNet Abuse Department wrote:
>> Today our primary mail server got listed again (it was delisted
>> yesterday).
> 
> Delisting is not the comprehensive way to manage a problem with a server
> getting itself blocklisted.

Sure. But this server pass through about half million messages per day,
serving ~8k clients. When it got listed, problem was fixed asap
(i.e. manual delisting), then i've filled dispute form (in order to get
details and fix root of the problem).
> 
>>  Server's ip is 195.54.192.35
> 
> 195.54.192.35 = relay.rinet.ru
> which is one of several output servers in the same family, some of which
> are also listed on other blocklists.
> 
>> Reason of listing is:
>> System has sent mail to SpamCop spam traps in the past week
> 
> 195.54.192.35 listed in bl.spamcop.net
> will be delisted automatically in approximately 19 hours
> has sent mail to SpamCop spam traps
> past 86.9 days, it has been listed 5 times for a total of 44 hours
> 

yes, i've seen that. But it's still unclear was it mail originated from server?
was it bounce? anything else? what should i fix?

>> Dispute listing didnt work - noone care to answer.
> 
> dispute listing only works for the instance of when the listing is based
> on 'mistakes' -- where a mistake is a mistake during the parse, that an
> IP is named as source when it wasn't, or when a reporter mistakenly
> reported their own provider named in a mistaken parse.
> 
> 'Mistakes' do not include reports based on backscatter or other
> non-conventional abuse which is not typical spam sourced from the IP.
> 
> The dispute par sez:  // Dispute Listing -- If you are the administrator
> of this system and you are sure this listing is erroneous, you may
> request that we review the listing. Because everyone wants to dispute
> their listing, regardless of merit, we reserve the right to ignore
> meritless disputes. //
> 
> Disputing a listing because the listing was based on backscatter is
> going to be considered meritless.
> 

How can i know what was that? 'Sending mail to spamcop trap' diagnostic is not
detailed enough - i still dont know which kind of problem should i fix
(was it bounce to spamtrap? someone who has access to this server sent mail to
spamtrap? autoresponder message?). Daily log of this server is about 2G, so
i _have to know_ what i'm looking for.

>> How can i get any info about reasons of listing? This system does
>> not originate mail itself, it's just mail relay.
> 
> Because the listing is based on spamtrap hitting, there isn't a process
> by which you could have gotten the report evidence itself.  When there
> are reports from reporters and not spamtraps, those reports are sent to
> [email protected]

yes, i know this. I'm the person who is dealing with those reports.
If i get such report for the issue we are talking about - i would be happy
and we had nothing to discuss.

> 
>> P.S. while reading spamcop web site i've found 'misdirected bounce'
>> feature. Can anyone explain me how it can be avoided on secondary
>> mail relays (which do not have any info about quotas/existing users
>> etc. and _can not_ reject mail during smtp phase)?
> 
> Misdirected bounces result from the condition of a server which is
> facing the internet and accepting mail with bogus Froms which it can't
> deliver which server then creates abusive newmails addressed to the
> bogus From.  Those abusive newmails are spamcop reportable.  That
> configuration is no good.
> 
> When you were reading on the spamcop website faq, you must've surely
> encountered this lengthy help page, which you should have been following
> instead of simply express delisting instead of remedying the problem:
> 
> http://www.spamcop.net/fom-serve/cache/329.html  Why are auto responders
> bad?  -- Traditional auto-responders - Misdirected bounces
> Challenge/response spam filtering  --  Why not allow bounces?  -- 
> Mitigation techniques?  -  If you use qmail, please apply a patch -- 
> Microsoft has updates available for their Exchange Servers  -- your
> responder should use SPF and/or Domain Keys to verify the authenticity
> of the message being replied to  -- Sending delayed bounces to all and
> sundry is not a good way to prevent directory harvesting - it harms
> others and does not really prevent harvesting
> 

I'm aware of all that stuff. But ISP mail server should avoid standard
violation as much as possible.

Correct me if i'm wrong: server may be listed if (and due to!) it does
conform rfc822 (i.e. will send bounce)? And you can avoid this if you violate
this part of rfc822?

-- 
Oleg.

================================================================
=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- [email protected] ===
================================================================