On 13 Mar 2002 at 22:29, Smith, Rick wrote: > > Jim - > > Have you gotten any response to your email (attached below for > reference) ? I'm interested in BOTH options. > > Rick > > > > > -------------- Attached message below ----------------------- > Message: 8057506 > FROM: Jim Paris > DATE: 03/09/2002 20:36:05 > SUBJECT: [SAtalk] More complex customizations (MIME, etc) > > > I'd like to make two changes to how SpamAssassin behaves: > > 1) If a message is spam, it should not be modified, but instead be > replaced by a multipart/mixed message where the first part is > a text/plain containing the SpamAssassin report and the second > part is a message/rfc822 containing the original, unmodified > message. This facilitates easy reporting to appropriate abuse@ > administrators, and allows me to easily deal with the message as > if it were normal if, say, I glance through the spam folder and > find a false positive. > > 2) A message in the exact same format should be sent back to the > original sender. I realize that most of these will bounce, but > that's fine. I want the first text/plain portion to describe why > and how it was rejected (with the SpamAssassin report included); > I'll also use this to give them a password that they can include > in the subject (and to which I would assign a really negative score > in SpamAssassin), to ensure delivery if it was, in fact, sent by > a human. The second part, again, would be the original, unmodified > message/rfc822. > > So, my question: What's the best way to do this? Should I modify > Mail::SpamAssassin and add these two things as options (an option to > create new MIME messages rather than modify the existing one, and an > option to send a message back to the sender), or should I just create > my own Perl script that uses Mail::SpamAssassin in its current form? > The latter seems difficult because there's a lot of code in > Mail::SpamAssassin specific to the current behavior, but modifying it > would really only be ideal out if it was something that I could get > included in the main distribution. Or is there some more elegant way? > > Or should one be added? For example, we could pass a callback > procedure to check(), and have check() simply invoke our procedure > with all of the gory details after determining what's up with the > current mail. Still, I'd have to modify /usr/bin/spamd or just > rewrite it to actually do this, which is non-ideal.
This might be easier to implement outside of SpamAssassin, depending on your MTA. I'm using Sendmail + MIMEDefang (http://www.roaringpenguin.com/mimedefang/), a milter based mail filter that's been around for a couple of years now. It's primary purpose is taking apart MIME messages, analyzing attachments, and implementing security policy, but recent versions have included SpamAssassin integration. It has the ability to quarantine messages (or parts of messages), bounce messages, send notifications, add text to messages, and a variety of other things. ---- Nels Lindquist <*> Information Systems Manager Morningstar Air Express Inc. _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
