Dan Hollis <[EMAIL PROTECTED]> writes:
> The old SA method makes it easy to deal with spam with various email
> clients (eg elm, pine). The new method of making attachments out of
> mails makes it MUCH more difficult.
a) If you don't want the body modified, you still have that option (and
just like before, body reports are the default).
b) If you do want the body report, users have more and better options
for handling probable spam.
- running "spamassassin -d" to remove SA mark-up still works and it
works better.
- mailers with built-in MIME support can get at the original without
running an external program (try getting a Windows Outlook user to
change edit Content-Type: headers or run "spamassassin -d").
- old (especially old Unix) mailers without MIME support can still
use "spamassassin -d" or standard MIME tools to get at originals.
Again, if you don't want body reports, turn them off. But, if you do
want body reports, the new way is vastly superior to the old way.
If you, as a mail administrator, think some other body report format is
better, the new format also makes it very easy for you to implement that
with a post filter. It was not especially easy with the old format.
> And telling users to "just change your email client" is not a
> sufficient answer.
I agree.
> Not to mention violating the "rule of least astonishment", eg
> spamassassin should behave in a way that astonishes the user the
> least. Receiving spam mails from 127.0.0.1 is certainly suprising to
> say the least.
Many sites relay mail from one of their own servers. Receiving from
127.0.0.1 is not much different than that. If a user has report_safe
turned on, receives a probable spam, *and* decides to look at the
Received: header, it should be pretty obvious where it came from
("SpamAssassin").
I am, however, now thinking about the Received: header thing. We might
need to do some tweaking. There's always going to be a bit of a
break-in period when things change to this extent. That's also why the
README for 2.50 red flags the new report format in the first paragraph.
> The new SA 2.50 defaults will result in increased helpdesk support calls
> at large sites. Please think carefully about this before unilaterally
> enforcing these suprising/astonishing new defaults.
We did consider it very carefully and multilaterally.
The number of questions and confusion about how to remove the *old*
style body report and mime_defang method was very large. Trust me, we
want to reduce the amount of support. Almost all of the major SA
developers have users that they have to worry about supporting, both
Windows *and* Unix users. In fact, some of our livelihoods depend on
making SA as easy to support and use as possible.
Daniel
--
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
