Re: 216.37.20.20

Alexey Lobanov <[email protected]> Fri, 29 Dec 2006 09:00:20 +0300
Newsgroups gmane.mail.spam.dsbl.admin
Message-ID <[email protected]>
Hello.

29.12.2006 4:49, Leah Peters пишет:

> Alexey,
> 
> Can you try your test again?

I see that you have disabled SMTP AUTH completely. Good idea, if you
really needn't this functionality.

And I confirm that your ISP did all the necessary for delisting.

2006/Dec/29 04:38:15 UTC
Removal Requested Requestor IP: 216.37.19.40
State: Awaiting Removal
Host will be removed in 23 Hours, 40 Minutes

All the best for 2007!

Alexey


> 
> Leah J. Peters
>  
> 
>  
> 
> -----Original Message-----
> From: Alexey Lobanov [mailto:[email protected]] 
> Sent: Thursday, December 28, 2006 8:36 PM
> To: Leah Peters
> Cc: [email protected]
> Subject: Re: [DSBL-Contact] 216.37.20.20
> 
> Hi Leah,
> 
> 29.12.2006 4:24, Leah Peters пишет:
> 
>> Alexey,
>>
>> We cannot find an info or admin account anywhere. 
> 
> Too bad.
> 
>> Do you have a
>> suggest as to where we should look? 
> 
> No. I don't know your system internals and I repeat that I have no right
> to know 'em.
> 
>> We have checked the SAM on the
>> server you referred us to, but there is nothing there.
> 
> So, this "info" resides in other location - but this location is still
> inside of your system.
> 
> Ideas:
> 
> 1. Study the logs. Find the same event in your today's logs and try to
> understand how was this "info" authentificated.
> 
> 2. Study your mailserver configuration and try to understand the
> authentification chain. In what databases does it lookup?
> 
> Alexey
>> Leah J. Peters
>>
>>
>>
>> -----Original Message----- From: Alexey Lobanov
>> [mailto:[email protected]] Sent: Thursday, December 28, 2006 8:24 PM 
>> To: Leah Peters Cc: [email protected] Subject: Re: [DSBL-Contact]
>> 216.37.20.20
>>
>> Hello.
>>
>> 29.12.2006 4:08, Leah Peters пишет:
>>
>>> Can you tell me what email address you sent the Removal request
>>> from?
>> From: DSBL <[email protected]>
>>
>> The Return-Path was empty, in accordance with RFC 1123/STD 3, Section
>>  5.2.9. The sending script is a dumb robot and it is not able to
>> receive and process any delivery or non-delivery reports.
>>
>>> Our ISP is not able to find the email you sent to [email protected]
>>> so they cannot respond back to it.
>> "250 ok 1167320663 qp 6148 
>> server-12.tower-55.messagelabs.com!1167320663!76661093!1" string must
>> be absolutely enough for message tracking. This record contains
>> unique "Queue-ID" assigned by the receiving mailserver.
>>
>> Alexey
>>
>>
>>
>>> Leah J. Peters
>>>
>>>
>>>
>>> -----Original Message----- From: Alexey Lobanov 
>>> [mailto:[email protected]] Sent: Thursday, December 28, 2006 8:10
>>> PM To: Leah Peters Cc: [email protected] Subject: Re: [DSBL-Contact] 
>>> 216.37.20.20
>>>
>>> Hello.
>>>
>>> 29.12.2006 3:55, Leah Peters пишет:
>>>
>>>> IF we find an Info and/or Admin account in our SAM (which as of 
>>>> yet, we have not)
>>> This idea about local SAM was a guess only. I don't know and I may 
>>> not know how does your internal authentification system works.
>>>
>>>> and delete or change the passwords, can you remove us from the 
>>>> list?
>>> No, because DSBL cannot check it. The ONLY delisting criteria is 
>>> "accountability": you have to prove that you are able to receive
>>> and read your "postmaster" (or "abuse") mail. In theory, you may
>>> even not to fix passwords, but in this case your server will be
>>> nearly instantly listed back.
>>>
>>> Alexey
>>>
>>>> Leah J. Peters
>>>>
>>>>
>>>> -----Original Message----- From: Alexey Lobanov 
>>>> [mailto:[email protected]] Sent: Thursday, December 28, 2006 7:43
>>>>  PM To: Leah Peters Cc: [email protected] Subject: Re:
>>>> [DSBL-Contact] 216.37.20.20
>>>>
>>>> Hello.
>>>>
>>>> 29.12.2006 3:28, Leah Peters пишет:
>>>>
>>>>> Since the vulnerabilities are happening on accounts that I do
>>>>> NOT run on my network,
>>>> How it looks from the sender side:
>>>>
>>>> Connecting to 216.37.20.20... done. <<< 220
>>>> **********************
>>>>>>> EHLO lobanov.sp.ru
>>>> <<< 250-mailfilter2003.TIG.local <<< 250-AUTH GSSAPI NTLM LOGIN
>>>> <<< 250 XA
>>>>>>> AUTH LOGIN
>>>> <<< 334 VXNlcm5hbWU6
>>>>>>> aW5mbw==
>>>> <<< 334 UGFzc3dvcmQ6
>>>>>>> aW5mbw==
>>>> <<< 235 2.7.0 Authentication successful.
>>>>>>> MAIL FROM:<[email protected]>
>>>> <<< 250 2.1.0 [email protected] OK
>>>>>>> RCPT TO:<[email protected]>
>>>> <<< 250 2.1.5 [email protected]
>>>>>>> DATA
>>>> <<< 354 Start mail input; end with <CRLF>.<CRLF>
>>>>>>> (message)
>>>> <<< 250 2.6.0  <[email protected]> 
>>>> Queued mail for delivery
>>>>>>> QUIT
>>>> <<< 221 2.0.0 tobiasemail.TIG.local Service closing transmission
>>>>  channel
>>>>
>>>> ------------------------------------------------------- Server 
>>>> accepted message AUTH=login USER=info PASS=<censored> 
>>>> IP=216.37.20.20 
>>>> -------------------------------------------------------
>>>>
>>>> So, your server definitely knows "info". A standard reason is
>>>> local accounts: you have no this "info" in the domain, but you
>>>> have it in the local SAM at mailfilter2003.TIG.local. Please
>>>> check.
>>>>
>>>>> you are clearly making business decisions for my company.
>>>> No, we are telling you new important details about your corporate
>>>>  computer system features and it's public activity in Internet.
>>>>
>>>> Alexey
>>>>
>>>>> Leah J. Peters
>>>>>
>>>>>
>>>>> -----Original Message----- From: Alexey Lobanov 
>>>>> [mailto:[email protected]] Sent: Thursday, December 28, 2006
>>>>> 7:32 PM To: Leah Peters Cc: [email protected] Subject: Re: 
>>>>> [DSBL-Contact] 216.37.20.20
>>>>>
>>>>> Hello Leah.
>>>>>
>>>>> 29.12.2006 3:17, Leah Peters пишет:
>>>>>
>>>>>> Alexey,
>>>>>>
>>>>>>
>>>>>>
>>>>>> One question, do YOU have the capability of removing my IP
>>>>>> from the list?
>>>>> I have neither capability nor wish. Your server is a proved and
>>>>>  active open relay, and DSBL users (your recipients) may and 
>>>>> should know this impleasant fact until you fix the
>>>>> vulnerability and prove that your Postmaster mail is really
>>>>> able to receive alerts and reports.
>>>>>
>>>>> Alexey
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>