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.
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