RE: 216.37.20.20

Alexey,

Can you try your test again?

Leah J. Peters
=20

=20

-----Original Message-----
From: Alexey Lobanov [mailto:[email protected]]=20
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 =D0=C9=DB=C5=D4:

> Alexey,
>=20
> We cannot find an info or admin account anywhere.=20

Too bad.

> Do you have a
> suggest as to where we should look?=20

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
>=20
> Leah J. Peters
>=20
>=20
>=20
> -----Original Message----- From: Alexey Lobanov
> [mailto:[email protected]] Sent: Thursday, December 28, 2006 8:24 PM=20
> To: Leah Peters Cc: [email protected] Subject: Re: [DSBL-Contact]
> 216.37.20.20
>=20
> Hello.
>=20
> 29.12.2006 4:08, Leah Peters =D0=C9=DB=C5=D4:
>=20
>> Can you tell me what email address you sent the Removal request
>> from?
>=20
> From: DSBL <[email protected]>
>=20
> 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.
>=20
>> Our ISP is not able to find the email you sent to [email protected]
>> so they cannot respond back to it.
>=20
> "250 ok 1167320663 qp 6148=20
> 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.
>=20
> Alexey
>=20
>=20
>=20
>> Leah J. Peters
>>=20
>>=20
>>=20
>> -----Original Message----- From: Alexey Lobanov=20
>> [mailto:[email protected]] Sent: Thursday, December 28, 2006 8:10
>> PM To: Leah Peters Cc: [email protected] Subject: Re: [DSBL-Contact]=20
>> 216.37.20.20
>>=20
>> Hello.
>>=20
>> 29.12.2006 3:55, Leah Peters =D0=C9=DB=C5=D4:
>>=20
>>> IF we find an Info and/or Admin account in our SAM (which as of=20
>>> yet, we have not)
>> This idea about local SAM was a guess only. I don't know and I may=20
>> not know how does your internal authentification system works.
>>=20
>>> and delete or change the passwords, can you remove us from the=20
>>> list?
>> No, because DSBL cannot check it. The ONLY delisting criteria is=20
>> "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.
>>=20
>> Alexey
>>=20
>>> Leah J. Peters
>>>=20
>>>=20
>>> -----Original Message----- From: Alexey Lobanov=20
>>> [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
>>>=20
>>> Hello.
>>>=20
>>> 29.12.2006 3:28, Leah Peters =D0=C9=DB=C5=D4:
>>>=20
>>>> Since the vulnerabilities are happening on accounts that I do
>>>> NOT run on my network,
>>> How it looks from the sender side:
>>>=20
>>> 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=3D=3D
>>> <<< 334 UGFzc3dvcmQ6
>>>>>> aW5mbw=3D=3D
>>> <<< 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]>=20
>>> Queued mail for delivery
>>>>>> QUIT
>>> <<< 221 2.0.0 tobiasemail.TIG.local Service closing transmission
>>>  channel
>>>=20
>>> ------------------------------------------------------- Server=20
>>> accepted message AUTH=3Dlogin USER=3Dinfo PASS=3D<censored>=20
>>> IP=3D216.37.20.20=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.
>>>=20
>>>> 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.
>>>=20
>>> Alexey
>>>=20
>>>> Leah J. Peters
>>>>=20
>>>>=20
>>>> -----Original Message----- From: Alexey Lobanov=20
>>>> [mailto:[email protected]] Sent: Thursday, December 28, 2006
>>>> 7:32 PM To: Leah Peters Cc: [email protected] Subject: Re:=20
>>>> [DSBL-Contact] 216.37.20.20
>>>>=20
>>>> Hello Leah.
>>>>=20
>>>> 29.12.2006 3:17, Leah Peters =D0=C9=DB=C5=D4:
>>>>=20
>>>>> Alexey,
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> 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=20
>>>> should know this impleasant fact until you fix the
>>>> vulnerability and prove that your Postmaster mail is really
>>>> able to receive alerts and reports.
>>>>=20
>>>> Alexey
>>>>=20
>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>=20