date:20040209

LDAP routing cannot be used for (and isn't designed for) that purpose.

If you're looking to integrate MS SMTP with your userbase, the best bet is ORF from 
Vamsoft, which offers AD-integrated envelope rejection.

--Sandy

--
 
Sanford Whiteman, Chief Technologist 
Broadleaf Systems, a division of 
Cypress Integrated Systems, Inc. 
mailto:[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] [Declude.Junkmail] MS SMTP LDAP Routing

Sandy,

I recall checking this out once before when it was mentioned, probably
by you. Somehow I figured that you would probably be the one that would
know :)

I do see the piece about ActiveDirectory integration. I'm not an AD
expert by any means, and I'm wondering if it's plausible to create a
database of sorts within AD that isn't the equivalent of your accounts.
This would be a great place to store such information if possible. I
could then create an application that essentially dumped the IMail users
to a file, and users from a separate database for gatewayed domains, and
then imported it into AD for use with something like this.

Also, now that it's clear that MS SMTP can be used for envelope
rejection, I'm wondering how easy it would be to write an application
that pulled this information from any number of sources (IMail's LDAP
for instance). I've got a programmer buddy that I'm sure could handle
this if I gave him the right pointers. It's not that ORF is expensive,
it's quite cheap, but I'm really only looking for envelope rejection of
bad accounts and also potentially for dictionary attacks through some
mechanism designed to detect them. Any idea about what is used to tap
into the MS SMTP service to make these extensions?

Right now I have no legitimate need for this due to my traffic, however
my business is growing and I would like to stay ahead of the game and
make plans for the future. Envelope rejection for gatewayed domains
would be a big bandwidth and processor saver, and it doesn't look like
IMail is headed in the direction of providing such a tool beyond their
own accounts.

Thanks,

Matt

Sanford Whiteman wrote:

LDAP routing cannot be used for (and isn't designed for) that purpose.

If you're looking to integrate MS SMTP with your userbase, the best bet is ORF from Vamsoft, which offers AD-integrated envelope rejection.

--Sandy

Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
mailto:[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.

--
=
MailPure custom filters for Declude JunkMail Pro.
http://www.mailpure.com/software/
=
---
[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] [Declude.Junkmail] MS SMTP LDAP Routing

2004-02-09 Thread John Tolmachoff \(Lists\)

The AD schema can be extended to include custom fields and such. One such
item that comes to mind is contacts, which are not users but rather
addressable objects in AD. Since AD is a database, you would not create a
database within a database, but rather extend the schema of the database. 

However, warning. Extending and/or changing the schema is permanent and must
be thoroughly tested to ensure there are no repercussions.

For gateway domains not in AD, you might want to consider, if possible, a
separate LDAP querry to a simple Access database.

John Tolmachoff
Engineer/Consultant/Owner
eServices For You


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:Declude.JunkMail-
 [EMAIL PROTECTED] On Behalf Of Matt
 Sent: Monday, February 09, 2004 11:06 AM
 To: [EMAIL PROTECTED]
 Subject: Re: [Declude.JunkMail] [Declude.Junkmail] MS SMTP LDAP Routing
 
 Sandy,
 
 I recall checking this out once before when it was mentioned, probably
 by you.  Somehow I figured that you would probably be the one that would
 know :)
 
 I do see the piece about ActiveDirectory integration.  I'm not an AD
 expert by any means, and I'm wondering if it's plausible to create a
 database of sorts within AD that isn't the equivalent of your accounts.
 This would be a great place to store such information if possible.  I
 could then create an application that essentially dumped the IMail users
 to a file, and users from a separate database for gatewayed domains, and
 then imported it into AD for use with something like this.
 
 Also, now that it's clear that MS SMTP can be used for envelope
 rejection, I'm wondering how easy it would be to write an application
 that pulled this information from any number of sources (IMail's LDAP
 for instance).  I've got a programmer buddy that I'm sure could handle
 this if I gave him the right pointers.  It's not that ORF is expensive,
 it's quite cheap, but I'm really only looking for envelope rejection of
 bad accounts and also potentially for dictionary attacks through some
 mechanism designed to detect them.  Any idea about what is used to tap
 into the MS SMTP service to make these extensions?
 
 Right now I have no legitimate need for this due to my traffic, however
 my business is growing and I would like to stay ahead of the game and
 make plans for the future.  Envelope rejection for gatewayed domains
 would be a big bandwidth and processor saver, and it doesn't look like
 IMail is headed in the direction of providing such a tool beyond their
 own accounts.
 
 Thanks,
 
 Matt
 
 
 
 Sanford Whiteman wrote:
 
 LDAP routing cannot be used for (and isn't designed for) that purpose.
 
 If you're looking to integrate MS SMTP with your userbase, the best bet
 is ORF from Vamsoft, which offers AD-integrated envelope rejection.
 
 --Sandy
 
 --
 
 Sanford Whiteman, Chief Technologist
 Broadleaf Systems, a division of
 Cypress Integrated Systems, Inc.
 mailto:[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.
 
 
 
 
 
 --
 =
 MailPure custom filters for Declude JunkMail Pro.
 http://www.mailpure.com/software/
 =
 
 
 ---
 [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] [Declude.Junkmail] MS SMTP LDAP Routing

Matt,

IIS SMTP supports event sinks at various stages of the protocol. VAMsoft
uses them to check the IP address upon connection, or to check the email
addresses in MAIL FROM / RCPT TO the moment they occur.

So - yes, it appears entirely feasible to write an event sink that will
compare the RCPT TO against ANY user base (AD, LDAP, SQL Queries, plain-text
files,...)  See:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsmtps/htm
l/writingmngsinks.asp?frame=true#writingmngsinks_topic2

I have offloaded all my outbound SMTP (and authorized SMTP relaying) to one
of my IIS SMTP machines - and it also acts as my backup MX.  ORF has been a
godsend to ward off unwanted emails by spammers who try to send to the
Backup MX (so they don't have to be processed by Declude/Imail).

I would seriously consider funding some of the development for an IMAIL/LDAP
lookup event sink as it would help my SMTP server to disconnect on
dictionary attacks.

Best Regards
Andy Schmidt

HM 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/


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matt
Sent: Monday, February 09, 2004 02:06 PM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] [Declude.Junkmail] MS SMTP LDAP Routing


Sandy,

I recall checking this out once before when it was mentioned, probably 
by you.  Somehow I figured that you would probably be the one that would 
know :)

I do see the piece about ActiveDirectory integration.  I'm not an AD 
expert by any means, and I'm wondering if it's plausible to create a 
database of sorts within AD that isn't the equivalent of your accounts.  
This would be a great place to store such information if possible.  I 
could then create an application that essentially dumped the IMail users 
to a file, and users from a separate database for gatewayed domains, and 
then imported it into AD for use with something like this.

Also, now that it's clear that MS SMTP can be used for envelope 
rejection, I'm wondering how easy it would be to write an application 
that pulled this information from any number of sources (IMail's LDAP 
for instance).  I've got a programmer buddy that I'm sure could handle 
this if I gave him the right pointers.  It's not that ORF is expensive, 
it's quite cheap, but I'm really only looking for envelope rejection of 
bad accounts and also potentially for dictionary attacks through some 
mechanism designed to detect them.  Any idea about what is used to tap 
into the MS SMTP service to make these extensions?

Right now I have no legitimate need for this due to my traffic, however 
my business is growing and I would like to stay ahead of the game and 
make plans for the future.  Envelope rejection for gatewayed domains 
would be a big bandwidth and processor saver, and it doesn't look like 
IMail is headed in the direction of providing such a tool beyond their 
own accounts.

Thanks,

Matt



Sanford Whiteman wrote:

LDAP routing cannot be used for (and isn't designed for) that purpose.

If you're looking to integrate MS SMTP with your userbase, the best bet 
is ORF from Vamsoft, which offers AD-integrated envelope rejection.

--Sandy

--

Sanford Whiteman, Chief Technologist 
Broadleaf Systems, a division of 
Cypress Integrated Systems, Inc. 
mailto:[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.


  


-- 
=
MailPure custom filters for Declude JunkMail Pro.
http://www.mailpure.com/software/
=


---
[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] [Declude.Junkmail] MS SMTP LDAP Routing





John,

Thanks for the info. It appears that if this tool is to be used in a
high volume environment, then the process of validating will need to be
very efficient. I'm guessing that AD is pretty quick to query, similar
to both LDAP and DNS. Access on the other hand is something that is
currently causing me some issues in my hosting environment where
someone has an ecommerce store that has outgrown their Access solution
despite it only being a moderately trafficked site and the database
only being 15 MB. Just a simple page load on that site will hit almost
100% of dual PIII 1 GHz processors. That will have to change :)

I've been digging into this and it's apparent that there is some sort
of MS SMTP SDK or resources provided so that a different application
could be designed, possibly one that took a list from something as
simple as a text file and loaded it into memory for use like this. It
might not even be all that hard to accomplish. I've also found that
you can in fact control the outgoing port on MS SMTP in the MetaBase,
which means that you could have this sit on the same server as an IMail
Gateway running on something besides port 25. Looks like there might
be a lot of possibilities here in using this as a pre-filter.

Naturally though, things would be a whole lot easier if IMail could
just simply be configured so that it doesn't take over every IP on the
server. Maybe we should all start a letter writing campaign to
Ipswitch asking that they do this. It would seem to be a simple enough
change.

Matt



John Tolmachoff (Lists) wrote:

  The AD schema can be extended to include custom fields and such. One such
item that comes to mind is contacts, which are not users but rather
addressable objects in AD. Since AD is a database, you would not create a
database within a database, but rather extend the schema of the database. 

However, warning. Extending and/or changing the schema is permanent and must
be thoroughly tested to ensure there are no repercussions.

For gateway domains not in AD, you might want to consider, if possible, a
separate LDAP querry to a simple Access database.

John Tolmachoff
Engineer/Consultant/Owner
eServices For You


  
  
-Original Message-
From: [EMAIL PROTECTED] [mailto:Declude.JunkMail-
[EMAIL PROTECTED]] On Behalf Of Matt
Sent: Monday, February 09, 2004 11:06 AM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] [Declude.Junkmail] MS SMTP LDAP Routing

Sandy,

I recall checking this out once before when it was mentioned, probably
by you.  Somehow I figured that you would probably be the one that would
know :)

I do see the piece about ActiveDirectory integration.  I'm not an AD
expert by any means, and I'm wondering if it's plausible to create a
database of sorts within AD that isn't the equivalent of your accounts.
This would be a great place to store such information if possible.  I
could then create an application that essentially dumped the IMail users
to a file, and users from a separate database for gatewayed domains, and
then imported it into AD for use with something like this.

Also, now that it's clear that MS SMTP can be used for envelope
rejection, I'm wondering how easy it would be to write an application
that pulled this information from any number of sources (IMail's LDAP
for instance).  I've got a programmer buddy that I'm sure could handle
this if I gave him the right pointers.  It's not that ORF is expensive,
it's quite cheap, but I'm really only looking for envelope rejection of
bad accounts and also potentially for dictionary attacks through some
mechanism designed to detect them.  Any idea about what is used to tap
into the MS SMTP service to make these extensions?

Right now I have no legitimate need for this due to my traffic, however
my business is growing and I would like to stay ahead of the game and
make plans for the future.  Envelope rejection for gatewayed domains
would be a big bandwidth and processor saver, and it doesn't look like
IMail is headed in the direction of providing such a tool beyond their
own accounts.

Thanks,

Matt



Sanford Whiteman wrote:



  LDAP routing cannot be used for (and isn't designed for) that purpose.

If you're looking to integrate MS SMTP with your userbase, the best bet
  

is ORF from Vamsoft, which offers AD-integrated envelope rejection.


  --Sandy

--

Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
mailto:[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] [Declude.Junkmail] MS SMTP LDAP Routing





Andy,

This is good stuff. I think it's what is needed.

My programming buddy is on perma-contract for the AP and
manages/programs many of their Internet related projects. It's
impossible to stump him with a task like this. He provides me with a
lot of friendly assistance, though for a project like this, he would
probably want to see this become a product. That's not to suggest that
anyone else should be discouraged from doing something like this
themselves.

My guess is that he could have something working for address validation
very quickly, however it would take longer to create a dictionary
attack stopper. The bigger question is how large the potential market
is for such a thing. It could be very large if IMail would allow
specified IP's to be used on port 25 by other applications, but it
would seem limited to just backup MX servers if done under the current
environment. Note that if this became a product, it would cost less as
a product than funding the development.

So two immediate questions come to mind.

1) How many people would like to run MS SMTP as a backup MX with sender
verification and dictionary attack detection?
2) Who would be interested in a user movement to compel Ipswitch to
prevent IMail from bonding to every last IP? This way it could also be
used on the primary server and not get in the way of hosted E-mail.

Matt





Andy Schmidt wrote:

  Matt,

IIS SMTP supports "event sinks" at various stages of the protocol. VAMsoft
uses them to check the IP address upon connection, or to check the email
addresses in MAIL FROM / RCPT TO the moment they occur.

So - yes, it appears entirely feasible to write an event sink that will
compare the RCPT TO against ANY user base (AD, LDAP, SQL Queries, plain-text
files,...)  See:
http://msdn.microsoft.com/library/default.asp?url="">
l/writingmngsinks.asp?frame=true#writingmngsinks_topic2

I have offloaded all my outbound SMTP (and authorized SMTP relaying) to one
of my IIS SMTP machines - and it also acts as my backup MX.  ORF has been a
godsend to ward off unwanted emails by spammers who try to send to the
Backup MX (so they don't have to be processed by Declude/Imail).

I would seriously consider funding some of the development for an IMAIL/LDAP
lookup event sink as it would help my SMTP server to "disconnect" on
dictionary attacks.

Best Regards
Andy Schmidt

HM 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/


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Matt
Sent: Monday, February 09, 2004 02:06 PM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] [Declude.Junkmail] MS SMTP LDAP Routing


Sandy,

I recall checking this out once before when it was mentioned, probably 
by you.  Somehow I figured that you would probably be the one that would 
know :)

I do see the piece about ActiveDirectory integration.  I'm not an AD 
expert by any means, and I'm wondering if it's plausible to create a 
database of sorts within AD that isn't the equivalent of your accounts.  
This would be a great place to store such information if possible.  I 
could then create an application that essentially dumped the IMail users 
to a file, and users from a separate database for gatewayed domains, and 
then imported it into AD for use with something like this.

Also, now that it's clear that MS SMTP can be used for envelope 
rejection, I'm wondering how easy it would be to write an application 
that pulled this information from any number of sources (IMail's LDAP 
for instance).  I've got a programmer buddy that I'm sure could handle 
this if I gave him the right pointers.  It's not that ORF is expensive, 
it's quite cheap, but I'm really only looking for envelope rejection of 
bad accounts and also potentially for dictionary attacks through some 
mechanism designed to detect them.  Any idea about what is used to tap 
into the MS SMTP service to make these extensions?

Right now I have no legitimate need for this due to my traffic, however 
my business is growing and I would like to stay ahead of the game and 
make plans for the future.  Envelope rejection for gatewayed domains 
would be a big bandwidth and processor saver, and it doesn't look like 
IMail is headed in the direction of providing such a tool beyond their 
own accounts.

Thanks,

Matt



Sanford Whiteman wrote:

  
  
LDAP routing cannot be used for (and isn't designed for) that purpose.

If you're looking to integrate MS SMTP with your userbase, the best bet 
is ORF from Vamsoft, which offers AD-integrated envelope rejection.

--Sandy

--

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

--
---
[This E-mail was scanned for viruses by Declude Virus

[Declude.JunkMail] OT: IMail LDAP for Virtual Mail Domains?

Title: Message



Matt:

One 
more angle to that.

Am I 
mistaken, or does the LDAP lookup only work for "IP based" mail domains? 
In other words, ifI host a few hundred mail domains sharing the SAME IP 
address, then it appears as if Imail's LDAP feature ONLY connects to the ONE 
mail domain that runs native on that specific IP address? All the IP-less 
domains cannot be queried? That would render any "external" LDAP verification by 
IIS useless.
Best 
RegardsAndy SchmidtHM 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[2]: [Declude.JunkMail] [Declude.Junkmail] MS SMTP LDAP Routing

 2)  Who would be interested in a user movement to compel Ipswitch to
 prevent  IMail from bonding to every last IP? This way it could also
 be  used  on  the  primary  server  and not get in the way of hosted
 E-mail.

No one's saying Ipswitch has ever worked on this, but I've had MS SMTP
and IIS working on the same box (and same port) for years now.

--Sandy



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

SpamAssassin plugs into Declude!
http://www.mailmage.com/download/software/freeutils/SPAMC32/Release/

---
[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[2]: [Declude.JunkMail] [Declude.Junkmail] MS SMTP LDAP Routing

 I  would  seriously  consider funding some of the development for an
 IMAIL/LDAP  lookup  event  sink  as  it would help my SMTP server to
 disconnect on dictionary attacks.

I  already  use  ORF  to reject at the envelope using LDAP lookups and
really have no need for any other intermediary. It's no-brainer if you
use  IMail's NT integration on an AD DC. All you need to do is add the
Exchange  schema  extensions  to the AD domain, since ORF is expecting
the  extended  schema--you  don't have to install or purchase Exchange
itself.  You  can run the ORF queries against any server in the domain
(which  doesn't  have  to be the same as your primary domain), meaning
that  you  can  scale  out from hitting the mailbox server directly to
hitting dedicated AD DCs that only service such MX lookups.

Building  anything  designed to interact with IMail's own ILDAP daemon
is a very bad move, as the service is barely functional, compliant, or
stable.  AD's  LDAP  services,  on  the  other  hand,  are  mature and
resilient.

The  other options that involve local text files would certainly work,
but  performance  under  load  could  not  exceed that of indexed LDAP
lookups.

--Sandy



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

SpamAssassin plugs into Declude!
http://www.mailmage.com/download/software/freeutils/SPAMC32/Release/

---
[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] [Declude.Junkmail] MS SMTP LDAP Routing

Title: Message



Hi 
Matt:

Imail 
already verifies its own user base - they have no reason to enable someone else 
to do it on the same server. If anything, we should lobby THEM directly to 
detect dictionary attacks (too many unknown users per time period during the 
same connection or from the same IP address). That would 
eliminate the need to run IIS SMTP on the same system?

My 
goal should/would be to provide for IIS SMTP to run 
stand-alone.

However, I wasn't thinking of the "dictionary attack" as a unique 
feature. 

The 
"poor man's" dictionary attack fend-off would simply be a side effect of the 
Imail user base checking. Sure, the spammer could still CONNECT to IIS 
SMTP, but would not be able to submit email with an invalid "TO" address, if IIS 
were to check the IMAIL user base. That itself would address the current problem 
where mail IS accepted by the Backup MX, then passed on to the IMail primary MX 
- where it is rejected. Now the Backup MX is tasked with sending hundreds 
of thousands of bounce messages. THAT is the (occasional) problem I'm 
trying to avoid.

I can 
live with the fact, that the connection is only dropped at the RCPT 
TO,instead of a little earlier at the HELO/EHLO. A "real" dictionary 
attack defense would have to update my router ACLs to actually reduce traffic to 
the mail servers.
Best 
RegardsAndy SchmidtHM 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/ 

  
  -Original Message-From: 
  [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
  On Behalf Of MattSent: Monday, February 09, 2004 03:09 
  PMTo: [EMAIL PROTECTED]Subject: Re: 
  [Declude.JunkMail] [Declude.Junkmail] MS SMTP LDAP 
  RoutingAndy,This is good stuff. I think 
  it's what is needed.My programming buddy is on perma-contract for the 
  AP and manages/programs many of their Internet related projects. It's 
  impossible to stump him with a task like this. He provides me with a lot 
  of friendly assistance, though for a project like this, he would probably want 
  to see this become a product. That's not to suggest that anyone else 
  should be discouraged from doing something like this themselves.My 
  guess is that he could have something working for address validation very 
  quickly, however it would take longer to create a dictionary attack 
  stopper. The bigger question is how large the potential market is for 
  such a thing. It could be very large if IMail would allow specified IP's 
  to be used on port 25 by other applications, but it would seem limited to just 
  backup MX servers if done under the current environment. Note that if 
  this became a product, it would cost less as a product than funding the 
  development.So two immediate questions come to mind.1) How 
  many people would like to run MS SMTP as a backup MX with sender verification 
  and dictionary attack detection?2) Who would be interested in a user 
  movement to compel Ipswitch to prevent IMail from bonding to every last 
  IP? This way it could also be used on the primary server and not get in 
  the way of hosted E-mail.MattAndy Schmidt 
  wrote:
  Matt,

IIS SMTP supports "event sinks" at various stages of the protocol. VAMsoft
uses them to check the IP address upon connection, or to check the email
addresses in MAIL FROM / RCPT TO the moment they occur.

So - yes, it appears entirely feasible to write an event sink that will
compare the RCPT TO against ANY user base (AD, LDAP, SQL Queries, plain-text
files,...)  See:
http://msdn.microsoft.com/library/default.asp?url="">
l/writingmngsinks.asp?frame=true#writingmngsinks_topic2

I have offloaded all my outbound SMTP (and authorized SMTP relaying) to one
of my IIS SMTP machines - and it also acts as my backup MX.  ORF has been a
godsend to ward off unwanted emails by spammers who try to send to the
Backup MX (so they don't have to be processed by Declude/Imail).

I would seriously consider funding some of the development for an IMAIL/LDAP
lookup event sink as it would help my SMTP server to "disconnect" on
dictionary attacks.

Best Regards
Andy Schmidt

HM 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/


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Matt
Sent: Monday, February 09, 2004 02:06 PM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] [Declude.Junkmail] MS SMTP LDAP Routing


Sandy,

I recall checking this out once before when it was mentioned, probably 
by you.  Somehow I figured that you would probably be the one that would 
know :)

I do see the piece about ActiveDirectory integration.  I'm not an AD 
expert by any means, and I'm wondering if it's plausible to create a 
database of sorts within AD that isn't the equivalent of your accounts.

Re: [Declude.JunkMail] [Declude.Junkmail] MS SMTP LDAP Routing





Sandy,

I'm aware of your work around for this and I might even attempt to use
it at some point. I'm not comfortable though with the idea of telling
others that this is the way to go with integrating a third-party
product seeing as how it is a kludge and potentially prone to other
issues. Ipswitch should learn to play nice instead.

Matt



Sanford Whiteman wrote:

  
2)  Who would be interested in a user movement to compel Ipswitch to
prevent  IMail from bonding to every last IP? This way it could also
be  used  on  the  primary  server  and not get in the way of hosted
E-mail.

  
  
No one's saying Ipswitch has ever worked on this, but I've had MS SMTP
and IIS working on the same box (and same port) for years now.

--Sandy



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

SpamAssassin plugs into Declude!
http://www.mailmage.com/download/software/freeutils/SPAMC32/Release/

---
[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.


  


-- 
=
MailPure custom filters for Declude JunkMail Pro.
http://www.mailpure.com/software/
=

Re: [Declude.JunkMail] [Declude.Junkmail] MS SMTP LDAP Routing





Andy,

What's at issue here is expanding beyond just locally hosted E-mail
accounts to gatewayed E-mail accounts. Since IMail doesn't offer any
way to validate gatewayed addresses or fending off dictionary attacks,
it might well be wise to place MS SMTP before IMail on the same box,
even if you only have locally hosted E-mail. This obviously isn't an
issue for the most part with backup MX's.

In relation to using IMail's LDAP, that might be too limiting and
provide unnecessary overhead. If you were to access the LDAP server on
the same machine it wouldn't be that big of a deal, but in a fail-over
situation where MX1 went down and MX2 is verifying off of the LDAP
server on MX1, you would lose the verification capabilities. The more
eloquent solution that takes into account all of the various needs
would be to dump an export into a text file and have the MS SMTP
plug-in read it into memory. You could then also allow those that want
to do address verification for gatewayed E-mail to place a text file in
a specific location and use that in addition to your IMail generated
lists.

I think this would be more efficient than using LDAP, and it would
allow for much greater flexibility.

Regarding dictionary attacks, router ACL's could certainly be used,
however it might be much easier to get it all to work within the same
application, i.e. MS SMTP. You can reject at the HELO based on IP, and
hardly any resources are used when that happens. The hardest part will
be defining what a dictionary attack is, for the same reason that
SpamCop has lots of trouble with bulk mail. It may be a better idea to
just go with address validation which shouldn't be that much more data
transmitted (rejected before the message is sent). Dictionary attack
detection is most helpful when the nobody alias is used. It certainly
seems that nobody aliases are a lost cause and maybe we should just
forget that they exist :(

Matt



Andy Schmidt wrote:

  
  Message
  
  Hi Matt:
  
  Imail already verifies its own user base -
they have no reason to enable someone else to do it on the same server.
If anything, we should lobby THEM directly to detect dictionary attacks
(too many unknown users per time period during the same connection or
from the same IP address). That
would eliminate the need to run IIS SMTP on the same system?
  
  My goal should/would be to provide for IIS
SMTP to run stand-alone.
  
  However, I
wasn't thinking of the "dictionary attack" as a unique feature. 
  
  The "poor man's" dictionary attack fend-off
would simply be a side effect of the Imail user base checking. Sure,
the spammer could still CONNECT to IIS SMTP, but would not be able to
submit email with an invalid "TO" address, if IIS were to check the
IMAIL user base. That itself would address the current problem where
mail IS accepted by the Backup MX, then passed on to the IMail primary
MX - where it is rejected. Now the Backup MX is tasked with sending
hundreds of thousands of bounce messages. THAT is the (occasional)
problem I'm trying to avoid.
  
  I can live with the fact, that the connection
is only dropped at the RCPT TO,instead of a little earlier at the
HELO/EHLO. A "real" dictionary attack defense would have to update my
router ACLs to actually reduce traffic to the mail servers.
  
  Best Regards
  Andy Schmidt
  
  HM 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/
  
  
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Matt
Sent: Monday, February 09, 2004 03:09 PM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] [Declude.Junkmail] MS SMTP
LDAP Routing


Andy,

This is good stuff. I think it's what is needed.

My programming buddy is on perma-contract for the AP and
manages/programs many of their Internet related projects. It's
impossible to stump him with a task like this. He provides me with a
lot of friendly assistance, though for a project like this, he would
probably want to see this become a product. That's not to suggest that
anyone else should be discouraged from doing something like this
themselves.

My guess is that he could have something working for address validation
very quickly, however it would take longer to create a dictionary
attack stopper. The bigger question is how large the potential market
is for such a thing. It could be very large if IMail would allow
specified IP's to be used on port 25 by other applications, but it
would seem limited to just backup MX servers if done under the current
environment. Note that if this became a product, it would cost less as
a product than funding the development.

So two immediate questions come to mind.

1) How many people would like to run MS SMTP as a backup MX with sender
verification and dictionary attack detection?
2) Who would be interested in a user

Re: [Declude.JunkMail] [Declude.Junkmail] MS SMTP LDAP Routing

Sanford Whiteman wrote:

The  other options that involve local text files would certainly work,
but  performance  under  load  could  not  exceed that of indexed LDAP
lookups.
 

From what I saw, ORF is loaded into memory the first time that it is 
called, and while AD lookups may be efficient, it would be more 
efficient and easier to implement a system where you had the plug-in 
read this information from a text file into memory.  The only trick 
would be determining how to refresh the data, which I'm sure is easy 
enough to do (like check the text files for last modified dates and only 
reload when changed).

Matt

--
=
MailPure custom filters for Declude JunkMail Pro.
http://www.mailpure.com/software/
=
---
[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[2]: [Declude.JunkMail] [Declude.Junkmail] MS SMTP LDAP Routing

 From what I saw, ORF is loaded into memory the first time that it is
 called,  and  while  AD  lookups  may be efficient, it would be more
 efficient and easier to implement a system where you had the plug-in
 read  this  information from a text file into memory.

No,  scanning  an  unindexed  text  file  with  tens  of  thousands of
addresses  is  NOT  faster than indexed LDAP lookups. Our LDAP servers
can handle millions of queries per hour.

If  you  index  the data, you're just reinventing the wheel. LDAP is a
standard  and powerful directory access protocol specifically designed
for this type of application.

--Sandy



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

SpamAssassin plugs into Declude!
http://www.mailmage.com/download/software/freeutils/SPAMC32/Release/

---
[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[2]: [Declude.JunkMail] [Declude.Junkmail] MS SMTP LDAP Routing

 I'm not comfortable though with the idea of telling others that this
 is  the  way  to go with integrating a third-party product seeing as
 how it is a kludge and potentially prone to other issues.

I  don't  think it's prone to any other issues, since the servers that
are using it have been doing so for a couple of years.

 Ipswitch should learn to play nice instead.

I  wouldn't  hold  your  breath.  As Andy said very well, if you think
concerted   pressure   can   be   applied,  that  pressure  should  be
concentrated  on the improvement of features within their own product!
Coexisting with the competition is not a feature.

--Sandy




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

SpamAssassin plugs into Declude!
http://www.mailmage.com/download/software/freeutils/SPAMC32/Release/

---
[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] OT: IMAIL - AD

Hi Sandy:

 It's no-brainer if you use  IMail's NT integration on an AD DC. 

I don't want to reinvent the wheel, so I'm trying to research this by
reading the Imail 8 manual. It doesn't reference AD directly (only the NT
User setup and that you have to run on a DC). So before I invest time and
play around with it, I have three no-brainer questions, which I could not
answer myself:

- It says that you can't use the Imail Explorer to manage accounts (users,
aliases, etc.) - does that imply that my clients wouldn't be able to use
WebMail to add/administer their own mailboxes either?

- Does the AD only store Users (mailboxes) - or also Alias (e.g., simple
alias, group alias, program alias, etc.)?  If not, then how do you
accomplish using the AD information to verify valid RCTP TO information?
A good portion of the email we process is addressed to an alias!?

- Does the Imail/NT/AD integration support (multiple) virtual domains
(ip-less) - or will it only create users for the AD domain name?
Accordingly, how will it know that two  mailboxes and/or aliases by the same
name, but on two different mail domains, should be kept as two different
entities in AD?

Best Regards
Andy Schmidt

HM 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/


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sanford Whiteman
Sent: Monday, February 09, 2004 03:47 PM
To: Andy Schmidt
Subject: Re[2]: [Declude.JunkMail] [Declude.Junkmail] MS SMTP LDAP Routing


 I  would  seriously  consider funding some of the development for an 
 IMAIL/LDAP  lookup  event  sink  as  it would help my SMTP server to 
 disconnect on dictionary attacks.

I  already  use  ORF  to reject at the envelope using LDAP lookups and
really have no need for any other intermediary. It's no-brainer if you use
IMail's NT integration on an AD DC. All you need to do is add the Exchange
schema  extensions  to the AD domain, since ORF is expecting the  extended
schema--you  don't have to install or purchase Exchange itself.  You  can
run the ORF queries against any server in the domain (which  doesn't  have
to be the same as your primary domain), meaning that  you  can  scale  out
from hitting the mailbox server directly to hitting dedicated AD DCs that
only service such MX lookups.

Building  anything  designed to interact with IMail's own ILDAP daemon is a
very bad move, as the service is barely functional, compliant, or stable.
AD's  LDAP  services,  on  the  other  hand,  are  mature and resilient.

The  other options that involve local text files would certainly work, but
performance  under  load  could  not  exceed that of indexed LDAP lookups.

--Sandy



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

SpamAssassin plugs into Declude!
http://www.mailmage.com/download/software/freeutils/SPAMC32/Release/

---
[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] [Declude.Junkmail] MS SMTP LDAP Routing

Sanford Whiteman wrote:

No,  scanning  an  unindexed  text  file  with  tens  of  thousands of
addresses  is  NOT  faster than indexed LDAP lookups. Our LDAP servers
can handle millions of queries per hour.
If  you  index  the data, you're just reinventing the wheel. LDAP is a
standard  and powerful directory access protocol specifically designed
for this type of application.
 

I think you misread me.  I meant that it could be loaded into memory 
along with the application.  The application could index it internally 
(if necessary).  The idea here is that it would only be read on the 
first use, or whenever there was a change in the source text file, but 
the application would not continually reference the text file.

Doesn't that make sense?

Matt

--
=
MailPure custom filters for Declude JunkMail Pro.
http://www.mailpure.com/software/
=
---
[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: IMAIL - AD





Andy,

I think what he meant was that you would import the data from IMail
into AD. IMail would still use it's own methods for storing and
accessing account information, but ORF would make use of the AD stuff
that you exported to it.

Personally, I don't use AD on my server because it doesn't seem to
offer me anything of value and adds complexity. The server is a
stand-alone box, and from a security standpoint, I believe it is best
for it to remain that way.

I'm asking my buddy to look into this. We certainly wouldn't come out
with something that did RBL scanning (DNSBL if Scott's listening :) ),
but I'm pretty sure we could get this to make use of a text file dump
fairly easily. ORF was written for an Exchange environment and it
might be easier to write something more appropriate for ours. If
Vamsoft came out with a different tool, then I would be all for giving
them money instead.

Matt



Andy Schmidt wrote:

  Hi Sandy:

  
  

  It's no-brainer if you use  IMail's NT integration on an AD DC. 
  

  
  
I don't want to reinvent the wheel, so I'm trying to research this by
reading the Imail 8 manual. It doesn't reference AD directly (only the NT
User setup and that you have to run on a DC). So before I invest time and
play around with it, I have three "no-brainer" questions, which I could not
answer myself:

- It says that you can't use the Imail "Explorer" to manage accounts (users,
aliases, etc.) - does that imply that my clients wouldn't be able to use
WebMail to add/administer their own mailboxes either?

- Does the AD only store "Users" (mailboxes) - or also "Alias" (e.g., simple
alias, group alias, program alias, etc.)?  If not, then how do you
accomplish using the AD information to verify "valid" RCTP TO information?
A good portion of the email we process is addressed to an alias!?

- Does the Imail/NT/AD integration support (multiple) virtual domains
(ip-less) - or will it only create users for the AD domain name?
Accordingly, how will it know that two  mailboxes and/or aliases by the same
name, but on two different mail domains, should be kept as two different
entities in AD?

Best Regards
Andy Schmidt

HM 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/


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Sanford Whiteman
Sent: Monday, February 09, 2004 03:47 PM
To: Andy Schmidt
Subject: Re[2]: [Declude.JunkMail] [Declude.Junkmail] MS SMTP LDAP Routing


  
  
I  would  seriously  consider funding some of the development for an 
IMAIL/LDAP  lookup  event  sink  as  it would help my SMTP server to 
"disconnect" on dictionary attacks.

  
  
I  already  use  ORF  to reject at the envelope using LDAP lookups and
really have no need for any other intermediary. It's no-brainer if you use
IMail's NT integration on an AD DC. All you need to do is add the Exchange
schema  extensions  to the AD domain, since ORF is expecting the  extended
schema--you  don't have to install or purchase Exchange itself.  You  can
run the ORF queries against any server in the domain (which  doesn't  have
to be the same as your primary domain), meaning that  you  can  scale  out
from hitting the mailbox server directly to hitting dedicated AD DCs that
only service such MX lookups.

Building  anything  designed to interact with IMail's own ILDAP daemon is a
very bad move, as the service is barely functional, compliant, or stable.
AD's  LDAP  services,  on  the  other  hand,  are  mature and resilient.

The  other options that involve local text files would certainly work, but
performance  under  load  could  not  exceed that of indexed LDAP lookups.

--Sandy



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

SpamAssassin plugs into Declude!
http://www.mailmage.com/download/software/freeutils/SPAMC32/Release/

---
[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.


  


-- 
=
MailPure custom filters for Declude JunkMail Pro.
http://www.mailpure.com/software/
=

RE: [Declude.JunkMail] Using Imail/Declude as Public Gateway

Title: Message

Matt:

gatewayed
E-mail accounts. Since IMail doesn't offer any way to validate gatewayed
addresses or fending off dictionary attacks
With "gateway" you mean
that you are hosting the "public" MX for them (primary and possibly backup MX),
but you are NOT hosting their mailboxes on your own Imail
machine?

Now I
understand your application (I assume). It means that ideally you'd want
Imail to validate against an external user base - even if the mail domain itself
is not hosted on Imail. Yes - I do have the same need.

It
would be nice if Imail had a little "checkmark" in the mail domain configuration
screen. If that checkmark for "remote domain"is set, then you could still
choose an external "user database" and the SMTPD daemon would actually perform
user validation.However, instead of doing an "LDELIVER" to a local
mailbox, it would then perform an "RDELIVER" to the remote mailbox
server.

In
reality, all the pieces already exist in their code. I think it's
worthwhile to make THAT an enhancement request. It would further broaden the
usability of Imail and reduce the need to look for alternative mail
servers.

With a
two scripts, you could probably already accomplish that:

a) on
the client'sremote mailbox server, export the user database for
"domain.com"in intervals
b) on
the clients' remote mailbox server, create an alias
"incoming.domain.com".
c) on
your Imail server, create a regular mail domain
"domain.com".
d) run a script that reads the client's exported user database and
creates an ALIAS in "domain.com" for every client USER, e.g. the user [EMAIL PROTECTED]becomes an ALIAS in your Imail
configuration. Point the alias to [EMAIL PROTECTED]and on your Imail server have a HOSTS entry for
"incoming.domain.com" pointing to the client's remote
server.

Now,
when someone sends mail, it WILL be validated by the Imail server. If an alias
does not exist, it can be rejected. If it does exist, the mail will be
processed by Declude and eventually it will be forwarded to the
"incoming.domain.com".

Best
RegardsAndy SchmidtHM 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/

-Original Message-From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of MattSent: Monday, February 09, 2004 04:42
PMTo: [EMAIL PROTECTED]Subject: Re:
[Declude.JunkMail] [Declude.Junkmail] MS SMTP LDAP
RoutingAndy,What's at issue here is expanding
beyond just locally hosted E-mail accounts to gatewayed E-mail accounts.
Since IMail doesn't offer any way to validate gatewayed addresses or fending
off dictionary attacks, it might well be wise to place MS SMTP before IMail on
the same box, even if you only have locally hosted E-mail. This
obviously isn't an issue for the most part with backup MX's.In
relation to using IMail's LDAP, that might be too limiting and provide
unnecessary overhead. If you were to access the LDAP server on the same
machine it wouldn't be that big of a deal, but in a fail-over situation where
MX1 went down and MX2 is verifying off of the LDAP server on MX1, you would
lose the verification capabilities. The more eloquent solution that
takes into account all of the various needs would be to dump an export into a
text file and have the MS SMTP plug-in read it into memory. You could
then also allow those that want to do address verification for gatewayed
E-mail to place a text file in a specific location and use that in addition to
your IMail generated lists.I think this would be more efficient than
using LDAP, and it would allow for much greater flexibility.Regarding
dictionary attacks, router ACL's could certainly be used, however it might be
much easier to get it all to work within the same application, i.e. MS
SMTP. You can reject at the HELO based on IP, and hardly any resources
are used when that happens. The hardest part will be defining what a
dictionary attack is, for the same reason that SpamCop has lots of trouble
with bulk mail. It may be a better idea to just go with address
validation which shouldn't be that much more data transmitted (rejected before
the message is sent). Dictionary attack detection is most helpful when
the nobody alias is used. It certainly seems that nobody aliases are a
lost cause and maybe we should just forget that they exist
:(Matt

Re[2]: [Declude.JunkMail] OT: IMAIL - AD

 I  think what he meant was that you would import the data from IMail
 into  AD.  IMail  would  still  use it's own methods for storing and
 accessing  account  information,  but  ORF  would make use of the AD
 stuff that you exported to it.

Nope,  it's total and automatic synchronization of the userbase, which
can then be replicated to as many LDAP slaves as necessary. That's the
power.

 Personally, I don't use AD on my server because it doesn't seem to offer 
 me anything of value and adds complexity.

LDAP is its thing of value. :)

 The  server  is a stand-alone box, and from a security standpoint, I
 believe it is best for it to remain that way.

You  can  still  run AD on a standalone DC, like I mentioned. Restrict
LDAP queries to the MXs, etc.

--Sandy



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

SpamAssassin plugs into Declude!
http://www.mailmage.com/download/software/freeutils/SPAMC32/Release/

---
[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[2]: [Declude.JunkMail] [Declude.Junkmail] MS SMTP LDAP Routing

 I  think you misread me. I meant that it could be loaded into memory
 along   with   the  application.  The  application  could  index  it
 internally  (if  necessary).  The idea here is that it would only be
 read  on the first use, or whenever there was a change in the source
 text  file,  but the application would not continually reference the
 text file.

 Doesn't that make sense?

It  does, but I just am opposed to data replication and CPU being used
for such functions when there are known standards for directory access
that are far more efficient. If indexed, sure, great, but that's still
hitting the source file on every message to check for changes, and CPU
stress every time there are changes.

It's  not  that  it  can't be done--it already is done all over--but I
have   a   predilection  for  existing,  replicable,  scaleable  query
languages like SQL, LDAP, even xBase (and their respective stable back
ends)  when  dealing  with appications which require up to hundreds of
thousands  of  values  to be stored. It's the sort of thing that seems
easy until you watch it grow--and crumble under load.

--Sandy




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

SpamAssassin plugs into Declude!
http://www.mailmage.com/download/software/freeutils/SPAMC32/Release/

---
[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: IMAIL - AD

 - It says that you can't use the Imail Explorer to manage accounts
 (users, aliases, etc.) - does that imply that my clients wouldn't be
 able to use WebMail to add/administer their own mailboxes either?

You can't add or delete AD users via the IMail interfaces, but you can
set  IMail  properties, such as Reply-To:, disabled, max mailbox size,
etc.

 - Does the AD only store Users (mailboxes) - or also Alias (e.g., simple
 alias, group alias, program alias, etc.)?  If not, then how do you
 accomplish using the AD information to verify valid RCTP TO information?
 A good portion of the email we process is addressed to an alias!?

You add the Alias information in AD as well (using the particular LDAP
attribute  designed  for this). Users without access to AD couldn't do
this.

 -  Does  the  Imail/NT/AD  integration  support  (multiple)  virtual
 domains  (ip-less)  - or will it only create users for the AD domain
 name?  Accordingly,  how  will  it  know  that  two mailboxes and/or
 aliases  by the same name, but on two different mail domains, should
 be kept as two different entities in AD?

It's  a  solution  built for single or overlapping userbases (which is
not  the  same  as  just having a single domain--we use this for sites
that  have  several  distinct domains, maildirs, etc., though they are
all  corporate).  It's not for non-overlapping userbases as you'd have
insituations   where   you're   offering   delegated,   segregated
administration for multiple client domains.

So...never  said it would work for everyone, but it's dirt easy. We do
use  _much_  more complex and time-costly stuff than this when we need
to  segregate  and  subdelegate  mail domains, but this has come handy
quite a bit.

--Sandy

P.S. Something else to consider when contemplating an event sink for a
subdelegated  environment  is  using  ODBC  lookups against per-domain
tables.  Anything  that relies on scanning unindexed data on the scale
of  tens  of  thousands of items is just bad programming. Anything but
that.  Remember,  the mighty ASCII-centric Postfix knows enough to use
indexed data at runtime.



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

SpamAssassin plugs into Declude!
http://www.mailmage.com/download/software/freeutils/SPAMC32/Release/

---
[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] message-id header

2004-02-09 Thread Robert Shubert

I got this:

Code: 8000800e. The E-mail failed the BADHEADERS test.

This E-mail has a bogus Message-ID: header.

From the online tool (and that code). I was wondering what constitutes a
good Message-ID? Is there a site (RFC?) or other description of what
these things should look like?

Thanks,

Robert

---
[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[2]: [Declude.JunkMail] Using Imail/Declude as Public Gateway

 Now,  when  someone  sends  mail,  it WILL be validated by the Imail
 server.  If  an alias does not exist, it can be rejected. If it does
 exist,  the mail will be processed by Declude and eventually it will
 be forwarded to the incoming.domain.com...

We  have  indeed built applications that automatically do this kind of
smart MX thing in much the same way using IMail alone.

What  would  be  great about MS SMTP and ORF in this situation is that
you  could  set  up  as many LDAP subdomains as you want, one for each
IMail domain, and push the IMail info into LDAP using CSVDE/LDIFDE. If
you  have ODBC tables for each domain, a SQL  CSV  CSVDE flow should
be very straightforward. Haven't done it, though.

--Sandy



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

SpamAssassin plugs into Declude!
http://www.mailmage.com/download/software/freeutils/SPAMC32/Release/

---
[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] message-id header

2004-02-09 Thread R. Scott Perry


I got this:

Code: 8000800e. The E-mail failed the BADHEADERS test.

This E-mail has a bogus Message-ID: header.

From the online tool (and that code). I was wondering what constitutes a
good Message-ID? Is there a site (RFC?) or other description of what
these things should look like?
The easy answer is that it doesn't matter what they look like -- an 
RFC-compliant mail client will generate properly Message-ID: headers.

The more difficult answer is that RFC822 covers the Message-ID: header, but 
it is not an easy document to digest.

   -Scott
---
Declude JunkMail: The advanced anti-spam solution for IMail mailservers 
since 2000.
Declude Virus: Catches known viruses and is the leader in mailserver 
vulnerability detection.
Find out what you've been missing: Ask for a 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] Using Imail/Declude as Public Gateway





Andy,

You do understand, however you are also leaving off a piece of the
utility. If you are running a gateway service, it might be nice to
force your customers to subscribe their addresses. Postini does this
for instance and for good cause...it prevents them from needing to
accept every E-mail, and it also leaves an auditing trail for charging
the customer. There is a question though as to requiring your
customers to subscribe each address being overly burdensome. I would
probably approach it as a cheaper service since otherwise I would be
processing more E-mail, so if they want no administration, they pay
more and deal with the consequences of bouncing E-mail to bogus
addresses (if it gets through Declude).

Regarding your work around, it definitely looks like it would work. I
am however apprehensive to ask that a client do more than the DNS
change that is required, and in some cases this isn't possible if their
E-mail is provided by yet another party who doesn't care to work with
your solution because they are reselling something like Brightmail (I
have one such customer currently). Besides, it seems like a bit of
overkill.

If you are running a secondary MX off of MS SMTP instead of buying
IMail, then it makes sense to have this all inside of that one
application. It does produce overhead though when paired with IMail on
the same box, so it would probably be best to add functionality to
filter out obvious spam with additional tests. To start though, I
think this first step will be easy to do.

Matt



Andy Schmidt wrote:

  
  Message
  
  Matt:
  
  
   gatewayed E-mail accounts. Since IMail
doesn't offer any way to validate gatewayed addresses or fending off
dictionary attacks 
  
With "gateway" you mean that you are hosting the "public" MX for them
(primary and possibly backup MX), but you are NOT hosting their
mailboxes on your own Imail machine?
  
  Now I understand your application (I
assume). It means that ideally you'd want Imail to validate against an
external user base - even if the mail domain itself is not hosted on
Imail. Yes - I do have the same need. 
  
  It would be nice if Imail had a little
"checkmark" in the mail domain configuration screen. If that checkmark
for "remote domain"is set, then you could still choose an external
"user database" and the SMTPD daemon would actually perform user
validation.However, instead of doing an "LDELIVER" to a local mailbox,
it would then perform an "RDELIVER" to the remote mailbox server.
  
  In reality, all the pieces already exist in
their code. I think it's worthwhile to make THAT an enhancement
request. It would further broaden the usability of Imail and reduce the
need to look for alternative mail servers.
  
  
  With a two scripts, you could probably
already accomplish that:
  
  a) on the client'sremote mailbox server,
export the user database for "domain.com"in intervals
  b) on the clients' remote mailbox server,
create an alias "incoming.domain.com".
  c) on your Imail server, create a regular
mail domain "domain.com".
  d) run a script that reads the client's
exported user database and creates an ALIAS in "domain.com" for every
client USER, e.g. the user [EMAIL PROTECTED]becomes
an ALIAS in your Imail configuration. Point the alias to [EMAIL PROTECTED]and
on your Imail server have a HOSTS entry for "incoming.domain.com"
pointing to the client's remote server.
  
  Now, when someone sends mail, it WILL be
validated by the Imail server. If an alias does not exist, it can be
rejected. If it does exist, the mail will be processed by Declude and
eventually it will be forwarded to the "incoming.domain.com".
  
  
  Best Regards
  Andy Schmidt
  
  HM 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/
  
  
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Matt
Sent: Monday, February 09, 2004 04:42 PM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] [Declude.Junkmail] MS SMTP
LDAP Routing


Andy,

What's at issue here is expanding beyond just locally hosted E-mail
accounts to gatewayed E-mail accounts. Since IMail doesn't offer any
way to validate gatewayed addresses or fending off dictionary attacks,
it might well be wise to place MS SMTP before IMail on the same box,
even if you only have locally hosted E-mail. This obviously isn't an
issue for the most part with backup MX's.

In relation to using IMail's LDAP, that might be too limiting and
provide unnecessary overhead. If you were to access the LDAP server on
the same machine it wouldn't be that big of a deal, but in a fail-over
situation where MX1 went down and MX2 is verifying off of the LDAP
server on MX1, you would lose the verification capabilities. The more
eloquent solution that takes into account all of the various needs
would be to dump an export into a

Re: [Declude.JunkMail] OT: IMAIL - AD





Andy (and Sandy),

I'm not dumping on LDAP, I think it can be very useful, however in this
case, is it really necessary? Why not just support loading a text file
into memory and using that? It's the lowest common denominator and
people without LDAP knowledge or software could make use of it. The
only reason not to use text files would be a technical limitation, but
I'm not suggesting that it be accessed once per message, so that isn't
at issue.

I would certainly look to VAMsoft for this application if they
supported text files, otherwise it looks easy enough to create. I'm
assuming that many around here that would consider such a tool would
prefer that all spam processing be done within Declude...maybe not
either or you, but most definitely some. I would prefer this myself as
long as capacity wasn't an issue. The only stuff that I would block
with VAMsoft is efficiently taken care of within Declude without
touching a single custom filter (besides spamdomains, fromfile and
ipfile types which currently can't be skipped, but no doubt will have
that capability soon).

Matt



Andy Schmidt wrote:

  
  Message
  
  VAMsoft has indicated on their newsgroup that
they consider supporting non-AD LDAP validation. It has been requested
several times afterthey introduced the AD synch and VAMsoft has been
very responsive to customer requests in the past.
  
  (If Sandy's idea was to EXPORT the user and
alias and import it into LDAP (or Active Directory), then, yes, that
could be workable way. However he was very specific in saying "if you use IMail's NT integration" and
that would be the feature where you make all your users NT users (or AD
users).)
  Best Regards
  Andy Schmidt
  
  HM 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/
  
  
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Matt
Sent: Monday, February 09, 2004 05:17 PM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] OT: IMAIL - AD


Andy,

I think what he meant was that you would import the data from IMail
into AD. IMail would still use it's own methods for storing and
accessing account information, but ORF would make use of the AD stuff
that you exported to it.

Personally, I don't use AD on my server because it doesn't seem to
offer me anything of value and adds complexity. The server is a
stand-alone box, and from a security standpoint, I believe it is best
for it to remain that way.

I'm asking my buddy to look into this. We certainly wouldn't come out
with something that did RBL scanning (DNSBL if Scott's listening :) ),
but I'm pretty sure we could get this to make use of a text file dump
fairly easily. ORF was written for an Exchange environment and it
might be easier to write something more appropriate for ours. If
Vamsoft came out with a different tool, then I would be all for giving
them money instead.

Matt



Andy Schmidt wrote:

  Hi Sandy:

  
  

  It's no-brainer if you use  IMail's NT integration on an AD DC. 
  

  
  
I don't want to reinvent the wheel, so I'm trying to research this by
reading the Imail 8 manual. It doesn't reference AD directly (only the NT
User setup and that you have to run on a DC). So before I invest time and
play around with it, I have three "no-brainer" questions, which I could not
answer myself:

- It says that you can't use the Imail "Explorer" to manage accounts (users,
aliases, etc.) - does that imply that my clients wouldn't be able to use
WebMail to add/administer their own mailboxes either?

- Does the AD only store "Users" (mailboxes) - or also "Alias" (e.g., simple
alias, group alias, program alias, etc.)?  If not, then how do you
accomplish using the AD information to verify "valid" RCTP TO information?
A good portion of the email we process is addressed to an alias!?

- Does the Imail/NT/AD integration support (multiple) virtual domains
(ip-less) - or will it only create users for the AD domain name?
Accordingly, how will it know that two  mailboxes and/or aliases by the same
name, but on two different mail domains, should be kept as two different
entities in AD?

Best Regards
Andy Schmidt

HM 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/


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Sanford Whiteman
Sent: Monday, February 09, 2004 03:47 PM
To: Andy Schmidt
Subject: Re[2]: [Declude.JunkMail] [Declude.Junkmail] MS SMTP LDAP Routing


  
  
I  would  seriously  consider funding some of the development for an 
IMAIL/LDAP  lookup  event  sink  as  it would help my SMTP server to 
"disconnect" on dictionary attacks.

Re[2]: [Declude.JunkMail] OT: IMAIL - AD