All,
I am a bit of a novice to enter this discussion. But I can give a bit of
insight as to the scope of the problem.
Some of our commercial clients are fussing about what they consider false
positives on our spam control system. We have determined that most of this
comes from sites running IPSWITCH's IMAIL product. This has a
configuration option to reject mail from <>.
I have had little success in making the RFC argument. They understand the
RBLs, but the concept of an RFC doesn't penetrate (which makes sense in
context - most of our clients are US Based; we seem to favor unilateral
action like the RBLs and we just won't stand for the likes of international
consensus:(.
So yesterday morning I turned sender_verify off. That action permitted
about 2000 additional mails into our system in the last 24 hours and we're
a small outfit. Some of those were blocked with spamassassin, but even so
I have noticed a jump in spam mail coming to my own mailbox.
My problem would be solved by the suggestion presented below - or
convincing the IMAIL folks to fix their product. An alternative would be
to make the callback "Warn" like the RBLs. Then we could let the end user
deal with it based on the headers.
----------------------
Because if you implement callbacks, you're most likely not refusing <>
What I already discussed with Philip was to have callbacks that first do
MAIL FROM: <>
fail null mail from
or
RCPT TO: <dest>
fail null mail from
RSET
MAIL FROM: <postmater@mysite>
RCPT TO: <dest>
-------------------------
Bruce C
