Pete,
I try not to get too passionate about things around here, so I welcome
your contribution. You are correct though, after a couple of days of
discussion, the solution to this need does appear to exist.
I have a great appreciation for your skill, and your willingness to
share both insight
> 1) Envelope rejection (and all that comes with it).
Already extant, as previously discussed.
> 2) SMTP AUTH (so it can co-exist on the same server as IMail, and handle
> hosted accounts with redundancy).
This is going to be very difficult relative to the other ideas, if you
continue to resi
Sorry about that - I seem to have stepped into a bit of a tiff. I was
skimming and saw a Sniffer reference and jumped in - I shouldn't do that (I
should get more sleep). At any rate, the pattern matching engine can run at
any point... Sniffer as it is packaged now runs after submission, but the
Pete,
Everything that Sniffer does is after submission, so it really
wouldn't apply.
--Sandy
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
e-mail: [EMAIL PROTECTED]
SpamAssassin plugs into Dec
In terms of scale, I would expect
to see a server handle not much more than 500,000 messages in a full
Declude/IMail environment, and with an average of more than 10 pieces of
spam per address per day, a solution of this sort would need to
effectively resolve against 50,000 or so E-mail addresses
Sanford Whiteman wrote:
It's simple and built-in functionality, not a tweak or anything like
that all. You simply enable the recipient blacklist button in the
"everybody but these people" mode (one of two modes). There's no need
to worry about processing order. All addresses are in plain
> To be honest, yes, I don't think I saw that in your messages. Take
> it from a fellow rambler...you could condense things from time to
> time...and maybe spend less time describing how I'm wrong or how
> impossible a task might be :)
Maybe...
> I saw a reference to an "everybody but"
Sanford Whiteman wrote:
Did you fail to read (twice) the part of my posts about the "accept
only for these users" option in ORF, which is loaded from a text file?
This has nothing to do with LDAP.
To be honest, yes, I don't think I saw that in your messages. Take it
from a fellow rambler..
> If VAMsoft builds this, please let me know. If I find that there is
> no interest on the part of my friend in programming this, I may very
> well think about going the LDAP route for lack of the "proper
> cable."
Did you fail to read (twice) the part of my posts about the "accept
only
Sandy,
I would prefer to pay $99 for a product that did what I wanted it to.
My issue is that I don't want to rely on AD or LDAP, though I would
consider a DNS implementation (with translation of addresses to valid
values, like [EMAIL PROTECTED] becomes
matt.mail.example.com.my-filter-domain.
> My friend is one of the most capable programmers that you will find,
> he's done a great deal of work in the last 5 years within
> Microsoft's framework, and I don't expect for this to be a challenge
> for him.
This is not at all a comment on his skills--many of us program for
Win
Sanford Whiteman wrote:
Jsut fine. Tens of thousands is a very, very different story. Again,
you seem to be missing the point in thinking these two situations
don't present different requirements. "Solely for the purpose of
scaleability" is one of the purest and most commendable
> However, had the proper cable been available, we would have been
> greatly overly complicating matters.
Indeed, your "proper cable" already exists in the form of the
"everything but" recipient list in ORF, as I mentioned in my last
message. I think you should use it.
> I gues
Sandy,
You're quite a capable person, and some of this stuff might be trivial
for you, or maybe you just like tinkering with such things...but, it's
overreaching to assume that this is the same for the vast majority of
users.
A long time ago when I was in high school and proud member of the g
> 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?
Because it's poor architecture that I wouldn't trust on my mailserver.
> It's the lowest common denomina
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 informat
> - 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 prope
Title: Message
VAMsoft has indicated on their newsgroup that they consider supporting
non-AD LDAP validation. It has been requested several times
after they introduced the AD synch and VAMsoft has been very responsive to
customer requests in the past.
(If
Sandy's idea was to EXPORT the us
> 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 t
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
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
21 matches
Mail list logo
