Shane Williams <[EMAIL PROTECTED]> writes:
> I haven't seen the new behavior (partly because this discussion made
> me reconsider), and Theo's response eases my mind, but here are the
> reasons I think the change is maybe not such a good idea. (Really, as
> long as the old header_report and mimedfang off behavior is an option,
> I don't care, so in that sense, consider this an argument not to
> abandon that system).
The old behavior is there. It's just one option now ("report_safe 0").
The rest of my message assumes that the body reporting is on.
Otherwise, it's not much of a discussion. :-)
> 1. Change. There is always a cost associated with changing (even if
> the change is "good"). For me, it means retraining users, altering
> all the procmail and MUA filters put in place based on the old
> method, and implementing a new one. Admittedly my users are
> perhaps more technophobic than others, but there users nonetheless.
> In particular, regularly changing software behavior is even worse.
> Is the "benefit" of the change worth the "cost" of the change and
> is the change permanent enough to offset the short-term cost?
Yes, there is a cost associated with changing for existing users, but
the ongoing training cost and cost for new users is definitely lower.
For 2.44, try explaining to a user how to:
- remove the body markup (where is the "spamassassin -d" option in
Outlook?)
- remove the header markup
- display the HTML body or other MIME breakage (for HTML false positives)
In addition, it will now be *possible* for mail systems to:
- report unadulterated spam to Razor and similar systems
- save original spam for use in corpuses
> 2. Transparency. I think we can all agree that average email users
> rarely (if ever) look at full headers. For the system I manage, I
> turned off subject munging and put reports in headers only. Then I
> filtered everything through SA. If you didn't want to "use" SA,
> then you didn't have to do anything. For those people the messages
> were essentially unchanged. Even for those who filtered based on
> SA's scoring, the effect was transparent. They (or more likely one
> of our techs) set up a filter in their MUA, told them to check for
> false positives, and to them it was magic (normally I hate making
> things appear like magic, but many of these users are tenured
> professors, they don't (and many won't) learn the details).
I think this is only a point if you don't have a way to turn it off.
Well, the default is now to not mark-up the Subject, but to use the safe
report format. We opted to go for "transparent except when it conflicts
with safety".
Few things are worse than opening an malicious HTML spam with an unsafe
mailer that reports to big spam brother that you exist and actually read
their spam, does something evil with Javascript, and more stuff to ruin
your day.
> 3. Efficiency. One of the purposes of SA is to make it easier (and I
> think faster) for people to read the email they need to read and
> skip the spam. Encapsulating potential spam means one more step
> they have to take to check whether something is really spam or
> not. While there's something to the idea that encapsualtion
> protects users from included images, if they want to verify its
> spamminess, they're going to have to look at it anyway. If they
> don't want to verify, then they just don't click on it in the first
> place.
I also think this is only a point if you don't have a way to turn it
off. If you compare the old body reporting method with the new one,
this is a great argument for the new way.
And no, you don't have to look at it anyway. In addition to seeing the
original From:, To:, Cc:, Subject:, and Date:, *and* the list of rules
that got hit, the new report also includes an excerpt from the message
(it even decodes HTML!). You no longer have to open the evil HTML spam
to decide whether it's spam. :-)
Well, I hope I've convinced you that exterminating the old evil body
report method was the right thing to do.
Dan
--
Daniel Quinlan anti-spam (SpamAssassin), Linux, and open
http://www.pathname.com/~quinlan/ source consulting (looking for new work)
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
