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