Yeah, that's probably what I'll end up doing too. I've definitely not gotten rid of my non-trach emails, but I was thinking of holding on to them now.

So the answer would be no, they don't need to be in the SPAM folder to keep the program working. I have no problem with archiving them away, but I'd like to clean it out every once and a while.

What do you use to archive? Are you using Outlook? How do you do it?

I use an IMAP server on my Linux box to store my mail, all the filtering happens there. I have a bunch of Unix shell scripts that do the archiving and are run automatical (for example I have one that watches two folders that I drop misidentified spam and non-spam into and reclassifies them correctly).

Outlook allows you to schedule archiving actions into another set of personal folders. That's not quite the same though...

I keep all my spam and non-spam

I used to do this, but lately I have a combination of things for spam prevention. With Postfix, I have my e-mail address, then the ability to have infinite aliases with no server side changes. So, I sign up for a new web board for example with drakino_newwebboard and I can get the initial e-mail needed to activate the account. Now, if that address gets harvested by someone and I get spam, I tell my procmail file to throw anything to that address away. If needed, I can just go to the board and change the e-mail to drakino_newwebboard2 to keep getting board notices.

Helpes quite a bit for server side IMAP filtering too. I can just say toss anything to drakino_bank into my bank notices folder.

ability to have infinite aliases with no server side changes

Yeah, I do the same with qmail: [email protected] goes to me, which makes it easier to filter email from a particular source.

Where it gets annoying is that Outlook doesn't (unlike mutt) provide any hooks when replying to emails, or sending to particular addresses, for setting the From address accordingly.

Maybe I can do something server-side on the way out, I don't know.

I'd be amazed if you can't do it with every bit of Unix mail server software. I do it with Sendmail and never realised there was anything special about it.

Until you've tried to do things with MS Exchange (esp. versions prior to 5.5), you truly don't appreciate the "specialness" of ye ol' Sendmail.

Maybe, but in my experience Sendmail and Exchange have one feature in common, there are both keen to drop all your mail down a black hole at the slightest sign of a misconfiguration. I have always thought this was an odd design choice...

N.B. I haven't used Exchange as an admin since before 5.5, so it might have got better in this regard, but I doubt it

Yeah. I do appreciate the "specialness" of Sendmail which is why I use Postfix Exim or Postfix is a much better option that Sendmail in my opinion. The rules for Postfix don't look like the line noise you get in Sendmail as well.

The rules for Postfix don't look like the line noise you get in Sendmail as well

Well, you have to remember when Sendmail was written, and for what purpose. And what Eric most probably was smoking at the time

I find Eric's comment "sendmail took the approach that it should try to accept, clean up, and deliver even very 'crufty' messages instead of rejecting them because they didn't meet some protocol" (from http://www.busan.edu/~nic/networking/sendmail/prf1_03.htm ) somewhat ironic given that any time I screw up a sendmail configuration the end result is mail disappearing without trace

Thankfully I only have to touch sendmail config files about once every 18 months (which probably also explains why I screw it up every time), in between times it just keeps working...

That's weird. I've never seen sendmail drop messages on the ground except in cases of extreme misconfiguration.

I must have an extreme talent for screwing it up then

Yeah...I've had it pipe messages straight into the bit hole when messing with the sendmail.cf rules. I was working on a mail to fax gateway at the time.

Most of the time, however, when something's misconfigured, the messages just get dumped to root.