Re: [courier-users] DNSBL exclusion

Alessandro Vesely wrote:
> mouss wrote:
>
>> Alessandro Vesely wrote:
>>
>>> mouss wrote:
>>>
>>>
>>>> 3- never block your own users with methods designed for "inbound" mail.
>>>> This includes DNSBLs, spamassassin rules, ... etc.
>>>>
>>> One exception is when you have methods that can determine that mail
>>> is being sent by automated malaware. Viruses, e.g., are dropped from
>>> external relays and customers alike.
>>>
>> well, I really meant "designed for". so this is not an exception,
>> because virus filtering is not designed "for inbound" mail. it is
>> designed for all mail. I don't mean one should not filter outbound mail.
>> but the methods to do so are not the same as those that apply to inbound
>> mail.
>>
>
> Anti-virus was an example. Email Service Providers could also use
> anti-spam rules to monitor their own subscribers. It's not just software
> reuse: not distinguishing between inbound and outbound mail the original
> SMTP protocol allows to _design_ filters generically.
>

If you try to find a general pattern that blocks all spam but does not
block ham, then you'll find it impossible. if instead, you implement
specific rules based on the situation, you can do better. mail sent from:
- internal networks
- generic rDNS hosts
- large ISPs
- ....
- other networks

can be checked using different rules. sure, you can use a single filter
to do all this, but complexity rarely pays for itself. Instead, divide
and conquer. Use the right tool to fight each different enemy.

There are also non technical considerations here. I would have no
problem rejecting a mail to my boss if the sender is non fqdn. I can
however not do so if the mail is coming from an (internal) MUA. In the
case of an ISP, legal consideration gets into play.

> OTOH, existence of port 587 may indicate there is something wrong with
> that approach...

It's a divide and conquer thing. why should I design complex things that
work in all cases, when I can design small pieces that handle specific
problems?

forcing users to use 587 with authentication and configuring the MX not
to relay can be easily and safely configured. configuring all rules on
an MX is error prone, and it takes some effort to make sure it's doing
the right thing.

> In facts, there are also services designed for monitoring
> customers' outbound mail, e.g. some of those provided by ProjectHoneyPot
> or CAUCE, that we may consider complementary to DNSBLs, in that sense.
>
>

sure. you can do many things for outbound mail that you cannot do for
inbound mail. you can analyze the behaviour of mail (and other traffic)
generated by some machine, and this can be used to detect whether it's
owned. you cannot do that with external machines, because there are too
many zombies out there, and spammers can use one different machine per
connection, so no statistical analysis is possible (statistical analysis
of content is still possible).

some people use no content filter: they only reject mail at smtp time,
and they find this sufficient. you cannot do the same for outbound mail.
if you do not trust your users, you need to do content analysis. but in
most companies, you can just trust your users (except for virus
filtering) and only take action if you detect misbehaviour. In short, a
reactive approach may be viable in the case of outbound mail, but fails
quickly in the case of inbound mail (you can spend days listing zombies,
just to get stormed by new ones).

I am not saying one should design N different systems. I am just saying
that analysis and implementation should not be constrained
"arbitrarily". This is no different than writing N different unix
programs to do a single task when one could do a lot of things. In
theory, all those cp, ls, mv, ln, ... etc could be implemented as a
single program (after all, they work on files). would you do that?


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/.../courier-users