Re: [exim] SMTP processing hangs during bayes sync

John W. Baxter wrote:

> On 8/31/06 10:02 AM, "W B Hacker" <wbh@???> wrote:
>
>
>>We do have to 'brownlist', for example, NetSol, who send from IP's with no DNS
>>entry, but even there, it is only for traffic from one domain.tld, and fewer
>>than a dozen usernames we allow in that domain.tld. The rest can whistle.
>
>
> Our little nonameok.txt file (which prevents generation of the headers we
> create that SpamAssassin gives points for) presently has 51 lines. It
> probably doesn't have that many *needed* entries, as I add entries as needed
> but haven't recently done a pass through it to remove IPs that now DO have
> reverse name service.
>
> Just today, my message from the Washington State Lottery mailing list wound
> up in my Spam folder because of the points added for no name: the state
> outsourced (or changed the outsourcing) of the list to a company whose mail
> server has no reverse DNS (really none, as opposed to reverse that doesn't
> please Exim). So nonameok.txt grew by one entry today.
>
> We learned early on (which for us means mid-1990s) that we couldn't afford
> to simply block for no name: The state runs DNS for all the school
> districts in the state except Seattle, and didn't know how to do it right
> (and still messes it up now and then, although they seem now to *intend* to
> have it right). Teachers really don't like it if they can't send email from
> school to spouses at home--and no one at the schools involved can fix the
> problem.
>
> We spent a LOT of support time trying to educate admins about DNS in the mid
> to late 1990s, and gave up (we couldn't afford to continue).
>

Much the same experience, frustration, and needed goals here.

To expand:

'The rest can whistle' means here that these corresponding servers are at the
mercy of the individual recipient's (user, not domain) tolerance threshold
settings fro protocol violations (RUDELIMIT).

A warn verb assigns 'demerits' for these transgressions. Accept/Deny decisions
come later.

Other filter settings aside, some of our accounts are configured to receive from
all such 'broken' senders, some only from those who have committed no other
significant protocol rudeness.

- The 'brownlist' just insures that, for example, branch office and headquarters
staff for a specific company will always be able to communicate, EVEN IF they
have otherwise set personal preferences on a portion of their accounts so
strictly as to reject. 'Public Facing' Accounts are ordinarily the most
forgiving, etc.

The 'demerit' scoring + personalized thresholds allows info, helpdesk, sales,
marketing, etc. to be more open, while internal staff and executive accounts see
fewer distractions.

That reduces list white/black/brown maintenance load for us, not just on this
'violation', but for spam as well.

The only thing we DON'T allow customization of is a ClamAV hit. That protects
our Windows users, who, by implication, cannot make wise choices.

Both of them. (users, or choices)

;-)

- and all of us who use borrowed/public boxen when traveling...

Bill



Bill