[Declude.JunkMail] Logging in general

[Bill Landry]

Scott, I sorry to be spamming the list with these logging messages today,
however, I am quite frankly astounded at how much data is not being logged
at LOGLEVEL MID.  I don't think there should ever be a situation where there
is no log entry for a message at all.  But I have found several instances
today where messages were processed through Declude JunkMail with absolutely
no reference to the message in the logs at all.  I can even parse the log
for the queue ID from the message headers (e.g., X-Queue-File:
Dd7a4018e00a48c59.SMD) and still find no reference to the message in the
logs.

To have the Declude headers not show up in some messages is somewhat
disturbing (reported to the list last week), but to have Declude process a
message and then have no record of it in the logs of ever being touch by
Declude is downright untenable, and I feel, totally unacceptable.

I think this is a matter that requires immediate attention.  I sincerely
hope that you see it that way, as well.

Bill

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

[Declude.JunkMail] WHITELIST AUTH logging

[Bill Landry]

Scott, can you please add "whitelisted authenticated user" to the log at
LOGLEVEL MID.  I could not even get a log entry for authenticated users at
the LOGLEVEL HIGH setting.  In order to see the following log entry, I had
to set the log to LOGLEVEL DEBUG:

Skipping E-mail from authenticated user [EMAIL PROTECTED];
whitelisted.

Thanks,

Bill

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

Re: [Declude.JunkMail] Another very effective filter test

[Matthew Bramble]

Bill,

One other very important note.  You need to be using IMail 8, WHITELIST 
AUTH with Declude 1.76b and make sure that all the mail clients are 
configured to use SMTP AUTH, otherwise intra-server E-mail is going to 
get tagged.  I can't use this in it's present form because I'm using 
IMail 7 :(

Am I missing something?

Matt



Bill Landry wrote:

This test is very effective at flagging or blocking spam from mail hosts
that attempt to connect to your mail server and announce your own hostnames
or IP addresses to it in their HELO string, especially if your IMail/Declude
server is directly sending and receiving mail from the Internet (less
functional, but still works if relaying via mail gateway to IMail/Declude).
This filter looks for the bogus HELO info in the headers.  In my testing,
100% of the messages delivered by these mail hosts is spam.
Think about it, why would any other legitimate mail server out there attempt
to connect to your mail server announcing your own hostname or IP address in
its HELO string?  The answer is, it wouldn't.  Anyway, here is the test I
use to detect these.
In global.cfg:
FORGEDHELO-FILTER filter M:\IMail\Declude\ForgedHelo-Filter.txt x 7 0
In ForgedHelo-Filter.txt file:
=
# In case you have mail gateways, deduct equal weight for these hosts
HELO -7 ENDSWITH gw1.yourdomain.com
HELO -7 ENDSWITH gw2.yourdomain.com
# Remote mail hosts connecting and announcing your IP addresses
HELO 0 CONTAINS xxx.xxx.xxx.
HELO 0 CONTAINS xxx.xxx.xxx.
# Remote mail hosts connection and announcing your hostnames
HELO 0 ENDSWITH your-host.com
HELO 0 ENDSWITH your-host.net
HELO 0 ENDSWITH cust-host.com
HELO 0 ENDSWITH cust-host.net
=
If you are not already running a test like this, try it out.  I think you
will find that it will flag lots of spam.
Bill

 



---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

Re: [Declude.JunkMail] Another very effective filter test

[Matthew Bramble]

Bill,

This looks to be more promising than filtering for forged MAILFROM's
(because of the FP's that exist there).  The spam that has gotten
through which forged the MAILFROM also forged the HELO, while the legit
stuff had appropriate HELO's listed.

I have one issue though that others might need to work around.  I have
MS SMTP on the same machine configured at the .16 address, however when
it hands off to my main domain, MS SMTP forges the IP as being that of
the server it's handing off to, .15 in this instance, but it uses the
proper name given to the MS SMTP server.  Here's an example:
Received: from webmail.igaia.com [208.7.179.15] by
igaia.com with ESMTP
  (SMTPD32-7.13) id A541250019C; Mon, 22 Sep 2003 18:18:41 -0400
Received: from mail pickup service by webmail.igaia.com with Microsoft
SMTPSVC;
Mon, 22 Sep 2003 18:18:41 -0400
Reply-To: "" 
From: "" 
To: "" 
Subject: Used Vehicle Inquiry - 
Date: Mon, 22 Sep 2003 18:18:41 -0400
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Message-ID: <[EMAIL PROTECTED]>
X-OriginalArrivalTime: 22 Sep 2003 22:18:41.0563 (UTC)
FILETIME=[7A9B1EB0:01C38157]
X-Declude-Sender:  [208.7.179.15]
X-Declude-Spoolname: D75410250019c9ee6.SMD
X-Note: This E-mail was scanned by iGaia Incorporated's E-mail service
(www.igaia.com) for spam.
X-Note: This E-mail was sent from igaia.com ([208.7.179.15]).
X-Spam-Tests-Failed: NOLEGITCONTENT, BCC-1, BCC-3, FORGEDASLOCAL,
DYNAMIC [0]
X-RCPT-TO: 
Status: U
X-UIDL: 364035046
  
Clearly this isn't proper behavior for MS SMTP (unless I'm mistaken
about something).  In this instance, it would be necessary to provide
exclusions for every instance of MS SMTP.  I'm not sure what happens
when MS SMTP forges the IP like this when hosted on a different server,
maybe one out of your control, but I suspect that happens also
according to the "Smart Host" if it is configured to hand off such
messages (as mine is).  If MS SMTP is configured to attempt delivery
itself, I would imagine that it will report the proper IP in the HELO.

Some software and hardware devices that send out notifications with
their own SMTP engine will also make the HELO whatever the
configuration says it is, and people will often use their own primary
mail domain in this which would FP on this test.  I have two such
devices from my customer base that are doing this.  Firewalls seem to
be the most common offenders.

Besides those two issues which people may need to work around, this
seems like a solid test.

I'm curious as to the exact format of the HELO that Declude matches
with this filter.  Based on your code, it suggests that the data
contains an IP address and ends with the sender's HELO domain.  I
thought that all that was matched with the HELO filter was the domain
name that is reported???  Could you clarify.  That will affect how I
exclude webmail.igaia.com from tripping the filter when it is received
by igaia.com.

You can answer that one tomorrow if you wish...I'm giving up on these
late-late nights.

Matt



Bill Landry wrote:

  This test is very effective at flagging or blocking spam from mail hosts
that attempt to connect to your mail server and announce your own hostnames
or IP addresses to it in their HELO string, especially if your IMail/Declude
server is directly sending and receiving mail from the Internet (less
functional, but still works if relaying via mail gateway to IMail/Declude).
This filter looks for the bogus HELO info in the headers.  In my testing,
100% of the messages delivered by these mail hosts is spam.

Think about it, why would any other legitimate mail server out there attempt
to connect to your mail server announcing your own hostname or IP address in
its HELO string?  The answer is, it wouldn't.  Anyway, here is the test I
use to detect these.

In global.cfg:
FORGEDHELO-FILTER filter M:\IMail\Declude\ForgedHelo-Filter.txt x 7 0

In ForgedHelo-Filter.txt file:
=
# In case you have mail gateways, deduct equal weight for these hosts
HELO -7 ENDSWITH gw1.yourdomain.com
HELO -7 ENDSWITH gw2.yourdomain.com

# Remote mail hosts connecting and announcing your IP addresses
HELO 0 CONTAINS xxx.xxx.xxx.
HELO 0 CONTAINS xxx.xxx.xxx.

# Remote mail hosts connection and announcing your hostnames
HELO 0 ENDSWITH your-host.com
HELO 0 ENDSWITH your-host.net
HELO 0 ENDSWITH cust-host.com
HELO 0 ENDSWITH cust-host.net
=

If you are not already running a test like this, try it out.  I think you
will find that it will flag lots of spam.

Bill

  

[Declude.JunkMail] Another very effective filter test

[Bill Landry]

This test is very effective at flagging or blocking spam from mail hosts
that attempt to connect to your mail server and announce your own hostnames
or IP addresses to it in their HELO string, especially if your IMail/Declude
server is directly sending and receiving mail from the Internet (less
functional, but still works if relaying via mail gateway to IMail/Declude).
This filter looks for the bogus HELO info in the headers.  In my testing,
100% of the messages delivered by these mail hosts is spam.

Think about it, why would any other legitimate mail server out there attempt
to connect to your mail server announcing your own hostname or IP address in
its HELO string?  The answer is, it wouldn't.  Anyway, here is the test I
use to detect these.

In global.cfg:
FORGEDHELO-FILTER filter M:\IMail\Declude\ForgedHelo-Filter.txt x 7 0

In ForgedHelo-Filter.txt file:
=
# In case you have mail gateways, deduct equal weight for these hosts
HELO -7 ENDSWITH gw1.yourdomain.com
HELO -7 ENDSWITH gw2.yourdomain.com

# Remote mail hosts connecting and announcing your IP addresses
HELO 0 CONTAINS xxx.xxx.xxx.
HELO 0 CONTAINS xxx.xxx.xxx.

# Remote mail hosts connection and announcing your hostnames
HELO 0 ENDSWITH your-host.com
HELO 0 ENDSWITH your-host.net
HELO 0 ENDSWITH cust-host.com
HELO 0 ENDSWITH cust-host.net
=

If you are not already running a test like this, try it out.  I think you
will find that it will flag lots of spam.

Bill



---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

[Declude.JunkMail] VeriSigns response to ICANN

[Bill Landry]

The VeriSign response:

http://www.icann.org/correspondence/lewis-to-twomey-21sep03.htm

Bill
---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

Re: [Declude.JunkMail] Bogus IP in headers

[Bill Landry]

- Original Message - 
From: "R. Scott Perry" <[EMAIL PROTECTED]>


> Do you have the full (or at least all the Received:) headers of such an
E-mail?

I couldn't locate a message with headers to show you for the "Bogus IP:
UNIX: localhost", but I did find one of the "Bogus IP: ?.?.?.?" messages,
here are the headers (again, e-mail addresses changed to protect the
innocent):

=
Received: from gw1.pointshare.com [204.189.38.4] by
intramail01.pointshare.net with ESMTP
  (SMTPD32-8.02) id A70911600050; Mon, 22 Sep 2003 17:42:49 -0700
Received: from lycos.com (www3.mail.lycos.com [209.202.220.160])
 by gw1.pointshare.com (Mail Gateway) with SMTP id D67DAADE47
 for <[EMAIL PROTECTED]>; Mon, 22 Sep 2003 17:42:43 -0700 (PDT)
Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Tue, 23 Sep 2003
00:42:24 -
To: [EMAIL PROTECTED]
Date: Mon, 22 Sep 2003 20:42:24 -0400
From: "Anish Ray" <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
X-Sent-Mail: off
Reply-To: [EMAIL PROTECTED]
X-Mailer: MailCity Service
X-Priority: 3
Subject: resume submission
X-Sender-Ip: 140.142.172.166
Organization: Lycos Mail  (http://www.mail.lycos.com:80)
Content-Type: multipart/mixed; boundary="=_-=_-IMMLKNJOFNOHJHAA"
Content-Transfer-Encoding: 7bit
X-IMAIL-SPAM-VALFROM: (291504208)
X-Alligate-In: FAILED - Score Adult: 9 (Req: 35) Spam: 21 (Req: 50) Tot: 30
(Req: 6)
X-Alligate-Tracking: 68886B86F3287CD0
X-Alligate-Signature: 884897994
X-Alligate-SpoolFile: D9709116000502df7.SMD
X-Alligate-Sender: [EMAIL PROTECTED] [209.202.220.160]
X-RBL-Warning: BLARSBL: This E-mail came from 209.202.220.160, a potential
spam source listed in BLARSBL.
X-RBL-Warning: COMPU: Sender IP: 209.202.220.138
X-RBL-Warning: LBL: 0.0.0.0.lbl.lagengymnastik.dk.
X-RBL-Warning: NOMOREFUNN: 0.0.0.0.no-more-funn.moensted.dk.
X-RBL-Warning: VISI-RELAY: Mail from 0.0.0.0 refused -- see
http://relays.visi.com/lookup.cgi?ipaddr=0.0.0.0
X-RBL-Warning: IPNOTINMX:
X-RBL-Warning: GIBBERISH-FILTER: Message failed GIBBERISH-FILTER test (132)
X-RBL-Warning: HEADERS-FILTER: Message failed HEADERS-FILTER test (58)
X-RBL-Warning: MAILFROM-FILTER: Message failed MAILFROM-FILTER test (1096)
X-RBL-Warning: NOGIBBERISH-FILTER: Message failed NOGIBBERISH-FILTER test
(52)
X-RBL-Warning: REVDNS-FILTER: Message failed REVDNS-FILTER test (59)
X-RBL-Warning: ALLIGATE-SPAM-L1: Message failed ALLIGATE-SPAM-L1: 30.
X-RBL-Warning: ALLIGATE-SPAM-L2: Message failed ALLIGATE-SPAM-L2: 30.
X-RBL-Warning: SNIFFER-GENERAL: Message failed SNIFFER-GENERAL: 63.
X-RBL-Warning: SPAMCHECK: Message failed SPAMCHECK: -3.
X-Declude-Sender: [EMAIL PROTECTED] [209.202.220.160]
X-Note: This e-mail was scanned for viruses & filtered for spam
X-Queue-File: D9709116000502df7.SMD - incoming
X-Note: Total spam test weight: 24
=

Bill

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

Re: [Declude.JunkMail] More logging issues

[Bill Landry]

- Original Message - 
From: "R. Scott Perry" <[EMAIL PROTECTED]>

> Declude JunkMail defaults to the IGNORE action if a test isn't listed.  So
> if you have no line stating which action to use in the global.cfg file,
> Declude JunkMail will assume you want to use the IGNORE action.

Okay, but if that's the case, it appears to only be running about 1/10th of
the tests I have defined.  Is there a way to disable the reporting of all
outgoing tests in the log file so that it does not skew my log reports?

Bill

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

Re: [Declude.JunkMail] More logging issues

[R. Scott Perry]

Scott, the message was outgoing, but I do not have any outgoing tests
configured in my global.cfg file, nor do I have any "IGNORE" actions set on
any incoming tests.
Declude JunkMail defaults to the IGNORE action if a test isn't listed.  So 
if you have no line stating which action to use in the global.cfg file, 
Declude JunkMail will assume you want to use the IGNORE action.

   -Scott
---
Declude JunkMail: The advanced anti-spam solution for IMail mailservers.
Declude Virus: Catches known viruses and is the leader in mailserver 
vulnerability detection.
Find out what you've been missing: Ask about our free 30-day evaluation.

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

Re: [Declude.JunkMail] Bogus IP in headers

[R. Scott Perry]

Scott, looks like people are starting to try and hide their internal IP
address through some rather bazaar means.  We have been getting quite a few
of these (e-mail addresses changed to protect the innocent):
Do you have the full (or at least all the Received:) headers of such an E-mail?

This should only happen if there is a gateway that is not properly 
recording the IP of the remote mailserver.

The problem with this is that if you using HOPHIGH 1 or greater, JunkMail is
running tests against the 0.0.0.0 address and coming back from the IP4R and
RHSBLs with a match.  I would request that JunkMail be set to never run
tests against the 0.0.0.0 IP address, unless that IP address actually shows
up in the received headers.
Declude JunkMail is already programmed to skip the IP-based spam tests if 
the IP is 0.0.0.0.  Unfortunately, while Declude JunkMail is able to scan 
multiple hops, there is a wide variety of formats that mailservers use to 
record IPs (since recording IPs isn't mandatory, so some do strange things 
like include the IP address in a non-standard format within a comment), and 
there are ways spammers can bypass them.  For example, if a mailserver 
doesn't use the proper format of "from hostname.example.com [192.0.2.25]", 
but instead uses "from hostname.example.com (192.0.2.25)", then a spammer 
could use a HELO of "[0.0.0.0]", which would change that to "from [0.0.0.0] 
(192.0.2.25)", in which case Declude JunkMail would see the IP as 0.0.0.0 
(which in fact it is in this case, according to the RFCs).

Hopefully, from the headers, I will be able to see if Declude JunkMail can 
be doing anything differently to handle this, and see why it may be looking 
up 0.0.0.0.

   -Scott
---
Declude JunkMail: The advanced anti-spam solution for IMail mailservers.
Declude Virus: Catches known viruses and is the leader in mailserver 
vulnerability detection.
Find out what you've been missing: Ask about our free 30-day evaluation.

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

Re: [Declude.JunkMail] More logging issues

[Bill Landry]

- Original Message - 
From: "R. Scott Perry" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 22, 2003 6:24 PM
Subject: Re: [Declude.JunkMail] More logging issues


>
> >Scott, I know I can figure this out by parsing the IMail logs, but I am
> >wondering why these messages have "Action=IGNORE" applied to them, but
> >without the "Subject" and "From/To" lines, there is no way to tell by
> >parsing just the Declude JunkMail logs:
>
> If it is an ongoing issue you are investigating, you can use "LOGLEVEL
> HIGH", which will record the file that Declude JunkMail gets the settings
> from, so you will know exactly which file has the action set to IGNORE
(the
> IGNORE action will also be used if the config file doesn't have any action
> listed for the test).

Scott, the message was outgoing, but I do not have any outgoing tests
configured in my global.cfg file, nor do I have any "IGNORE" actions set on
any incoming tests.  I did a column by column compare of my global.cfg tests
against my $default$.junkmail files in Excel, and all global tests were
defined in all $default$.junkmail files and all actions are set to WARN,
except PERCENT, which is set to HOLD.

I can set the logging to HIGH, but any ideas what else I should look at?

Bill

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

Re: [Declude.JunkMail] More logging issues

[R. Scott Perry]

Scott, I know I can figure this out by parsing the IMail logs, but I am
wondering why these messages have "Action=IGNORE" applied to them, but
without the "Subject" and "From/To" lines, there is no way to tell by
parsing just the Declude JunkMail logs:
If it is an ongoing issue you are investigating, you can use "LOGLEVEL 
HIGH", which will record the file that Declude JunkMail gets the settings 
from, so you will know exactly which file has the action set to IGNORE (the 
IGNORE action will also be used if the config file doesn't have any action 
listed for the test).

   -Scott
---
Declude JunkMail: The advanced anti-spam solution for IMail mailservers.
Declude Virus: Catches known viruses and is the leader in mailserver 
vulnerability detection.
Find out what you've been missing: Ask about our free 30-day evaluation.

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

[Declude.JunkMail] Bogus IP in headers

[Bill Landry]

Scott, looks like people are starting to try and hide their internal IP
address through some rather bazaar means.  We have been getting quite a few
of these (e-mail addresses changed to protect the innocent):

=
09/22/2003 11:00:41 Q38c433940072f11a Bogus IP: UNIX: localhost
09/22/2003 11:00:48 Q38c433940072f11a LBL:3 NOMOREFUNN:2 VISI-RELAY:3
nIPNOTINMX:-3 nNOLEGITCONTENT:-5 HELO-FILTER:-10 REVDNS
-FILTER:-5 ALLIGATE-SPAM-L1:1 .  Total weight = -14
09/22/2003 11:00:48 Q38c433940072f11a Msg failed LBL
(0.0.0.0.lbl.lagengymnastik.dk.). Action=IGNORE.
09/22/2003 11:00:48 Q38c433940072f11a Msg failed NOMOREFUNN
(0.0.0.0.no-more-funn.moensted.dk.). Action=WARN.
09/22/2003 11:00:48 Q38c433940072f11a Msg failed VISI-RELAY (Mail from
0.0.0.0 refused -- see http://relays.visi.com/lookup.c
gi?ipaddr=0.0.0.0). Action=WARN.
09/22/2003 11:00:48 Q38c433940072f11a Msg failed HELO-FILTER (Message failed
HELO-FILTER test (122)). Action=WARN.
09/22/2003 11:00:48 Q38c433940072f11a Msg failed REVDNS-FILTER (Message
failed REVDNS-FILTER test (78)). Action=WARN.
09/22/2003 11:00:48 Q38c433940072f11a Msg failed ALLIGATE-SPAM-L1 (Message
failed ALLIGATE-SPAM-L1: 12.). Action=WARN.
09/22/2003 11:00:48 Q38c433940072f11a L1 Message OK
09/22/2003 11:00:48 Q38c433940072f11a Subject: ipn Website Focus Group
Opportunity
09/22/2003 11:00:48 Q38c433940072f11a From: [EMAIL PROTECTED] To:
[EMAIL PROTECTED]  IP: 198.88.144.42 ID: 423
6CADF58
=

And a few of these, as well:

=
09/22/2003 17:43:40 Q9709116000502df7 Bogus IP: ?.?.?.?
09/22/2003 17:43:47 Q9709116000502df7 BLARSBL:2 COMPU:2 LBL:3 NOMOREFUNN:2
VISI-RELAY:3 nNOLEGITCONTENT:-5 GIBBERISH-FILTER:5 HEADERS-FILTER:5
MAILFROM-FILTER:10 NOGIBBERISH-FILTER:-5 REVDNS-FILTER:-10
ALLIGATE-SPAM-L1:1 ALLIGATE-SPAM-L2:2 SNIFFER-GENERAL:12 SPAMCHECK:-3 .
Total weight = 24
09/22/2003 17:43:47 Q9709116000502df7 Msg failed BLARSBL (This E-mail came
from 209.202.220.160, a potential spam source listed in BLARSBL.).
Action=WARN.
09/22/2003 17:43:47 Q9709116000502df7 Msg failed COMPU (Sender IP:
209.202.220.138). Action=WARN.
09/22/2003 17:43:47 Q9709116000502df7 Msg failed LBL
(0.0.0.0.lbl.lagengymnastik.dk.). Action=WARN.
09/22/2003 17:43:47 Q9709116000502df7 Msg failed NOMOREFUNN
(0.0.0.0.no-more-funn.moensted.dk.). Action=WARN.
09/22/2003 17:43:47 Q9709116000502df7 Msg failed VISI-RELAY (Mail from
0.0.0.0 refused -- see http://relays.visi.com/lookup.cgi?ipaddr=0.0.0.0).
Action=WARN.
09/22/2003 17:43:47 Q9709116000502df7 Msg failed IPNOTINMX (). Action=WARN.
09/22/2003 17:43:47 Q9709116000502df7 Msg failed GIBBERISH-FILTER (Message
failed GIBBERISH-FILTER test (132)). Action=WARN.
09/22/2003 17:43:47 Q9709116000502df7 Msg failed HEADERS-FILTER (Message
failed HEADERS-FILTER test (58)). Action=WARN.
09/22/2003 17:43:47 Q9709116000502df7 Msg failed MAILFROM-FILTER (Message
failed MAILFROM-FILTER test (1096)). Action=WARN.
09/22/2003 17:43:47 Q9709116000502df7 Msg failed NOGIBBERISH-FILTER (Message
failed NOGIBBERISH-FILTER test (52)). Action=WARN.
09/22/2003 17:43:47 Q9709116000502df7 Msg failed REVDNS-FILTER (Message
failed REVDNS-FILTER test (59)). Action=WARN.
09/22/2003 17:43:47 Q9709116000502df7 Msg failed ALLIGATE-SPAM-L1 (Message
failed ALLIGATE-SPAM-L1: 30.). Action=WARN.
09/22/2003 17:43:47 Q9709116000502df7 Msg failed ALLIGATE-SPAM-L2 (Message
failed ALLIGATE-SPAM-L2: 30.). Action=WARN.
09/22/2003 17:43:47 Q9709116000502df7 Msg failed SNIFFER-GENERAL (Message
failed SNIFFER-GENERAL: 63.). Action=WARN.
09/22/2003 17:43:47 Q9709116000502df7 Msg failed SPAMCHECK (Message failed
SPAMCHECK: -3.). Action=WARN.
09/22/2003 17:43:47 Q9709116000502df7 Msg failed WEIGHT16-35 (Total weight
between 16 and 35.). Action=HOLD.
09/22/2003 17:43:47 Q9709116000502df7 Subject: resume submission
09/22/2003 17:43:47 Q9709116000502df7 From: [EMAIL PROTECTED] To:
[EMAIL PROTECTED]  IP: 209.202.220.160 ID: D67DAADE47
=

The problem with this is that if you using HOPHIGH 1 or greater, JunkMail is
running tests against the 0.0.0.0 address and coming back from the IP4R and
RHSBLs with a match.  I would request that JunkMail be set to never run
tests against the 0.0.0.0 IP address, unless that IP address actually shows
up in the received headers.

Thanks,

Bill

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

[Declude.JunkMail] More logging issues

[Bill Landry]

Scott, I know I can figure this out by parsing the IMail logs, but I am
wondering why these messages have "Action=IGNORE" applied to them, but
without the "Subject" and "From/To" lines, there is no way to tell by
parsing just the Declude JunkMail logs:

=
09/22/2003 17:01:04 Q8d3c39c70054e638 nNOLEGITCONTENT:-5 REVDNS:1
GIBBERISH-FILTER:5 NOGIBBERISH-FILTER:-5 SUBJECT-FILTER:-3 VERP-FILTER:5
FORGED-DOMAINS:5 SPAMCHECK:-3 .  Total weight = 0
09/22/2003 17:01:04 Q8d3c39c70054e638 Msg failed REVDNS (This E-mail was
sent from a MUA/MTA 65.169.102.21 with no reverse DNS entry.).
Action=IGNORE.
09/22/2003 17:01:04 Q8d3c39c70054e638 Msg failed GIBBERISH-FILTER (Message
failed GIBBERISH-FILTER test (88)). Action=IGNORE.
09/22/2003 17:01:04 Q8d3c39c70054e638 Msg failed NOGIBBERISH-FILTER (Message
failed NOGIBBERISH-FILTER test (86)). Action=IGNORE.
09/22/2003 17:01:04 Q8d3c39c70054e638 Msg failed SUBJECT-FILTER (Message
failed SUBJECT-FILTER test (130)). Action=IGNORE.
09/22/2003 17:01:04 Q8d3c39c70054e638 Msg failed VERP-FILTER (Message failed
VERP-FILTER test (11)). Action=IGNORE.
09/22/2003 17:01:04 Q8d3c39c70054e638 Msg failed FORGED-DOMAINS (Spamdomain
'@cwhealth.net' found: Address of [EMAIL PROTECTED] sent from invalid [No
Reverse DNS].). Action=IGNORE.
09/22/2003 17:01:04 Q8d3c39c70054e638 Msg failed SPAMCHECK (Message failed
SPAMCHECK: -3.). Action=IGNORE.
09/22/2003 17:01:04 Q8d3c39c70054e638 R1 Message OK
=

Running Declude v1.76i1, with log level set to MID.

Bill

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[Joshua Levitsky]

I know, but was just showing that people are writing things with the assumption that .local will never exist.


On Sep 22, 2003, at 5:47 PM, Matthew Bramble wrote:

Josh,

>From that RFC:

The IESG notes that this mechanism makes use of the .local top-level domain (TLD) internally when handling host names that don't contain any dots, and that this mechanism might not work in the expected way should an actual .local TLD ever be registered. 

Probably safe, but by no means assured at this point.

Matt

[Declude.JunkMail] identifying actual WORDFILTER trigger

[decjunkmail]

Hi,

Is there a toggle or setting that will put enable the WORDFILTER to append the actual 
phrase to the headers of the email?

We're filtering on a lot of stuff and need to prune it back.

Examining the headers of FP messages would be the easiest but they only confirm the 
WORDFILTER and not the actual match phrase

(Did a quick check of the archives and could not find any info on this)
---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

[Declude.JunkMail] SUBJECTSPACES

[John Tolmachoff \(Lists\)]

I have come across legit messages that were caught by this because some
stupid person had lots of spaces after the last word or character.

Is there a way we can mitigate this by ignoring subject spaces after the
last character?

John Tolmachoff MCSE CSSA
Engineer/Consultant
eServices For You
www.eservicesforyou.com



---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[Matthew Bramble]

Josh,

>From that RFC:
The IESG notes that this mechanism makes use of the .local
top-level domain (TLD) internally when handling host names that don't
contain any dots, and that this mechanism might not work in the
expected way should an actual .local TLD ever be registered.
  

Probably safe, but by no means assured at this point.

Matt


Joshua Levitsky wrote:

  
On Sep 22, 2003, at 3:05 PM, Matthew Bramble wrote:
  
  
   do see the reasoning in either owning the domain or
using a
fake TLD.  Eventually the fake TLDs though could come back and haunt
users if they are ever allowed to be registered for Internet use.  I
believe that will happen some day.

  
  
I have always been told, and in talking to others gotten the same
feeling that ".local" would never be made a TLD. People make that
assumption in recent RFCs... 
  
ftp://ftp.isi.edu/in-notes/rfc2965.txt
  
  
-Josh
  

RE: [Declude.JunkMail] OT: VerySinn disrupts LAN traffic

[John Tolmachoff \(Lists\)]

Title: Message









Maybe, just maybe, people will start to
realize that hiring someone to do their AD for cheap is not a good idea.

 

You get what you pay for.

 

I can not count the number of AD setup
jobs I did not get because they found some one that would do it for 1/3 the price.
I tried to warn them…

 





John Tolmachoff MCSE CSSA

Engineer/Consultant

eServices For You

www.eservicesforyou.com





 



-Original Message-
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Schmidt
Sent: Monday, September 22, 2003 12:04 PM
To: [EMAIL PROTECTED]
Subject: RE: [Declude.JunkMail]
OT: VerySinn disrupts LAN traffic

 



There are reports of people's printers
that stopped working. Essentially, TCP/IP connected printers on a local LAN set
up by an ignorant network "admin" with an invalid domain
name, connected to a local print server.  Somehow, the workstations
FIRST did a lookup by the (invalid) host/domain name - and would get a negative
response from the external DNS.  Then they would do internal name
resolution and the printer could be found.





 





After VerySinn's move, the external
resolution now points to VerySinn - and the result is a printer failure in a
local LAN.





 





The point is, who knows how many things
relied on the proper "not found" response to domain lookups - that
are now broken and someone will waste time trying to figure out what changed.



 

Best Regards
Andy Schmidt

H&M
Systems Software, Inc.
600 East Crescent
Avenue, Suite
 203
Upper Saddle River,
 NJ 07458-1846

Phone:  +1 201 934-3414 x20 (Business)
Fax:    +1 201 934-9206

http://www.HM-Software.com/ 

Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[Joshua Levitsky]

On Sep 22, 2003, at 3:05 PM, Matthew Bramble wrote:

do see the reasoning in either owning the domain or using a fake TLD.  Eventually the fake TLDs though could come back and haunt users if they are ever allowed to be registered for Internet use.  I believe that will happen some day.

I have always been told, and in talking to others gotten the same feeling that ".local" would never be made a TLD. People make that assumption in recent RFCs... 

ftp://ftp.isi.edu/in-notes/rfc2965.txt

-Josh

Re: [Declude.JunkMail] country filter question

[R. Scott Perry]

Is it OK to put comments in the country TXT filter file? Such as adding the
name of the country at the end? For instamce:
COUNTRIES   0   CONTAINSSE  sweden

('cause i may forget what some of the codes represent.)
No.  Otherwise, Declude JunkMail will look for "SE sweden" in the list 
of countries that the E-mail passed through.  You can, however, have a line 
before it that has a comment, if it starts with "#".

   -Scott
---
Declude JunkMail: The advanced anti-spam solution for IMail mailservers.
Declude Virus: Catches known viruses and is the leader in mailserver 
vulnerability detection.
Find out what you've been missing: Ask about our free 30-day evaluation.

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

RE: [Declude.JunkMail] OT: VerySinn disrupts LAN traffic

[Andy Schmidt]

Title: Message



There 
are reports of people's printers that stopped working. Essentially, TCP/IP 
connected printers on a local LAN set up by an ignorant network "admin" 
with an invalid domain name, connected to a local print server.  
Somehow, the workstations FIRST did a lookup by the (invalid) host/domain name - 
and would get a negative response from the external DNS.  Then they would 
do internal name resolution and the printer could be found.
 
After 
VerySinn's move, the external resolution now points to VerySinn - and the result 
is a printer failure in a local LAN.
 
The 
point is, who knows how many things relied on the proper "not found" response to 
domain lookups - that are now broken and someone will waste time trying to 
figure out what changed.
Best 
RegardsAndy SchmidtH&M Systems Software, Inc.600 East Crescent 
Avenue, Suite 203Upper Saddle River, NJ 07458-1846Phone:  +1 201 934-3414 x20 
(Business)Fax:    +1 201 934-9206http://www.HM-Software.com/ 

RE: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[ISPhuset Nordic / Benny Samuelsen]

It was 
a combination but the main problem was the domain they used, that solved it 
cleared up most of the problems



From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Matthew 
BrambleSent: 22. september 2003 21:00To: 
[EMAIL PROTECTED]

Clearly the problem was deeper than just the domain they 
choose, there were issues with their overall architecture.  Was that not 
the case?MattISPhuset Nordic / Benny Samuelsen 
wrote:

  
  sure 
  but yuo will still have the same problem as i see it if I fex register the 
  domain then I can "steal" the traffic... its the same 
  result.
   
  I 
  have an ex. hereon a company who set up there system like this and they could 
  suddenly not send internal mail anymore... why wll someone had registered the 
  domain they used as an internal domain... 600 users couldnt send mail for 8 
  weeks cost them big money to fix this
  
  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]] 
  On Behalf Of Matthew BrambleSent: 22. september 2003 
  20:19To: [EMAIL PROTECTED]
  ISPhuset Nordic / Benny Samuelsen wrote:
  

Thats why you are supposed to use fex 
  .locThat makes some sense, however there has 
  been plenty of talk about allowing an infinite number of TLD's on the 
  Internet.  Also, many companies actually use a sub-directory of their 
  primary domain for their Active Directory.  I believe that your AD server 
  would be sending lookups out to the root servers even if you used .loc as your 
  TLD, the only difference is that .loc won't return SiteFinder, but something 
  on .com and .net will now, but before it worked the same as .loc as long as 
  your name wasn't registered.
   if fex someone register this domain u use and then 
someone on the inside want to send an email to to them it will never get 
trough Only if your E-mail server is behind 
  your Active Directory server.  I can't see why you would want to do 
  that.  My Web/mail server doesn't use Active Directory and is located 
  off-site.
  
Jesus this is so basic in AD i thought most people know about those 
failuresWhen I set up my AD server, I spent 
  dozens of hours trying to figure the thing out by reading just about every 
  document on Microsoft's Web site that I could find.  No where did I ever 
  see such a thing mentioned.  As things stand, I wasted enough time 
  setting up AD for what is currently a 2 computer network and I'm sure that 
  many others feel the same way.  I'm quite happy with my internal name 
  also, and have no interest in changing it.  If I want to register it, 
  it's only $10 a year.What I'm pointing to with this is actually 
  support for why something needs to be returned by the root servers saying 
  record doesn't exist instead of just matching whatever they get with their 
  site, even processing the E-mail that is received which would otherwise be 
  unaddressable.Matt
  


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED]] 
On Behalf Of Matthew BrambleSent: 22. september 2003 
19:40To: [EMAIL PROTECTED]
Who says that I have to register the domain that 
Active Directory is using?  My Active Directory name isn't intended to 
be used on the Internet.  In most installations, you look to your own 
Active Directory server first for the lookups, so if it exists on the 
Internet it won't interfeer...until now.I think this is one of the 
issues that ICANN was talking about concerning how the change can have 
unintended consequences (besides spam blockers).  This also looks to be 
a problem in general with how Microsoft delegates lookups.  Their 
software shouldn't take the root of your Active Directory tree and then 
append sub-domains to it and turn to the root servers for resolution.  
That appears to be a security risk if you ask me, and it doesn't make sense 
to do.MattJohn Tolmachoff (Lists) wrote:
Ah yes, using an unregistered domain name with a real TLD is a no-no. When
are people using AD going to get this?
 
AD must be configured correctly or else problems will come up when you least
expect it.
 
John Tolmachoff MCSE CSSA
Engineer/Consultant
eServices For You
www.eservicesforyou.com
 
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Bramble
Sent: Monday, September 22, 2003 12:52 AM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your
domain.
 
I figured it out.  The problem is definitely with Active Directory.  Turning
off DNS Client on the local server only created a situation where their
first bogus sub-domain would timeout but a retry would still go to
SiteFinder.  Here's what nslookup returns when directed at the DNS server on
the co-located machine (not running Active Directory):
  
  adsfadsfasfdadsf.declude.com
Server:  ns1.igaia.com
Address:  208.7.179.11

Non-authoritative answer:
Name:    adsfadsfasfdadsf.declude.com.primary.igai

[Declude.JunkMail] country filter question

[Doug Bevins]

Is it OK to put comments in the country TXT filter file? Such as adding the
name of the country at the end? For instamce:

COUNTRIES   0   CONTAINSSE  sweden

('cause i may forget what some of the codes represent.)

Thanks,

Doug

Doug Bevins, Systems Manager
Record-Journal, 11 Crown St., Meriden CT 06450
Phone (203) 317-2223 Fax (203) 317-2233
[EMAIL PROTECTED]



---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

RE: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[R. Scott Perry]

The MS example I saw was to use a domain that ended .local if you did not 
want to use a real/public domain.  This seems to work, let s hope that 
.local never becomes a real tld.
It may.  MS needs to update their example -- it should be ".localhost" (or 
.test, .example, or .invalid).  Those TLDs are defined by RFC2606 and are 
guaranteed never to become real TLDs.

   -Scott
---
Declude JunkMail: The advanced anti-spam solution for IMail mailservers.
Declude Virus: Catches known viruses and is the leader in mailserver 
vulnerability detection.
Find out what you've been missing: Ask about our free 30-day evaluation.

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

[Declude.JunkMail] SWEN

[Kevin Bilbee]

I have come up with a filter that catches the SWEN virus emails and bounces.
The only false positives in the last three days have come from CNN.com being
caught on line 3. They are using and Iframe and also include a link to a
javascript (what are they thinking!).

BODY 0 CONTAINS Message follows:
BODY 0 CONTAINS Undeliverable to
BODY 0 CONTAINS http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

RE: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[Jonathan C Miller]

The MS example I saw was to use a domain
that ended .local if you did not want
to use a real/public domain.  This seems to work, let’s hope that
.local never becomes a real tld.

 



Sincerely,

 

Jonathan Miller

Internet Service Department

ACCS.net

Advanced Computer & Communication Systems, Inc.











From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Matthew Bramble
Sent: Monday, September 22, 2003 2:05 PM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail]
VeriSteal is stealing traffic from your domain.



 

This AD server is over 2 years old.  Support was
very weak back then.  It was set up as a trial of AD so I could see if
there was any benefit to using it on my production server.  I decided that
is was not useful and too many problems existed.

I do see the reasoning in either owning the domain or using a fake TLD. 
Eventually the fake TLDs though could come back and haunt users if they are
ever allowed to be registered for Internet use.  I believe that will
happen some day.

Matt



Joshua Levitsky wrote:





On Sep 22, 2003,
at 1:40 PM, Matthew
Bramble wrote: 

Who says that I have to
register the domain that Active Directory is using?  My Active Directory
name isn't intended to be used on the Internet.  In most installations,
you look to your own Active Directory server first for the lookups, so if it
exists on the Internet it won't interfeer...until now. 


In my MCSE class the Microsoft printed material said to use ".local"
if you didn't have an internet domain. I always do it that way when the company
I do consulting for doesn't have a domain or if they have a domain and the mail
/ web is at a hosting company. If the domain isn't totally in-house then I use
.local 

-Josh 

 

Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[Matthew Bramble]

Clearly the problem was deeper than just the domain they choose, there
were issues with their overall architecture.  Was that not the case?

Matt



ISPhuset Nordic / Benny Samuelsen wrote:

  
  
  
  sure but yuo will still have the same problem
as i see it if I fex register the domain then I can "steal" the
traffic... its the same result.
   
  I have an ex. hereon a company who set up
there system like this and they could suddenly not send internal mail
anymore... why wll someone had registered the domain they used as an
internal domain... 600 users couldnt send mail for 8 weeks cost them
big money to fix this
  
  
  
  
  From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Matthew
Bramble
  Sent: 22. september 2003 20:19
  To: [EMAIL PROTECTED]
  
  
  
ISPhuset Nordic / Benny Samuelsen wrote:
  
  

Thats why you are supposed to use fex .loc
  
That makes some sense, however there has been plenty of talk about
allowing an infinite number of TLD's on the Internet.  Also, many
companies actually use a sub-directory of their primary domain for
their Active Directory.  I believe that your AD server would be sending
lookups out to the root servers even if you used .loc as your TLD, the
only difference is that .loc won't return SiteFinder, but something on
.com and .net will now, but before it worked the same as .loc as long
as your name wasn't registered.
  
   if
fex someone register this domain u use and then someone on the inside
want to send an email to to them it will never get trough 
Only if your E-mail server is behind your Active Directory server.  I
can't see why you would want to do that.  My Web/mail server doesn't
use Active Directory and is located off-site.
  
  
Jesus this is so basic in AD i thought most
people know about those failures
  
When I set up my AD server, I spent dozens of hours trying to figure
the thing out by reading just about every document on Microsoft's Web
site that I could find.  No where did I ever see such a thing
mentioned.  As things stand, I wasted enough time setting up AD for
what is currently a 2 computer network and I'm sure that many others
feel the same way.  I'm quite happy with my internal name also, and
have no interest in changing it.  If I want to register it, it's only
$10 a year.
  
What I'm pointing to with this is actually support for why something
needs to be returned by the root servers saying record doesn't exist
instead of just matching whatever they get with their site, even
processing the E-mail that is received which would otherwise be
unaddressable.
  
Matt
  
  
  

 From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of Matthew Bramble
Sent: 22. september 2003 19:40
To: [EMAIL PROTECTED]


Who says that I have to register the
domain that Active Directory is using?  My Active Directory name isn't
intended to be used on the Internet.  In most installations, you look
to your own Active Directory server first for the lookups, so if it
exists on the Internet it won't interfeer...until now.

I think this is one of the issues that ICANN was talking about
concerning how the change can have unintended consequences (besides
spam blockers).  This also looks to be a problem in general with how
Microsoft delegates lookups.  Their software shouldn't take the root of
your Active Directory tree and then append sub-domains to it and turn
to the root servers for resolution.  That appears to be a security risk
if you ask me, and it doesn't make sense to do.

Matt



John Tolmachoff (Lists) wrote:


  Ah yes, using an unregistered domain name with a real TLD is a no-no. When
are people using AD going to get this?
 
AD must be configured correctly or else problems will come up when you least
expect it.
 
John Tolmachoff MCSE CSSA
Engineer/Consultant
eServices For You
www.eservicesforyou.com
 
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Bramble
Sent: Monday, September 22, 2003 12:52 AM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your
domain.
 
I figured it out.  The problem is definitely with Active Directory.  Turning
off DNS Client on the local server only created a situation where their
first bogus sub-domain would timeout but a retry would still go to
SiteFinder.  Here's what nslookup returns when directed at the DNS server on
the co-located machine (not running Active Directory):
  
  
adsfadsfasfdadsf.declude.com

  
  Server:  ns1.igaia.com
Address:  208.7.179.11

Non-authoritative answer:
Name:    adsfadsfasfdadsf.declude.com.primary.igaiaoffice.com
Address:  64.94.110.11
That's the bogus sub-domain appended to my local Active Directory domain
(replaced for security with an equivalent).   The issue relates to the fact
that my real Active Directory domain name is not registered and lies in the
.com namespace, so when the lookup

RE: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[ISPhuset Nordic / Benny Samuelsen]

bad 
example
 
the 
problem is anyway here that he is using a .com domain in his AD and that shall 
not be used if he hasn't registered it and have in house or are setting up  
forwarders for this



From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Joshua 
LevitskySent: 22. september 2003 20:53To: 
[EMAIL PROTECTED]

On Sep 22, 2003, at 1:51 PM, ISPhuset Nordic / Benny 
Samuelsen wrote:
if 
  fex someone register this domain u use and then someone on the inside want to 
  send an email to to them it will never get trough That's not true 
unless you try to email a person using their AD contact info, and even then you 
can tell the AD object to have an email address that is legit. If the domain he 
used was even registered to someone else it has nothing to do with IMail 
email... unless he was maybe using NT accounts as the accounts database 
maybe.. and in that scenario I am not sure what would 
happen.-Josh

Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[Matthew Bramble]

Well, $10 fixes my "problem," but I'm really not concerned with fixing 
it, though I might register that domain name anyway.  And ICANN has no 
claim to names used on a private network.

What's new/strange to me is that my primary is the non-AD server that 
has no clue that my local AD server/domain exists.  My computer looks up 
fake.declude.com on my external AD-unaware server and returns no record 
exists, but then my computer does another lookup using my AD-server's 
domain and appends fake.declude.com to it.   Maybe this wouldn't happen 
if I was using my local AD server as my primary, but I purposefully 
chose the external DNS server for testing purposes, and I'm going to 
keep it that way.  Clearly Microsoft intended on providing some form of 
functionality, but the result is that a Web browser doesn't see the IP 
being returned as being appended to my AD domain, it just sees it as 
being the un-resolveable yet registered domain, fake.declude.com.

Matt



John Tolmachoff (Lists) wrote:

Problem1. If the AD domain is called 123exampleforme.com, and someone 
registers that on the internet, you are now according to ICANNA 
regulations illegally using a registered name.

 

Problem 2. If you do not have forwarders properly configured in the 
DNS server that is used, you are querring the root servers, which are 
controlled by Verisign. Therefore, you are subject to that control.

 

This is way it is always recommended that if you are going to use a 
unregistered domain name in AD, you use a fake TLD, such as .moc or 
.abc or .mine or such AND have forwarders properly configured.

 

John Tolmachoff MCSE CSSA

Engineer/Consultant

eServices For You

www.eservicesforyou.com

 

-Original Message-
From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble
Sent: Monday, September 22, 2003 10:40 AM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from 
your domain.

 

Who says that I have to register the domain that Active Directory is 
using?  My Active Directory name isn't intended to be used on the 
Internet.  In most installations, you look to your own Active 
Directory server first for the lookups, so if it exists on the 
Internet it won't interfeer...until now.

I think this is one of the issues that ICANN was talking about 
concerning how the change can have unintended consequences (besides 
spam blockers).  This also looks to be a problem in general with how 
Microsoft delegates lookups.  Their software shouldn't take the root 
of your Active Directory tree and then append sub-domains to it and 
turn to the root servers for resolution.  That appears to be a 
security risk if you ask me, and it doesn't make sense to do.

Matt



John Tolmachoff (Lists) wrote:

Ah yes, using an unregistered domain name with a real TLD is a no-no. When

are people using AD going to get this?



AD must be configured correctly or else problems will come up when you least

expect it.



John Tolmachoff MCSE CSSA

Engineer/Consultant

eServices For You

www.eservicesforyou.com 



-Original Message-

From: [EMAIL PROTECTED] 

[mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble

Sent: Monday, September 22, 2003 12:52 AM

To: [EMAIL PROTECTED] 

Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your

domain.



I figured it out.  The problem is definitely with Active Directory.  Turning

off DNS Client on the local server only created a situation where their

first bogus sub-domain would timeout but a retry would still go to

SiteFinder.  Here's what nslookup returns when directed at the DNS server on

the co-located machine (not running Active Directory):

 

adsfadsfasfdadsf.declude.com

   

Server:  ns1.igaia.com

Address:  208.7.179.11



Non-authoritative answer:

Name:adsfadsfasfdadsf.declude.com.primary.igaiaoffice.com

Address:  64.94.110.11

That's the bogus sub-domain appended to my local Active Directory domain

(replaced for security with an equivalent).   The issue relates to the fact

that my real Active Directory domain name is not registered and lies in the

.com namespace, so when the lookup fails on the primary server, it goes back

to the local Active Directory server and appends the lookup that produces no

match to my unregistered Active Directory name, which returns the IP for

SiteFinder.  If I registered my Active Directory name, I wouldn't be

directed to SiteFinder.



Make sense now?



Matt

 

 

Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[Matthew Bramble]

This AD server is over 2 years old.  Support was very weak back then. 
It was set up as a trial of AD so I could see if there was any benefit
to using it on my production server.  I decided that is was not useful
and too many problems existed.

I do see the reasoning in either owning the domain or using a fake
TLD.  Eventually the fake TLDs though could come back and haunt users
if they are ever allowed to be registered for Internet use.  I believe
that will happen some day.

Matt



Joshua Levitsky wrote:

  
On Sep 22, 2003, at 1:40 PM, Matthew Bramble wrote:
  
  
  Who says that I have to register the domain that Active
Directory is using?  My Active Directory name isn't intended to be
used on the Internet.  In most installations, you look to your own
Active Directory server first for the lookups, so if it exists on the
Internet it won't interfeer...until now.


  
  
In my MCSE class the Microsoft printed material said to use ".local"
if you didn't have an internet domain. I always do it that way when
the company I do consulting for doesn't have a domain or if they have
a domain and the mail / web is at a hosting company. If the domain
isn't totally in-house then I use .local
  
  
-Josh
  

Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[Bill Landry]

Just one minor clarification:  VeriSign does not control the root servers, only the 
.com and .net TLDs that the root servers refer to.

Bill
  - Original Message - 
  From: John Tolmachoff (Lists) 
  To: [EMAIL PROTECTED] 
  Sent: Monday, September 22, 2003 11:31 AM
  Subject: RE: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.


  Problem1. If the AD domain is called 123exampleforme.com, and someone registers that 
on the internet, you are now according to ICANNA regulations illegally using a 
registered name.



  Problem 2. If you do not have forwarders properly configured in the DNS server that 
is used, you are querring the root servers, which are controlled by Verisign. 
Therefore, you are subject to that control.



  This is way it is always recommended that if you are going to use a unregistered 
domain name in AD, you use a fake TLD, such as .moc or .abc or .mine or such AND have 
forwarders properly configured.



  John Tolmachoff MCSE CSSA

  Engineer/Consultant

  eServices For You

  www.eservicesforyou.com



  -Original Message-
  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble
  Sent: Monday, September 22, 2003 10:40 AM
  To: [EMAIL PROTECTED]
  Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.



  Who says that I have to register the domain that Active Directory is using?  My 
Active Directory name isn't intended to be used on the Internet.  In most 
installations, you look to your own Active Directory server first for the lookups, so 
if it exists on the Internet it won't interfeer...until now.

  I think this is one of the issues that ICANN was talking about concerning how the 
change can have unintended consequences (besides spam blockers).  This also looks to 
be a problem in general with how Microsoft delegates lookups.  Their software 
shouldn't take the root of your Active Directory tree and then append sub-domains to 
it and turn to the root servers for resolution.  That appears to be a security risk if 
you ask me, and it doesn't make sense to do.

  Matt



  John Tolmachoff (Lists) wrote:



Ah yes, using an unregistered domain name with a real TLD is a no-no. Whenare people 
using AD going to get this? AD must be configured correctly or else problems will come 
up when you leastexpect it. John Tolmachoff MCSE CSSAEngineer/ConsultanteServices For 
Youwww.eservicesforyou.com -Original Message-From: [EMAIL PROTECTED]:[EMAIL 
PROTECTED] On Behalf Of Matthew BrambleSent: Monday, September 22, 2003 12:52 AMTo: 
[EMAIL PROTECTED]: Re: [Declude.JunkMail] VeriSteal is stealing traffic from 
yourdomain. I figured it out.  The problem is definitely with Active Directory.  
Turningoff DNS Client on the local server only created a situation where theirfirst 
bogus sub-domain would timeout but a retry would still go toSiteFinder.  Here's what 
nslookup returns when directed at the DNS server onthe co-located machine (not running 
Active Directory):  adsfadsfasfdadsf.declude.comServer:  ns1.igaia.comAddress:  
208.7.179.11 Non-authoritative answer:Name:
adsfadsfasfdadsf.declude.com.primary.igaiaoffice.comAddress:  64.94.110.11That's the 
bogus sub-domain appended to my local Active Directory domain(replaced for security 
with an equivalent).   The issue relates to the factthat my real Active Directory 
domain name is not registered and lies in the.com namespace, so when the lookup fails 
on the primary server, it goes backto the local Active Directory server and appends 
the lookup that produces nomatch to my unregistered Active Directory name, which 
returns the IP forSiteFinder.  If I registered my Active Directory name, I wouldn't 
bedirected to SiteFinder. Make sense now? Matt  

Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[Joshua Levitsky]

On Sep 22, 2003, at 1:40 PM, Matthew Bramble wrote:

Who says that I have to register the domain that Active Directory is using?  My Active Directory name isn't intended to be used on the Internet.  In most installations, you look to your own Active Directory server first for the lookups, so if it exists on the Internet it won't interfeer...until now.


In my MCSE class the Microsoft printed material said to use ".local" if you didn't have an internet domain. I always do it that way when the company I do consulting for doesn't have a domain or if they have a domain and the mail / web is at a hosting company. If the domain isn't totally in-house then I use .local

-Josh

Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[Joshua Levitsky]

On Sep 22, 2003, at 1:51 PM, ISPhuset Nordic / Benny Samuelsen wrote:

if fex someone register this domain u use and then someone on the inside want to send an email to to them it will never get trough 

That's not true unless you try to email a person using their AD contact info, and even then you can tell the AD object to have an email address that is legit. If the domain he used was even registered to someone else it has nothing to do with IMail email... unless he was maybe using NT accounts as the accounts database maybe.. and in that scenario I am not sure what would happen.

-Josh

RE: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[John Tolmachoff \(Lists\)]

> When I set up my AD server, I spent dozens of hours trying to figure the
thing out by reading just about every document on Microsoft's Web site that
I could find.  No where did I ever see such a thing mentioned.  As things
stand, I wasted enough time setting up AD for what is currently a 2 computer
network and I'm sure that many others feel the same way.  I'm quite happy
with my internal name also, and have no interest in changing it.  If I want
to register it, it's only $10 a year.

Who ever said MS gets all their documentation correct? If you are solely
relaying on MS documentation... (BTW, it is well known MS documentation is
the weak link.)

> What I'm pointing to with this is actually support for why something needs
to be returned by the root servers saying record doesn't exist instead of
just matching whatever they get with their site, even processing the E-mail
that is received which would otherwise be unaddressable.

That is also why it is not recommend to relay on the root servers. Instead,
you should be using forwarders.

John Tolmachoff MCSE CSSA
Engineer/Consultant
eServices For You
www.eservicesforyou.com


---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

RE: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[ISPhuset Nordic / Benny Samuelsen]

sure 
but yuo will still have the same problem as i see it if I fex register the 
domain then I can "steal" the traffic... its the same 
result.
 
I have 
an ex. hereon a company who set up there system like this and they could 
suddenly not send internal mail anymore... why wll someone had registered the 
domain they used as an internal domain... 600 users couldnt send mail for 8 
weeks cost them big money to fix this



From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Matthew 
BrambleSent: 22. september 2003 20:19To: 
[EMAIL PROTECTED]

ISPhuset Nordic / Benny Samuelsen wrote:

  
  Thats why you are supposed to use fex 
.locThat makes some sense, however there has 
been plenty of talk about allowing an infinite number of TLD's on the 
Internet.  Also, many companies actually use a sub-directory of their 
primary domain for their Active Directory.  I believe that your AD server 
would be sending lookups out to the root servers even if you used .loc as your 
TLD, the only difference is that .loc won't return SiteFinder, but something on 
.com and .net will now, but before it worked the same as .loc as long as your 
name wasn't registered.
 if fex someone 
  register this domain u use and then someone on the inside want to send an 
  email to to them it will never get trough Only if 
your E-mail server is behind your Active Directory server.  I can't see why 
you would want to do that.  My Web/mail server doesn't use Active Directory 
and is located off-site.

  Jesus this is so basic in AD i thought most people know about those 
  failuresWhen I set up my AD server, I spent 
dozens of hours trying to figure the thing out by reading just about every 
document on Microsoft's Web site that I could find.  No where did I ever 
see such a thing mentioned.  As things stand, I wasted enough time setting 
up AD for what is currently a 2 computer network and I'm sure that many others 
feel the same way.  I'm quite happy with my internal name also, and have no 
interest in changing it.  If I want to register it, it's only $10 a 
year.What I'm pointing to with this is actually support for why 
something needs to be returned by the root servers saying record doesn't exist 
instead of just matching whatever they get with their site, even processing the 
E-mail that is received which would otherwise be 
unaddressable.Matt

  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]] 
  On Behalf Of Matthew BrambleSent: 22. september 2003 
  19:40To: [EMAIL PROTECTED]
  Who says that I have to register the domain that 
  Active Directory is using?  My Active Directory name isn't intended to be 
  used on the Internet.  In most installations, you look to your own Active 
  Directory server first for the lookups, so if it exists on the Internet it 
  won't interfeer...until now.I think this is one of the issues that 
  ICANN was talking about concerning how the change can have unintended 
  consequences (besides spam blockers).  This also looks to be a problem in 
  general with how Microsoft delegates lookups.  Their software shouldn't 
  take the root of your Active Directory tree and then append sub-domains to it 
  and turn to the root servers for resolution.  That appears to be a 
  security risk if you ask me, and it doesn't make sense to 
  do.MattJohn Tolmachoff (Lists) wrote:
  Ah yes, using an unregistered domain name with a real TLD is a no-no. When
are people using AD going to get this?
 
AD must be configured correctly or else problems will come up when you least
expect it.
 
John Tolmachoff MCSE CSSA
Engineer/Consultant
eServices For You
www.eservicesforyou.com
 
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Bramble
Sent: Monday, September 22, 2003 12:52 AM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your
domain.
 
I figured it out.  The problem is definitely with Active Directory.  Turning
off DNS Client on the local server only created a situation where their
first bogus sub-domain would timeout but a retry would still go to
SiteFinder.  Here's what nslookup returns when directed at the DNS server on
the co-located machine (not running Active Directory):
  
adsfadsfasfdadsf.declude.com
Server:  ns1.igaia.com
Address:  208.7.179.11

Non-authoritative answer:
Name:    adsfadsfasfdadsf.declude.com.primary.igaiaoffice.com
Address:  64.94.110.11
That's the bogus sub-domain appended to my local Active Directory domain
(replaced for security with an equivalent).   The issue relates to the fact
that my real Active Directory domain name is not registered and lies in the
.com namespace, so when the lookup fails on the primary server, it goes back
to the local Active Directory server and appends the lookup that produces no
match to my unregistered Active Directory name, which returns the IP for
SiteFinder.  If I registered my Active Directory name, I wouldn't be
directed to SiteFinder.

Make

RE: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[John Tolmachoff \(Lists\)]

Problem1. If the AD domain is called
123exampleforme.com, and someone registers that on the internet, you are now
according to ICANNA regulations illegally using a registered name.

 

Problem 2. If you do not have forwarders
properly configured in the DNS server that is used, you are querring the root
servers, which are controlled by Verisign. Therefore, you are subject to that
control.

 

This is way it is always recommended
that if you are going to use a unregistered domain name in AD, you use a fake
TLD, such as .moc or .abc or .mine or such AND have forwarders properly
configured.

 





John Tolmachoff MCSE CSSA

Engineer/Consultant

eServices For You

www.eservicesforyou.com





 



-Original Message-
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble
Sent: Monday, September 22, 2003 10:40 AM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail]
VeriSteal is stealing traffic from your domain.

 

Who says that I have to register the domain that
Active Directory is using?  My Active Directory name isn't intended to be
used on the Internet.  In most installations, you look to your own Active
Directory server first for the lookups, so if it exists on the Internet it
won't interfeer...until now.

I think this is one of the issues that ICANN was talking about concerning how
the change can have unintended consequences (besides spam blockers).  This
also looks to be a problem in general with how Microsoft delegates
lookups.  Their software shouldn't take the root of your Active Directory
tree and then append sub-domains to it and turn to the root servers for
resolution.  That appears to be a security risk if you ask me, and it
doesn't make sense to do.

Matt



John Tolmachoff (Lists) wrote:



Ah yes, using an unregistered domain name with a real TLD is a no-no. Whenare people using AD going to get this? AD must be configured correctly or else problems will come up when you leastexpect it. John Tolmachoff MCSE CSSAEngineer/ConsultanteServices For Youwww.eservicesforyou.com -Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]] On Behalf Of Matthew BrambleSent: Monday, September 22, 2003 12:52 AMTo: [EMAIL PROTECTED]Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from yourdomain. I figured it out.  The problem is definitely with Active Directory.  Turningoff DNS Client on the local server only created a situation where theirfirst bogus sub-domain would timeout but a retry would still go toSiteFinder.  Here's what nslookup returns when directed at the DNS server onthe co-located machine (not running Active Directory):  

adsfadsfasfdadsf.declude.com    

Server:  ns1.igaia.comAddress:  208.7.179.11 Non-authoritative answer:Name:    adsfadsfasfdadsf.declude.com.primary.igaiaoffice.comAddress:  64.94.110.11That's the bogus sub-domain appended to my local Active Directory domain(replaced for security with an equivalent).   The issue relates to the factthat my real Active Directory domain name is not registered and lies in the.com namespace, so when the lookup fails on the primary server, it goes backto the local Active Directory server and appends the lookup that produces nomatch to my unregistered Active Directory name, which returns the IP forSiteFinder.  If I registered my Active Directory name, I wouldn't bedirected to SiteFinder. Make sense now? Matt  

 

Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[Matthew Bramble]

ISPhuset Nordic / Benny Samuelsen wrote:

  
  
  
  Thats why you are supposed to use fex .loc

That makes some sense, however there has been plenty of talk about
allowing an infinite number of TLD's on the Internet.  Also, many
companies actually use a sub-directory of their primary domain for
their Active Directory.  I believe that your AD server would be sending
lookups out to the root servers even if you used .loc as your TLD, the
only difference is that .loc won't return SiteFinder, but something on
.com and .net will now, but before it worked the same as .loc as long
as your name wasn't registered.

 if
fex someone register this domain u use and then someone on the inside
want to send an email to to them it will never get trough 
Only if your E-mail server is behind your Active Directory server.  I
can't see why you would want to do that.  My Web/mail server doesn't
use Active Directory and is located off-site.


  Jesus this is so basic in AD i thought most
people know about those failures

When I set up my AD server, I spent dozens of hours trying to figure
the thing out by reading just about every document on Microsoft's Web
site that I could find.  No where did I ever see such a thing
mentioned.  As things stand, I wasted enough time setting up AD for
what is currently a 2 computer network and I'm sure that many others
feel the same way.  I'm quite happy with my internal name also, and
have no interest in changing it.  If I want to register it, it's only
$10 a year.

What I'm pointing to with this is actually support for why something
needs to be returned by the root servers saying record doesn't exist
instead of just matching whatever they get with their site, even
processing the E-mail that is received which would otherwise be
unaddressable.

Matt



  
  From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Matthew
Bramble
  Sent: 22. september 2003 19:40
  To: [EMAIL PROTECTED]
  
  
  Who says that I have to register the
domain that Active Directory is using?  My Active Directory name isn't
intended to be used on the Internet.  In most installations, you look
to your own Active Directory server first for the lookups, so if it
exists on the Internet it won't interfeer...until now.
  
I think this is one of the issues that ICANN was talking about
concerning how the change can have unintended consequences (besides
spam blockers).  This also looks to be a problem in general with how
Microsoft delegates lookups.  Their software shouldn't take the root of
your Active Directory tree and then append sub-domains to it and turn
to the root servers for resolution.  That appears to be a security risk
if you ask me, and it doesn't make sense to do.
  
Matt
  
  
  
John Tolmachoff (Lists) wrote:
  
  
Ah yes, using an unregistered domain name with a real TLD is a no-no. When
are people using AD going to get this?
 
AD must be configured correctly or else problems will come up when you least
expect it.
 
John Tolmachoff MCSE CSSA
Engineer/Consultant
eServices For You
www.eservicesforyou.com
 
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Bramble
Sent: Monday, September 22, 2003 12:52 AM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your
domain.
 
I figured it out.  The problem is definitely with Active Directory.  Turning
off DNS Client on the local server only created a situation where their
first bogus sub-domain would timeout but a retry would still go to
SiteFinder.  Here's what nslookup returns when directed at the DNS server on
the co-located machine (not running Active Directory):
  

  adsfadsfasfdadsf.declude.com


Server:  ns1.igaia.com
Address:  208.7.179.11

Non-authoritative answer:
Name:    adsfadsfasfdadsf.declude.com.primary.igaiaoffice.com
Address:  64.94.110.11
That's the bogus sub-domain appended to my local Active Directory domain
(replaced for security with an equivalent).   The issue relates to the fact
that my real Active Directory domain name is not registered and lies in the
.com namespace, so when the lookup fails on the primary server, it goes back
to the local Active Directory server and appends the lookup that produces no
match to my unregistered Active Directory name, which returns the IP for
SiteFinder.  If I registered my Active Directory name, I wouldn't be
directed to SiteFinder.

Make sense now?

Matt
  
  

RE: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[Keith Anderson]

Easy to get around by making the active directory domain a subordinate of
another valid Internet domain.  Then any requests that Active Directory
sends out are returned to your own external DNS server.

-Original Message-
From: Matthew Bramble [mailto:[EMAIL PROTECTED]
Sent: Monday, September 22, 2003 11:40 AM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your
domain.


Who says that I have to register the domain that Active Directory is using?
My Active Directory name isn't intended to be used on the Internet.  In most
installations, you look to your own Active Directory server first for the
lookups, so if it exists on the Internet it won't interfeer...until now.

I think this is one of the issues that ICANN was talking about concerning
how the change can have unintended consequences (besides spam blockers).
This also looks to be a problem in general with how Microsoft delegates
lookups.  Their software shouldn't take the root of your Active Directory
tree and then append sub-domains to it and turn to the root servers for
resolution.  That appears to be a security risk if you ask me, and it
doesn't make sense to do.

Matt


---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

RE: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[ISPhuset Nordic / Benny Samuelsen]

Thats 
why you are supposed to use fex .loc
 
This 
is a deathsin in my opinion
 
if fex 
someone register this domain u use and then someone on the inside want to send 
an email to to them it will never get trough 
 
Jesus 
this is so basic in AD i thought most people know about those 
failures



From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Matthew 
BrambleSent: 22. september 2003 19:40To: 
[EMAIL PROTECTED]

Who says that I have to register the domain that Active 
Directory is using?  My Active Directory name isn't intended to be used on 
the Internet.  In most installations, you look to your own Active Directory 
server first for the lookups, so if it exists on the Internet it won't 
interfeer...until now.I think this is one of the issues that ICANN was 
talking about concerning how the change can have unintended consequences 
(besides spam blockers).  This also looks to be a problem in general with 
how Microsoft delegates lookups.  Their software shouldn't take the root of 
your Active Directory tree and then append sub-domains to it and turn to the 
root servers for resolution.  That appears to be a security risk if you ask 
me, and it doesn't make sense to do.MattJohn Tolmachoff 
(Lists) wrote:
Ah yes, using an unregistered domain name with a real TLD is a no-no. When
are people using AD going to get this?
 
AD must be configured correctly or else problems will come up when you least
expect it.
 
John Tolmachoff MCSE CSSA
Engineer/Consultant
eServices For You
www.eservicesforyou.com
 
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Bramble
Sent: Monday, September 22, 2003 12:52 AM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your
domain.
 
I figured it out.  The problem is definitely with Active Directory.  Turning
off DNS Client on the local server only created a situation where their
first bogus sub-domain would timeout but a retry would still go to
SiteFinder.  Here's what nslookup returns when directed at the DNS server on
the co-located machine (not running Active Directory):
  
  adsfadsfasfdadsf.declude.com
Server:  ns1.igaia.com
Address:  208.7.179.11

Non-authoritative answer:
Name:    adsfadsfasfdadsf.declude.com.primary.igaiaoffice.com
Address:  64.94.110.11
That's the bogus sub-domain appended to my local Active Directory domain
(replaced for security with an equivalent).   The issue relates to the fact
that my real Active Directory domain name is not registered and lies in the
.com namespace, so when the lookup fails on the primary server, it goes back
to the local Active Directory server and appends the lookup that produces no
match to my unregistered Active Directory name, which returns the IP for
SiteFinder.  If I registered my Active Directory name, I wouldn't be
directed to SiteFinder.

Make sense now?

Matt
  

Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[Matthew Bramble]

Who says that I have to register the domain that Active Directory is
using?  My Active Directory name isn't intended to be used on the
Internet.  In most installations, you look to your own Active Directory
server first for the lookups, so if it exists on the Internet it won't
interfeer...until now.

I think this is one of the issues that ICANN was talking about
concerning how the change can have unintended consequences (besides
spam blockers).  This also looks to be a problem in general with how
Microsoft delegates lookups.  Their software shouldn't take the root of
your Active Directory tree and then append sub-domains to it and turn
to the root servers for resolution.  That appears to be a security risk
if you ask me, and it doesn't make sense to do.

Matt



John Tolmachoff (Lists) wrote:

  Ah yes, using an unregistered domain name with a real TLD is a no-no. When
are people using AD going to get this?
 
AD must be configured correctly or else problems will come up when you least
expect it.
 
John Tolmachoff MCSE CSSA
Engineer/Consultant
eServices For You
www.eservicesforyou.com
 
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Bramble
Sent: Monday, September 22, 2003 12:52 AM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your
domain.
 
I figured it out.  The problem is definitely with Active Directory.  Turning
off DNS Client on the local server only created a situation where their
first bogus sub-domain would timeout but a retry would still go to
SiteFinder.  Here's what nslookup returns when directed at the DNS server on
the co-located machine (not running Active Directory):
  
  
adsfadsfasfdadsf.declude.com

  
  Server:  ns1.igaia.com
Address:  208.7.179.11

Non-authoritative answer:
Name:    adsfadsfasfdadsf.declude.com.primary.igaiaoffice.com
Address:  64.94.110.11
That's the bogus sub-domain appended to my local Active Directory domain
(replaced for security with an equivalent).   The issue relates to the fact
that my real Active Directory domain name is not registered and lies in the
.com namespace, so when the lookup fails on the primary server, it goes back
to the local Active Directory server and appends the lookup that produces no
match to my unregistered Active Directory name, which returns the IP for
SiteFinder.  If I registered my Active Directory name, I wouldn't be
directed to SiteFinder.

Make sense now?

Matt
  

Re: [Declude.JunkMail] Is it possible

[Sanford Whiteman]

> Declude  does  a great job of creating sub-folders on the fly for on
> the  box  Imail  users, however, this is more on the fly creation of
> Imail main boxes,

> ...which  to  me is dangerous since spammers could send email to any
> ole' user...

Well, they can already send mail to any old user, since you don't have
access  to  their  userbase  and  are  forwarding stuff on to them and
bouncing  stuff  from  their  server back out to the 'Net (and killing
their double-bounces).

Even if you could assume that all mailboxes are valid and create IMail
maildrops  for  them,  how are you supposed to generate the forwarding
addresses? How does this differ substantively from them just accepting
mail  for  more  than one host alias? For example, if someone sends to
[EMAIL PROTECTED],andyou   forward   it   to
[EMAIL PROTECTED]@mx.example.com, how was that easier than having their
server just accept the mail to the original address? It's not like the
sender  is  in any way notified of the forward. Please explain further
if you wish.

-Sandy



Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
e-mail: [EMAIL PROTECTED]


---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

Re: [Declude.JunkMail] Bogus email from local domain

[Bill Landry]

Ah, now I understand.  That could be a nice feature, since you are correct,
IMail should know whether the account exists or not.  A simple check of the
"From" address (if it shows a local domain) would be all that it would take,
and then a simple reject if the account does not exist as a user or alias.

Bill
- Original Message - 
From: "Kami Razvan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 22, 2003 7:58 AM
Subject: RE: [Declude.JunkMail] Bogus email from local domain


:)

We do not have nobody.

Let me explain again since there is a misunderstanding here.

If I send you an email and make my outlook Reply address:  [EMAIL PROTECTED]
domain.com you will get the email.  Right?

I can change my email to: [EMAIL PROTECTED]

Naturally that email does not exist.

All I say is Imail should know its own database and this query should be
much faster than doing the IP4R tests.  So before it does anything - if it
receives an email from a domain that is local to it - IMail has to make sure
that email exists.  Otherwise reject the email.

- in Imail list I was suggesting Imail to reject it..

In Declude we can simply have a test that can say this FROM address is
invalid as a local domain.  So someone can not have:

[EMAIL PROTECTED] in their from address and send me
email.

Regards,
Kami

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bill Landry
Sent: Monday, September 22, 2003 9:55 AM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] Bogus email from local domain


Kami, if you remove the "nobody" alias from your hosted domains, then IMail
will simply refuse to accept delivery for non-existent users with a "550 no
such user" and neither IMail nor Declude will have to do any processing for
these messages.

Bill
- Original Message - 
From: "Kami Razvan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 22, 2003 5:30 AM
Subject: [Declude.JunkMail] Bogus email from local domain


Hi;

I just posted a message in the IMail list regarding this..

Can a test be defined so emails from local domains that do not exist are
identified.

E.g.: [EMAIL PROTECTED]

This user does not exist.  If Declude could have a test - InvalidLocalUser -
then we can simply add a large enough weight or hopefully later on when such
feature is available stop processing the email from this user and simply
delete it.

When you receive about 20 of these emails to different people one can
imagine all the useless cpu required to process what could have simply been
deleted.

Regards,
Kami

---
[This E-mail was scanned for viruses by Declude Virus
(http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To unsubscribe,
just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe
Declude.JunkMail".  The archives can be found at
http://www.mail-archive.com.

---
[This E-mail was scanned for viruses by Declude Virus
(http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To unsubscribe,
just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe
Declude.JunkMail".  The archives can be found at
http://www.mail-archive.com.

---
[This E-mail was scanned for viruses by Declude Virus
(http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

[Declude.JunkMail] Is it possible

[Keith Johnson]

I have a strange request, however, I don't think it can be done.  I have
a store-and-forward domain (Exchange User) that would like for us to
forward individual spam email to another location for each individual
user.  The catch is, they don't want to send us their individual user
email addresses so that I can create a per-user junkmail file for them,
this would cause double management.  They have informed me that their
last Spam provider ISP could do this with a store-and-forward domain.
Declude does a great job of creating sub-folders on the fly for on the
box Imail users, however, this is more on the fly creation of Imail main
boxes, which to me is dangerous since spammers could send email to any
ole' user.  Any suggestions, thanks for the time.

Keith
---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

RE: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[John Tolmachoff \(Lists\)]

Ah yes, using an unregistered domain name with a real TLD is a no-no. When
are people using AD going to get this?
 
AD must be configured correctly or else problems will come up when you least
expect it.
 
John Tolmachoff MCSE CSSA
Engineer/Consultant
eServices For You
www.eservicesforyou.com
 
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble
Sent: Monday, September 22, 2003 12:52 AM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your
domain.
 
I figured it out.  The problem is definitely with Active Directory.  Turning
off DNS Client on the local server only created a situation where their
first bogus sub-domain would timeout but a retry would still go to
SiteFinder.  Here's what nslookup returns when directed at the DNS server on
the co-located machine (not running Active Directory):
> adsfadsfasfdadsf.declude.com
Server:  ns1.igaia.com
Address:  208.7.179.11

Non-authoritative answer:
Name:    adsfadsfasfdadsf.declude.com.primary.igaiaoffice.com
Address:  64.94.110.11
That's the bogus sub-domain appended to my local Active Directory domain
(replaced for security with an equivalent).   The issue relates to the fact
that my real Active Directory domain name is not registered and lies in the
.com namespace, so when the lookup fails on the primary server, it goes back
to the local Active Directory server and appends the lookup that produces no
match to my unregistered Active Directory name, which returns the IP for
SiteFinder.  If I registered my Active Directory name, I wouldn't be
directed to SiteFinder.

Make sense now?

Matt



---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

RE: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[John Tolmachoff \(Lists\)]

Has nothing to do with AD. It has to do with you do not have fowarders
configured, instead relying on root servers, which of course are run by
you-know-who.

John Tolmachoff MCSE CSSA
Engineer/Consultant
eServices For You
www.eservicesforyou.com


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:Declude.JunkMail-
> [EMAIL PROTECTED] On Behalf Of Matthew Bramble
> Sent: Sunday, September 21, 2003 11:05 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your
domain.
> 
> Very strange.  I just confirmed that it happens from both Netscape and
> IE on both local computers, but it doesn't happen on my mail/web
> server.  I think this has to do with the fact that I am on a local
> network with Active Directory, which my mail/web server isn't using.
> 
> Anyone else behind an Active Directory server that can confirm?
> 
> Matt
> 
> 
> 
> Andy Schmidt wrote:
> 
> >Can't reproduce here.
> >
> >I get regular "Not found" in my browser.
> >
> >Best Regards
> >Andy Schmidt
> >
> >Phone:  +1 201 934-3414 x20 (Business)
> >Fax:+1 201 934-9206
> >
> >
> >
> >-Original Message-
> >From: [EMAIL PROTECTED]
> >[mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble
> >Sent: Monday, September 22, 2003 01:34 AM
> >To: [EMAIL PROTECTED]
> >Subject: [Declude.JunkMail] VeriSteal is stealing traffic from your
domain.
> >
> >
> >I didn't realize this until a second ago, but VeriCorrupt is stealing
> >traffic from every domain name out there on the Internet, regardless of
> >the extension, and regardless of whether or not it is registered.  Want
> >to see something else that's quite strange?
> >
> >http://asfdasdsadfdsf.online.museum
> >http://asdfaasdfasdf.site.biz
> >
> >For some reason that brings you to VeriThief's SiteFinder??  If you
> >take out the ".online" it will take you to the wildcarded MuseDoma
> >site.  Seems that VeriSteal has some bleed over.  Want to see something
> >even worse?
> >
> >http://asdasdfasdfa.igaia.com
> >http://asdfasdfasdf.declude.com
> >
> >Any lookup, registered or unregistered that doesn't return an A record
> >is being directed at this site.  Why the hell are these guys stealing
> >traffic from the domain names that I am paying for?  THIS MUST END!  Up
> >until now, I only thought this was limited to unregistered domains.
> >VeriHijack can't be allowed to write the rules whatever way they see
> >fit.  They quite literally just took over the backbone of the Internet.
> >
> >Matt
> >
> >
> >
> 
> 
> ---
> [This E-mail was scanned for viruses by Declude Virus
(http://www.declude.com)]
> 
> ---
> This E-mail came from the Declude.JunkMail mailing list.  To
> unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
> type "unsubscribe Declude.JunkMail".  The archives can be found
> at http://www.mail-archive.com.

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

RE: [Declude.JunkMail] Bogus email from local domain

[Kami Razvan]

:)

We do not have nobody. 

Let me explain again since there is a misunderstanding here.

If I send you an email and make my outlook Reply address:  [EMAIL PROTECTED]
domain.com you will get the email.  Right?

I can change my email to: [EMAIL PROTECTED]

Naturally that email does not exist.

All I say is Imail should know its own database and this query should be
much faster than doing the IP4R tests.  So before it does anything - if it
receives an email from a domain that is local to it - IMail has to make sure
that email exists.  Otherwise reject the email.

- in Imail list I was suggesting Imail to reject it..

In Declude we can simply have a test that can say this FROM address is
invalid as a local domain.  So someone can not have:

[EMAIL PROTECTED] in their from address and send me
email.

Regards,
Kami

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bill Landry
Sent: Monday, September 22, 2003 9:55 AM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] Bogus email from local domain


Kami, if you remove the "nobody" alias from your hosted domains, then IMail
will simply refuse to accept delivery for non-existent users with a "550 no
such user" and neither IMail nor Declude will have to do any processing for
these messages.

Bill
- Original Message - 
From: "Kami Razvan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 22, 2003 5:30 AM
Subject: [Declude.JunkMail] Bogus email from local domain


Hi;

I just posted a message in the IMail list regarding this..

Can a test be defined so emails from local domains that do not exist are
identified.

E.g.: [EMAIL PROTECTED]

This user does not exist.  If Declude could have a test - InvalidLocalUser -
then we can simply add a large enough weight or hopefully later on when such
feature is available stop processing the email from this user and simply
delete it.

When you receive about 20 of these emails to different people one can
imagine all the useless cpu required to process what could have simply been
deleted.

Regards,
Kami

---
[This E-mail was scanned for viruses by Declude Virus
(http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To unsubscribe,
just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe
Declude.JunkMail".  The archives can be found at
http://www.mail-archive.com.

---
[This E-mail was scanned for viruses by Declude Virus
(http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To unsubscribe,
just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe
Declude.JunkMail".  The archives can be found at
http://www.mail-archive.com.

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

Re: [Declude.JunkMail] Strange log and header behavior

[Bill Landry]

- Original Message - 
From: "R. Scott Perry" <[EMAIL PROTECTED]>

> >So I decided to whitelist the message using:
> >
> > WHITELIST FROM root
> >
> >in the Global.cfg file.
>
> FYI, I would not recommend that -- it will whitelist all E-mails that have
> "root" in their return address (such as "[EMAIL PROTECTED]").

I just did this for testing to see if it would prevent the other tests from
showing up in my logs.  That's why I noticed that it actually prevented any
entries from being logged.

> >X-Declude-Sender: root [204.189.38.3]
> >X-Queue-File: D523f367500567d1d.SMD - outgoing
> >X-Note: Total spam test weight: 0
>
> These headers do correspond with:
>
> >---
> >Log file entry:
> >M:\IMail\Declude\Unix-Tools>grep "Q523f367500567d1d"
> >m:\imail\spool\spam\log\dec0921.log
> >NO LOG ENTRY FOUND
> >=
>
> this.  If Declude JunkMail is not run for some reason, you will still see
> those partial headers.  In this case, it uses different code to get the IP
> address, which only checks the first line.  This normally will happen if
> Declude Virus quarantines an E-mail.
>
> Do you have any C:\Declude.gp1 or C:\Declude.gp2 files with a date similar
> to the time that E-mail was processed (or more recent)?

There are no gp* files in the root of c:\.

> >Note that Declude was now able to determine the IP address of the sending
> >server (strange).  But when the whitelist is enabled, there is an even
> >stranger side effect in that nothing for the message shows up in the
> >JunkMail log file.  Remove the whitelist entry, and Declude again cannot
> >determine the sending servers IP address, but the message once again
shows
> >up in the logs.
>
> It just occurred to me that this may be happening if you use the
> "PREWHITELIST ON" option, which essentially disables Declude JunkMail if a
> whitelist occurs.  This could have the side-effects that you are
> mentioning.  It will not use the expected (by me) IP, because different
> code is used to determine the IP when the Declude JunkMail code is not
run,
> and certain headers may not be added.
>
> I'll need to investigate this further to see what changes need to be made
> when the PREWHITELIST ON setting is used.

Yes, I do use PREWHITELIST ON.

> As for the IPs, the Declude JunkMail code is behaving correctly without
the
> PREWHITELIST ON setting.  Specifically, you have an IPBYPASS (or HOP) line
> that is telling it to skip over the first hop, but the second hop (the one
> where the IP should be) is missing the IP address.  If it had "127.0.0.1"
> in there, then Declude JunkMail would see that as the IP address.  But
> since there is no IP, Declude JunkMail treats this the same as if there
was
> no IP listed at all.

HOP is set to 0, but I am using IPBYPASS for the gateway server addresses.
I will try a couple of other things, as well.

Bill

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[Bill Landry]

- Original Message - 
From: Matthew Bramble

> I figured it out.  The problem is definitely with Active Directory.
Turning
> off DNS Client on the local server only created a situation where their
> first bogus sub-domain would timeout but a retry would still go to
SiteFinder.

Hmmm, well I was talking about shutting of the DNS Client on the
workstations, since that is where queries will bypass DNS by using locally
cached info, even if it is incorrect, until the cached entries expire.

> Here's what nslookup returns when directed at the DNS server on the
> co-located machine (not running Active Directory):
>
> adsfadsfasfdadsf.declude.com
> Server:  ns1.igaia.com
> Address:  208.7.179.11
>
> Non-authoritative answer:
> Name:adsfadsfasfdadsf.declude.com.primary.igaiaoffice.com
> Address:  64.94.110.11

Make sense now?

Yep.

Bill

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

Re: [Declude.JunkMail] Bogus email from local domain

[Bill Landry]

Kami, if you remove the "nobody" alias from your hosted domains, then IMail
will simply refuse to accept delivery for non-existent users with a "550 no
such user" and neither IMail nor Declude will have to do any processing for
these messages.

Bill
- Original Message - 
From: "Kami Razvan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 22, 2003 5:30 AM
Subject: [Declude.JunkMail] Bogus email from local domain


Hi;

I just posted a message in the IMail list regarding this..

Can a test be defined so emails from local domains that do not exist are
identified.

E.g.: [EMAIL PROTECTED]

This user does not exist.  If Declude could have a test - InvalidLocalUser -
then we can simply add a large enough weight or hopefully later on when such
feature is available stop processing the email from this user and simply
delete it.

When you receive about 20 of these emails to different people one can
imagine all the useless cpu required to process what could have simply been
deleted.

Regards,
Kami

---
[This E-mail was scanned for viruses by Declude Virus
(http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

RE: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[Keith Anderson]

I'm behind Active Directory here and it doesn't happen the same way as you
describe.  Other than mistyped .COM and .NET domains, it gives me an error.
That's really odd.

> I think this has something to do with Active Directory.  I
> have no clue as to where the lookup is coming from because it
> isn't cached.  It is most certainly happening though:
>
> http://www.mailpure.com/VeriStrange.jpg



---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

[Declude.JunkMail] Bogus email from local domain

[Kami Razvan]

Hi;

I just posted a message in the IMail list regarding this..

Can a test be defined so emails from local domains that do not exist are
identified.

E.g.: [EMAIL PROTECTED]

This user does not exist.  If Declude could have a test - InvalidLocalUser -
then we can simply add a large enough weight or hopefully later on when such
feature is available stop processing the email from this user and simply
delete it.

When you receive about 20 of these emails to different people one can
imagine all the useless cpu required to process what could have simply been
deleted.

Regards,
Kami

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[Bud Durland]

Matthew Bramble wrote:

   http://asfdasdsadfdsf.online.museum
   http://asdfaasdfasdf.site.biz
   http://asdasdfasdfa.igaia.com
   http://asdfasdfasdf.declude.com
All of the above yiled the standard "page could not be displayed" 
message for me.  I'm using NetWare 5.1's NAMED.NLM.  I've been told that 
it is based on BIND, but not the most current version.

--
---
illigitimi non carborundum
---
Bud Durland, CNE Mold-Rite Plastics
Network Administrator http://www.mrpcap.com
---
---
[This E-mail scanned for viruses by Declude Virus / Sophos AV]
---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

Re: [Declude.JunkMail] Strange log and header behavior

[R. Scott Perry]

So I decided to whitelist the message using:

WHITELIST FROM root

in the Global.cfg file.
FYI, I would not recommend that -- it will whitelist all E-mails that have 
"root" in their return address (such as "[EMAIL PROTECTED]").

X-Declude-Sender: root [204.189.38.3]
X-Queue-File: D523f367500567d1d.SMD - outgoing
X-Note: Total spam test weight: 0
These headers do correspond with:

---
Log file entry:
M:\IMail\Declude\Unix-Tools>grep "Q523f367500567d1d"
m:\imail\spool\spam\log\dec0921.log
NO LOG ENTRY FOUND
=
this.  If Declude JunkMail is not run for some reason, you will still see 
those partial headers.  In this case, it uses different code to get the IP 
address, which only checks the first line.  This normally will happen if 
Declude Virus quarantines an E-mail.

Do you have any C:\Declude.gp1 or C:\Declude.gp2 files with a date similar 
to the time that E-mail was processed (or more recent)?

Note that Declude was now able to determine the IP address of the sending
server (strange).  But when the whitelist is enabled, there is an even
stranger side effect in that nothing for the message shows up in the
JunkMail log file.  Remove the whitelist entry, and Declude again cannot
determine the sending servers IP address, but the message once again shows
up in the logs.
It just occurred to me that this may be happening if you use the 
"PREWHITELIST ON" option, which essentially disables Declude JunkMail if a 
whitelist occurs.  This could have the side-effects that you are 
mentioning.  It will not use the expected (by me) IP, because different 
code is used to determine the IP when the Declude JunkMail code is not run, 
and certain headers may not be added.

I'll need to investigate this further to see what changes need to be made 
when the PREWHITELIST ON setting is used.

As for the IPs, the Declude JunkMail code is behaving correctly without the 
PREWHITELIST ON setting.  Specifically, you have an IPBYPASS (or HOP) line 
that is telling it to skip over the first hop, but the second hop (the one 
where the IP should be) is missing the IP address.  If it had "127.0.0.1" 
in there, then Declude JunkMail would see that as the IP address.  But 
since there is no IP, Declude JunkMail treats this the same as if there was 
no IP listed at all.

   -Scott
---
Declude JunkMail: The advanced anti-spam solution for IMail mailservers.
Declude Virus: Catches known viruses and is the leader in mailserver 
vulnerability detection.
Find out what you've been missing: Ask about our free 30-day evaluation.

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

RE: [Declude.JunkMail] Number of times JM scans an email?

[R. Scott Perry]

I just have to jump in here, because I raised the issue of the multiple
recipients a short while ago, and my understanding was that if one
receipient sets an action on a message, that action will also be performed
on the message to all other receipients.
Correct.

Are you saying that individual actions will take place for individual
messages if they have individual JunkMail files, but if they do not have a
JunkMail file, then the action is determined by the one recipient who does
have actions set?
I'm saying that Declude JunkMail checks all the recipients to see what 
action(s) they have set for the various tests.  In the case of conflicting 
actions (such as IGNORE for one user and WARN for another), Declude 
JunkMail does its best to determine how to handle the conflicting actions.
-Scott

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

RE: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[ISPhuset Nordic AS]

Title: Message



Yes u 
did the mistake of using a .com domain which are not registered... slap your 
fingers and repeat after me NEVER do this gain :-)

  
  -Original Message-From: 
  [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
  On Behalf Of Matthew BrambleSent: 22. september 2003 
  09:53To: [EMAIL PROTECTED]Subject: Re: 
  [Declude.JunkMail] VeriSteal is stealing traffic from your 
  domain.I figured it out.  The problem is definitely 
  with Active Directory.  Turning off DNS Client on the local server only 
  created a situation where their first bogus sub-domain would timeout but a 
  retry would still go to SiteFinder.  Here's what nslookup returns when 
  directed at the DNS server on the co-located machine (not running Active 
  Directory):
  > adsfadsfasfdadsf.declude.comServer:  
ns1.igaia.comAddress:  208.7.179.11Non-authoritative 
answer:Name:    
adsfadsfasfdadsf.declude.com.primary.igaiaoffice.comAddress:  
64.94.110.11That's the bogus sub-domain appended to my local 
  Active Directory domain (replaced for security with an 
  equivalent).   The issue relates to the fact that my real Active 
  Directory domain name is not registered and lies in the .com namespace, so 
  when the lookup fails on the primary server, it goes back to the local Active 
  Directory server and appends the lookup that produces no match to my 
  unregistered Active Directory name, which returns the IP for SiteFinder.  
  If I registered my Active Directory name, I wouldn't be directed to 
  SiteFinder.Make sense now?MattBill Landry 
  wrote:
  

Are you running W2K or XP?  If so, make 
sure you have the "DNS Client" service disabled.  We setup all machines 
with it off by default now, because it has caused nothing but problems for 
us in the past by caching bogus info.
 
Good luck!
 
Bill

  - 
  Original Message - 
  From: 
  Matthew Bramble 
  
  To: 
  [EMAIL PROTECTED] 
  
  Sent: 
  Sunday, September 21, 2003 11:56 PM
  Subject: 
  Re: [Declude.JunkMail] VeriSteal is stealing traffic from your 
  domain.
  I think this has something to do with Active 
  Directory.  I have no clue as to where the lookup is coming from 
  because it isn't cached.  It is most certainly happening 
  though:http://www.mailpure.com/VeriStrange.jpgI 
  did a quick search and couldn't find any mention of this on 
  Google.MattBill Landry wrote:
  



But VeriSign does not even have the 
authority nor control over any other TLDs except .com and .net, so it 
doesn't make sense that you are having the name resolution issues you 
are experiencing.
 
Bill

  - 
  Original Message - 
  From: 
  Matthew 
  Bramble 
  To: 
  [EMAIL PROTECTED] 
  
  Sent: 
  Sunday, September 21, 2003 11:34 PM
  Subject: 
  Re: [Declude.JunkMail] VeriSteal is stealing traffic from your 
  domain.
  My primary is my mail/Web server that is co-located 
  off-site running MS DNS without Active Directory.  My secondary 
  is my LAN's Microsoft Active Directory bound DNS server.  The 
  unregistered .com and .net misspellings are in my mail/Web server's 
  cache, however these invalid sub-domains don't show up in the cache of 
  either server.It's strange behavior.  I wonder where my 
  computer is getting this information.  Maybe this is proof of why 
  you shouldn't wildcard from the root 
  servers?MattISPhuset Nordic AS wrote:
  what dns are u using ?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Bramble
Sent: 22. september 2003 08:05
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.


Very strange.  I just confirmed that it happens from both Netscape and 
IE on both local computers, but it doesn't happen on my mail/web 
server.  I think this has to do with the fact that I am on a local 
network with Active Directory, which my mail/web server isn't using.

Anyone else behind an Active Directory server that can confirm?

Matt



Andy Schmidt wrote:

  
Can't reproduce here.

I get regular "Not found" in my browser.

Best Regards
Andy Schmidt

Phone:  +1 201 934-3414 x20 (Business)
Fax:+1 201 934-9206 



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble
Sent: Monday, September 22, 2003 01:34 AM
To: [EMAIL PROTECTED]
Subject: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.


I didn't realize this until a second ago, but VeriCorrupt is stealing 
traffic from every domain name out there on the Internet, regardless of 
the extension, and regardless of whether or 

Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[Matthew Bramble]

I figured it out.  The problem is definitely with Active Directory. 
Turning off DNS Client on the local server only created a situation
where their first bogus sub-domain would timeout but a retry would
still go to SiteFinder.  Here's what nslookup returns when directed at
the DNS server on the co-located machine (not running Active Directory):
> adsfadsfasfdadsf.declude.com
Server:  ns1.igaia.com
Address:  208.7.179.11
  
Non-authoritative answer:
Name:    adsfadsfasfdadsf.declude.com.primary.igaiaoffice.com
Address:  64.94.110.11

That's the bogus sub-domain appended to my local Active Directory
domain (replaced for security with an equivalent).   The issue relates
to the fact that my real Active Directory domain name is not registered
and lies in the .com namespace, so when the lookup fails on the primary
server, it goes back to the local Active Directory server and appends
the lookup that produces no match to my unregistered Active Directory
name, which returns the IP for SiteFinder.  If I registered my Active
Directory name, I wouldn't be directed to SiteFinder.

Make sense now?

Matt



Bill Landry wrote:

  
  
  
  Are you running W2K or XP?  If so,
make sure you have the "DNS Client" service disabled.  We setup all
machines with it off by default now, because it has caused nothing but
problems for us in the past by caching bogus info.
   
  Good luck!
   
  Bill
  
-
Original Message - 
From:
Matthew
Bramble 
To:
[EMAIL PROTECTED]

Sent:
Sunday, September 21, 2003 11:56 PM
Subject:
Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.


I think this has something to do with Active Directory.  I have no clue
as to where the lookup is coming from because it isn't cached.  It is
most certainly happening though:

http://www.mailpure.com/VeriStrange.jpg

I did a quick search and couldn't find any mention of this on Google.

Matt



Bill Landry wrote:

  
  
  But VeriSign does not even have
the authority nor control over any other TLDs except .com and .net, so
it doesn't make sense that you are having the name resolution issues
you are experiencing.
   
  Bill
  
-
Original Message - 
From:
Matthew
Bramble 
To:
[EMAIL PROTECTED]

Sent:
Sunday, September 21, 2003 11:34 PM
Subject:
Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.


My primary is my mail/Web server that is co-located off-site running MS
DNS without Active Directory.  My secondary is my LAN's Microsoft
Active Directory bound DNS server.  The unregistered .com and .net
misspellings are in my mail/Web server's cache, however these invalid
sub-domains don't show up in the cache of either server.

It's strange behavior.  I wonder where my computer is getting this
information.  Maybe this is proof of why you shouldn't wildcard from
the root servers?

Matt



ISPhuset Nordic AS wrote:

  what dns are u using ?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Bramble
Sent: 22. september 2003 08:05
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.


Very strange.  I just confirmed that it happens from both Netscape and 
IE on both local computers, but it doesn't happen on my mail/web 
server.  I think this has to do with the fact that I am on a local 
network with Active Directory, which my mail/web server isn't using.

Anyone else behind an Active Directory server that can confirm?

Matt



Andy Schmidt wrote:

  
  
Can't reproduce here.

I get regular "Not found" in my browser.

Best Regards
Andy Schmidt

Phone:  +1 201 934-3414 x20 (Business)
Fax:+1 201 934-9206 



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble
Sent: Monday, September 22, 2003 01:34 AM
To: [EMAIL PROTECTED]
Subject: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.


I didn't realize this until a second ago, but VeriCorrupt is stealing 
traffic from every domain name out there on the Internet, regardless of 
the extension, and regardless of whether or not it is registered.  Want 
to see something else that's quite strange?

   http://asfdasdsadfdsf.online.museum
   http://asdfaasdfasdf.site.biz

For some reason that brings you to VeriThief's SiteFinder??  If you 
take out the ".online" it will take you to the wildcarded MuseDoma 
site.  Seems that VeriSteal has some bleed over.  Want to see something 
even worse?

   http://asdasdfasdfa.igaia.com
   http://asdfasdfasdf.declude.com

Any lookup, registered or unregistered that doesn't return an A record 
is being directed at this site.  Why the hell are these guys stealing 
traffic from the domain names that I am paying for?  THIS MUST EN

RE: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[ISPhuset Nordic AS]

Title: Message



Which 
ip adresses are there on the servers u hve set up as dns on that maschine 
?

  
  -Original Message-From: 
  [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
  On Behalf Of Matthew BrambleSent: 22. september 2003 
  08:57To: [EMAIL PROTECTED]Subject: Re: 
  [Declude.JunkMail] VeriSteal is stealing traffic from your 
  domain.I think this has something to do with Active 
  Directory.  I have no clue as to where the lookup is coming from because 
  it isn't cached.  It is most certainly happening though:http://www.mailpure.com/VeriStrange.jpgI 
  did a quick search and couldn't find any mention of this on 
  Google.MattBill Landry wrote:
  



But VeriSign does not even have the authority 
nor control over any other TLDs except .com and .net, so it doesn't make 
sense that you are having the name resolution issues you are 
experiencing.
 
Bill

  - 
  Original Message - 
  From: 
  Matthew Bramble 
  
  To: 
  [EMAIL PROTECTED] 
  
  Sent: 
  Sunday, September 21, 2003 11:34 PM
  Subject: 
  Re: [Declude.JunkMail] VeriSteal is stealing traffic from your 
  domain.
  My primary is my mail/Web server that is co-located 
  off-site running MS DNS without Active Directory.  My secondary is my 
  LAN's Microsoft Active Directory bound DNS server.  The unregistered 
  .com and .net misspellings are in my mail/Web server's cache, however 
  these invalid sub-domains don't show up in the cache of either 
  server.It's strange behavior.  I wonder where my computer is 
  getting this information.  Maybe this is proof of why you shouldn't 
  wildcard from the root servers?MattISPhuset Nordic 
  AS wrote:
  what dns are u using ?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Bramble
Sent: 22. september 2003 08:05
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.


Very strange.  I just confirmed that it happens from both Netscape and 
IE on both local computers, but it doesn't happen on my mail/web 
server.  I think this has to do with the fact that I am on a local 
network with Active Directory, which my mail/web server isn't using.

Anyone else behind an Active Directory server that can confirm?

Matt



Andy Schmidt wrote:

  
Can't reproduce here.

I get regular "Not found" in my browser.

Best Regards
Andy Schmidt

Phone:  +1 201 934-3414 x20 (Business)
Fax:+1 201 934-9206 



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble
Sent: Monday, September 22, 2003 01:34 AM
To: [EMAIL PROTECTED]
Subject: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.


I didn't realize this until a second ago, but VeriCorrupt is stealing 
traffic from every domain name out there on the Internet, regardless of 
the extension, and regardless of whether or not it is registered.  Want 
to see something else that's quite strange?

   http://asfdasdsadfdsf.online.museum
   http://asdfaasdfasdf.site.biz

For some reason that brings you to VeriThief's SiteFinder??  If you 
take out the ".online" it will take you to the wildcarded MuseDoma 
site.  Seems that VeriSteal has some bleed over.  Want to see something 
even worse?

   http://asdasdfasdfa.igaia.com
   http://asdfasdfasdf.declude.com

Any lookup, registered or unregistered that doesn't return an A record 
is being directed at this site.  Why the hell are these guys stealing 
traffic from the domain names that I am paying for?  THIS MUST END!  Up 
until now, I only thought this was limited to unregistered domains.  
VeriHijack can't be allowed to write the rules whatever way they see 
fit.  They quite literally just took over the backbone of the Internet.

Matt

Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[Bill Landry]

Are you running W2K or XP?  If so, make sure 
you have the "DNS Client" service disabled.  We setup all machines with it 
off by default now, because it has caused nothing but problems for us in the 
past by caching bogus info.
 
Good luck!
 
Bill

  - Original Message - 
  From: 
  Matthew Bramble 

  To: [EMAIL PROTECTED] 
  
  Sent: Sunday, September 21, 2003 11:56 
  PM
  Subject: Re: [Declude.JunkMail] VeriSteal 
  is stealing traffic from your domain.
  I think this has something to do with Active Directory.  I 
  have no clue as to where the lookup is coming from because it isn't 
  cached.  It is most certainly happening though:http://www.mailpure.com/VeriStrange.jpgI 
  did a quick search and couldn't find any mention of this on 
  Google.MattBill Landry wrote:
  



But VeriSign does not even have the authority 
nor control over any other TLDs except .com and .net, so it doesn't make 
sense that you are having the name resolution issues you are 
experiencing.
 
Bill

  - 
  Original Message - 
  From: 
  Matthew Bramble 
  
  To: 
  [EMAIL PROTECTED] 
  
  Sent: 
  Sunday, September 21, 2003 11:34 PM
  Subject: 
  Re: [Declude.JunkMail] VeriSteal is stealing traffic from your 
  domain.
  My primary is my mail/Web server that is co-located 
  off-site running MS DNS without Active Directory.  My secondary is my 
  LAN's Microsoft Active Directory bound DNS server.  The unregistered 
  .com and .net misspellings are in my mail/Web server's cache, however 
  these invalid sub-domains don't show up in the cache of either 
  server.It's strange behavior.  I wonder where my computer is 
  getting this information.  Maybe this is proof of why you shouldn't 
  wildcard from the root servers?MattISPhuset Nordic 
  AS wrote:
  what dns are u using ?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Bramble
Sent: 22. september 2003 08:05
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.


Very strange.  I just confirmed that it happens from both Netscape and 
IE on both local computers, but it doesn't happen on my mail/web 
server.  I think this has to do with the fact that I am on a local 
network with Active Directory, which my mail/web server isn't using.

Anyone else behind an Active Directory server that can confirm?

Matt



Andy Schmidt wrote:

  
Can't reproduce here.

I get regular "Not found" in my browser.

Best Regards
Andy Schmidt

Phone:  +1 201 934-3414 x20 (Business)
Fax:+1 201 934-9206 



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble
Sent: Monday, September 22, 2003 01:34 AM
To: [EMAIL PROTECTED]
Subject: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.


I didn't realize this until a second ago, but VeriCorrupt is stealing 
traffic from every domain name out there on the Internet, regardless of 
the extension, and regardless of whether or not it is registered.  Want 
to see something else that's quite strange?

   http://asfdasdsadfdsf.online.museum
   http://asdfaasdfasdf.site.biz

For some reason that brings you to VeriThief's SiteFinder??  If you 
take out the ".online" it will take you to the wildcarded MuseDoma 
site.  Seems that VeriSteal has some bleed over.  Want to see something 
even worse?

   http://asdasdfasdfa.igaia.com
   http://asdfasdfasdf.declude.com

Any lookup, registered or unregistered that doesn't return an A record 
is being directed at this site.  Why the hell are these guys stealing 
traffic from the domain names that I am paying for?  THIS MUST END!  Up 
until now, I only thought this was limited to unregistered domains.  
VeriHijack can't be allowed to write the rules whatever way they see 
fit.  They quite literally just took over the backbone of the Internet.

Matt

Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.

[Matthew Bramble]

I think this has something to do with Active Directory.  I have no clue
as to where the lookup is coming from because it isn't cached.  It is
most certainly happening though:

http://www.mailpure.com/VeriStrange.jpg

I did a quick search and couldn't find any mention of this on Google.

Matt



Bill Landry wrote:

  
  
  
  
  But VeriSign does not even have the
authority nor control over any other TLDs except .com and .net, so it
doesn't make sense that you are having the name resolution issues you
are experiencing.
   
  Bill
  
-
Original Message - 
From:
Matthew
Bramble 
To:
[EMAIL PROTECTED]

Sent:
Sunday, September 21, 2003 11:34 PM
Subject:
Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.


My primary is my mail/Web server that is co-located off-site running MS
DNS without Active Directory.  My secondary is my LAN's Microsoft
Active Directory bound DNS server.  The unregistered .com and .net
misspellings are in my mail/Web server's cache, however these invalid
sub-domains don't show up in the cache of either server.

It's strange behavior.  I wonder where my computer is getting this
information.  Maybe this is proof of why you shouldn't wildcard from
the root servers?

Matt



ISPhuset Nordic AS wrote:

  what dns are u using ?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Bramble
Sent: 22. september 2003 08:05
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.


Very strange.  I just confirmed that it happens from both Netscape and 
IE on both local computers, but it doesn't happen on my mail/web 
server.  I think this has to do with the fact that I am on a local 
network with Active Directory, which my mail/web server isn't using.

Anyone else behind an Active Directory server that can confirm?

Matt



Andy Schmidt wrote:

  
  
Can't reproduce here.

I get regular "Not found" in my browser.

Best Regards
Andy Schmidt

Phone:  +1 201 934-3414 x20 (Business)
Fax:+1 201 934-9206 



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble
Sent: Monday, September 22, 2003 01:34 AM
To: [EMAIL PROTECTED]
Subject: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.


I didn't realize this until a second ago, but VeriCorrupt is stealing 
traffic from every domain name out there on the Internet, regardless of 
the extension, and regardless of whether or not it is registered.  Want 
to see something else that's quite strange?

   http://asfdasdsadfdsf.online.museum
   http://asdfaasdfasdf.site.biz

For some reason that brings you to VeriThief's SiteFinder??  If you 
take out the ".online" it will take you to the wildcarded MuseDoma 
site.  Seems that VeriSteal has some bleed over.  Want to see something 
even worse?

   http://asdasdfasdfa.igaia.com
   http://asdfasdfasdf.declude.com

Any lookup, registered or unregistered that doesn't return an A record 
is being directed at this site.  Why the hell are these guys stealing 
traffic from the domain names that I am paying for?  THIS MUST END!  Up 
until now, I only thought this was limited to unregistered domains.  
VeriHijack can't be allowed to write the rules whatever way they see 
fit.  They quite literally just took over the backbone of the Internet.

Matt
  
  

  

Re: [Declude.JunkMail] blocking spam faked as coming from local address

[Bill Landry]

Ah yes, a mail admin's job is never 
done...  ;-)
 
Bill

  - Original Message - 
  From: 
  Matthew Bramble 

  To: [EMAIL PROTECTED] 
  
  Sent: Sunday, September 21, 2003 11:50 
  PM
  Subject: Re: [Declude.JunkMail] blocking 
  spam faked as coming from local address
  It would solve that issue, however I'm a big promoter of never 
  using a domain that you don't own when you can avoid it because it creates a 
  liability, though not on simple replies.  I've worked with many to help 
  them remove any trace of an old ISP account and this might tell their 
  receivers that the un-owned account is still active.  I'd rather 
  whitelist them instead, it would be less work.I'm not worried about 
  adding a couple extra points to that stuff though since their ISP's mail 
  server should be fairly clean, and I have decided that rejecting valid E-mail 
  from a server marked as an open relay isn't in fact a false positive, though 
  this only rarely happens.  It's the non-customers sending valid stuff 
  that is forged and the hardware devices that send out notifications which tend 
  to have difficulties in passing some of the technical tests (HELOBOGUS, 
  BADHEADERS and SPAMHEADERS among others).  I already have some issues 
  with this stuff FP'ing and bounces aren't useful in the second 
  instance.MattBill Landry wrote:
  - Original Message - 
From: Matthew Bramble

  
Thanks for the link to the GNU stuff.  I might be asking for some help
writing useful strings of pipes in the future :)

No problem, I have several scripts I run to generate differnt kinds of
reports.

[snip]
  
I think you might have overlooked this in your response because
WHITELIST AUTH won't forgive these senders, [...]

Good point.  I would suggest that in these circumstances where a customer is
using their ISP's MTA for outbound mail delivery, that you have them set
their e-mail address in their e-mail client to their ISP account and then
set their "Reply To" address as their e-mail address on your IMail server.
I think this would resolve the inadvertant flagging of these customer
e-mails with referrence to the spamdomains tests.

Bill
  

Re: [Declude.JunkMail] blocking spam faked as coming from local address

[Matthew Bramble]

It would solve that issue, however I'm a big promoter of never using a
domain that you don't own when you can avoid it because it creates a
liability, though not on simple replies.  I've worked with many to help
them remove any trace of an old ISP account and this might tell their
receivers that the un-owned account is still active.  I'd rather
whitelist them instead, it would be less work.

I'm not worried about adding a couple extra points to that stuff though
since their ISP's mail server should be fairly clean, and I have
decided that rejecting valid E-mail from a server marked as an open
relay isn't in fact a false positive, though this only rarely happens. 
It's the non-customers sending valid stuff that is forged and the
hardware devices that send out notifications which tend to have
difficulties in passing some of the technical tests (HELOBOGUS,
BADHEADERS and SPAMHEADERS among others).  I already have some issues
with this stuff FP'ing and bounces aren't useful in the second instance.

Matt



Bill Landry wrote:

  - Original Message - 
From: Matthew Bramble

  
  
Thanks for the link to the GNU stuff.  I might be asking for some help
writing useful strings of pipes in the future :)

  
  
No problem, I have several scripts I run to generate differnt kinds of
reports.

[snip]
  
  
I think you might have overlooked this in your response because
WHITELIST AUTH won't forgive these senders, [...]

  
  
Good point.  I would suggest that in these circumstances where a customer is
using their ISP's MTA for outbound mail delivery, that you have them set
their e-mail address in their e-mail client to their ISP account and then
set their "Reply To" address as their e-mail address on your IMail server.
I think this would resolve the inadvertant flagging of these customer
e-mails with referrence to the spamdomains tests.

Bill