----- Original Message -----
From: <Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu>
Given the number of times you've said "We do it this way, therefore the
rest of you should"
I have NEVER said such a statement. You can't prove it. I never have and
NEVER will because it isn't my character to do so. If that is how you wish
to read it, I can't help that. But I have NEVER, EVER, EVER told anyone in
my entire software and product engineering and development carries "to do it
may way."
I am providing my own insights. That's it. It is very valuable insight
whether you care to believe that or not.
with little or no consideration of what circumstances
caused the codifying of standards sections you find inconvenient,
I am not BREAKING ANY STANDARD whatsoever. I am maximizing whatever is
necessary to be done within the confines of the specification and the best
current practice. Where it is spelled out, it is 100% followed. Where it
is ambiguous, you do what is the BEST thing possible to make it work for
your customers and interfacing with the rest of the world.
I think he's got you here as well...
I disagree with you 100%. But of course, I understand why you may think so.
Maybe if you fixed your mail system to work according to
standards rather than your imagination you wouldn't attract such
criticism.
This one is borderline. However, I'd *strongly* recommend not starting
any
"defamation and tort legal action" unless you are *really* sure that
*nobody*
is able to produce a copy of an RFC-compliant message that was rejected by
any
mail system under your control at the time...
(Anybody got one? ;)
You don't have to ask anyone. There is no doubt we have false positives but
they are ADDRESSED 100%, For whatever reason the false positive exhibited
itself, it was probably a bug or some tight administrative LEVEL filter.
BUT with 100% without of doubt, no SMTP level false positives that did not
have a meaningful reason.
In fact, Julian Mehlne (SPF) just reported what seems to false positive and
a possible bug with our SPF processor. I bring this up because it has to do
with the MX expander and his specific SPF record. I'm looking into it as
we speak.
If a bug (and I'm sure it is), it will be fixed. No big deal.
But nothing due to NON-COMPLIANCE.
Keith is filtered in a black list - an administrative level policy. Instant
notification conforms with US ECPA provisions.
100% support for BOUNCE notifications, if necessary. No NUL BIN DUMPING.
Conforms with US ECPA provisions.
Nothing you will be able to prove that we are RFC x822 or RFC x821
non-compliant. NOTHING and claiming without proof will cause us business
harm.
And you find something - GREAT - all the better. I have a thick skin. We
fix it and move on.
Finally, this isn't going excuse all the defamation and tort attacks and
call for censorship attacks I have experience from Keith. I won't have a
problem proving this.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com