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.
Your practice is anything but "best" or "current".
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.
The standards don't say "don't cut your arm off" either. That doesn't
mean it is wise to cut your arm off.
When you make dubious or incorrection assumptions about how the mail
system works and use those assumptions as justification to discard or
bounce mail, you may be within the letter of the standards, but you're
not within the intent of the standards.
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.
There is no 100% reliable way of knowing that you have a false positive
without showing the message to a recipient and asking him if it is a
message he would want to receive. You certainly can't detect such
things based on source IP, MAIL FROM, and RCPT TO.
Keith is filtered in a black list - an administrative level policy. Instant
notification conforms with US ECPA provisions.
Here's the message I'm getting from your server:
<hsantos(_at_)santronics(_dot_)com>: host mail.winserver.com[208.247.131.9]
said: dIn ???
550 Return Path not verifiable. (in reply to RCPT TO command)
Now according to RFC 2821 550 is the correct reply code for "Access denied"
but the message "Return Path not verifiable" is misleading at best. Either
you are rejecting my message due to totally bogus criteria or you are returning
a misleading error message. If you're really bouncing my mail because you've
blacklisted my return address, a more meaningful text message would be
appropriate. If you supported ENHANCEDSTATUS codes a status code of 5.7.1
"Delivery not authorized, message refused" would also seem appropriate.
Personally I don't bounce mail from you - instead I file it into an
appropriately-named folder in case I realize that there's a need to read or
respond to something you've said.
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.
Everyone in this business gets to succeed or fail based on his reputation.
You and your company are no more immune from criticism than anyone
else - though your tendency to concurrently make dubious statements
and claim superiority for your products does make you a more tempting
target. Of course the point of such criticism isn't to bash any one particular
person or company but to point out examples of harmful practices that
need to be discouraged - not just in your products but in everyones'.
Keith