ietf-asrg
[Top] [All Lists]

[Asrg] Re: whitelisting

2005-04-26 07:31:33
On 25 Apr 2005, at 21:57, gep2(_at_)terabites(_dot_)com wrote:

The point of a whitelist (IMHO) is to toss out certain types of incoming mail that you aren't willing to trust or accept from people you don't recognize.

I think we're getting into a bit of a semantical tiff here. This is dependent on whether or not your site is practicing a default deny or default accept policy with regards to mail. Many sites would rather trust unknown senders and reject known poor senders rather than increase false positive rates and associated support costs.

Ideally, such a whitelist is VERY finely-grained, and with a "relatively safe"
default behavior.

Finely grained anything leads to scalability and complexity issues. That is not to say such solutions cannot work, only that the trade off between complexity and effectiveness often yields diminishing returns.

When you whitelist senders, you ought to be able to do so (again) in a
fine-grained way.

In your proposed implementation, who controls this white list? The "you" appears to indicate the mail service provider, however, managing a finely grained permission set for millions of users quickly outstrips available resources. Another solution is to have service representatives default allow behavior when a customer complains, however this is expensive both in representative time and in the amount of churn it will cause due to dissatisfied customers. The most scalable solution is to have the customer control their settings. This most likely would fail as most customers will not understand the options of a finely grained control system.

Once the HTML, scripting, and attachments are zapped, there are relatively few tricks remaining that spammers can use to evade content filters... so the fine-grained whitelist discrimination should be followed up by a good content
filter.

Do content filters not weight based on the presence of HTML, scripting, and attachments? Does not automatically deleting matches to this blanket rule reduce, not increase, your amount of control over what mail you allow?

I disagree... I think you CAN use it to reject spam, although one might argue that it's even more useful to reject OTHER kinds of unwanted/untrustworthy
mail.... specifically, phishing scams with misrepresented hyperlinks,
attachments which carry viruses or worms, and other unwanted junk.

Once again, this is semantics. Default deny versus default reject.

I agree that knowing who the "real" sender is can be useful, although by itself it's NO guarantee of safety (or not being spam) either. The fact that the "from:" address represents the actual machine of (or an alternate machine sometimes used by) that legitimate sender is NOT a guarantee that said machine hasn't been commandeered by a spambot zombie which is sending out spam or
viruses using the victim's authorizations and certificates.

This is a remote site management issue. It is up to the remote site to manage whether or not their senders can forge "From:" fields. The domain based identification allows us make policy decisions based on administrative boundaries, that is to say we can either block poor senders or return mail to the administrators for further investigation. You cannot guarantee that the mail was send legitimately, but you can guarantee that your policies are affecting the responsible parties.

Many "certification" schemes are worse still in that they only try to determine that the E-mail originated from a server authorized to send mail from the indicated "sender domain", and for domains containing (literally) millions of valid E-mail addresses, that means that ANY of those millions of machines could counterfeit/spoof the E-mail address of any other user within the same domain name and still successfully pass the "authorized mail server for that domain"
test.

Once again, "spoofing" is a domain based sender policy issue. If the remote site is only allowing "From:" fields to match the authenticated username this is a non issue. If the site is not authenticated mail sourced within their domain, then my external policies are in place to restrict this behavior.

Ultimately, it's a FAR better solution to identify spam based on whether it "looks right" (i.e. looks like mail is EXPECTED to look, coming from that specific sender) and that it doesn't contain anything (executable attachments, encrypted ZIP files, Javascript, ActiveX modules, etc etc) that make its purpose
or intentions suspect.

I disagree. Keeping state on specific senders will not scale to the whole internet. If you're discussing keeping state on specific senders in an edge model, this might be appropriate as the number of legitimate senders to a single receiver is small, however on an enterprise level I cannot fathom a manner to efficiently manage state for every sender destined to my customers. It is less complex to create stateless policies based on message contents and keep state on high traffic authenticated sender domains.

Attachment: PGP.sig
Description: This is a digitally signed message part

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
<Prev in Thread] Current Thread [Next in Thread>