Update to my Spam-Reporting AppleScripts

I think I tried to do this back when I set these spam-reporting AppleScripts up originally, but I couldn’t find the right variable to set. Turns out I didn’t look hard enough. Here’s the change:

tell application "Mail"
	set theMessages to the selection
	repeat with thisMessage in theMessages
		set newMessage to make new outgoing message at end of outgoing messages
		tell newMessage
			set content to thisMessage's source
			set subject to thisMessage's subject
			make new to recipient with properties {address:"spam@uce.gov"}
		end tell
		send newMessage
		set junk mail status of thisMessage to true
		set read status of thisMessage to true
		move thisMessage to mailbox "INBOX/ConfirmedJunk" of account "[$account]"
	end repeat
end tell

Simple enough, no? The updated scripts: spam_uce_gov.scpt and spoof_paypal_com.scpt. You could, of course, further modify the {address:”email@email.tld”} to send wherever you like. If, for example, you have a specific place you’re fighting phishing attempts [e.g., your bank], and you know their phishing address, set one up for them.

Additional Thoughts

I use these two scripts with the excellent Mail Act-On package. I have rules for each: J for general junk mail, and P for PayPal/eBay spam. Actually, my MA-O use is what drove me to seek out the junk mail status flag, because otherwise to train Mail’s spam filter took an extra step. I wish I’d Googled a little harder three years ago, as I’d probably have saved myself an hour of typing and clicking over that time.

Update: These scripts were broken by syntax changes in OS X Lion, but they have been updated.

TiVo and the iPad

Why has TiVo not built an iPad application yet? Ideally, it should do three things, two of which are directly related:

  1. Allow the scheduling of recordings from within the app. Yes, this can be done on TiVo.com, but anyone who’s used that UI can tell you that, uh, it’s clunky and very un-TiVo.
  2. Monitor the recordings currently scheduled on the TiVo in question. Yes, this is also done on the Web site, and while it’s easier to find, it’s not as easy as it could be. This would be related to the first in letting you see a) what’s being recorded and b) resolve conflicts in the TiVo app.
  3. On the local network where your TiVo resides, show the current queue of shows on the TiVo. This can be done, as the TiVo Now Playing Dashboard widget shows.

Admittedly, the last one could be done with a standalone app, but it seems like something that should be a part of a larger TiVo-focused app. Also, there’d be plenty of other opportunities for the app: in-app purchases equivalent to the TiVo store, etc. Seems like a win to me.

Two Apps I’d Buy

Here’s a couple ideas that have been rattling around the ol’ brain for the last little bit …

  1. If I’ve got the lyrics entered into the metadata of a song in iTunes, I want to see them superimposed onto my desktop. That way, if I have everything hidden save the Finder, I can read the lyrics while I listen to the song.
  2. I want a Bluetooth application that displays a Growl notification with whatever phone number is ringing on my iPhone. Do I want to careen across the house to pick up my ringing phone or not? Really, Apple.

As always, these are free ideas for which I’d only like passing credit, not anything I’d want money for, you know. I just want them.

Advice on Migrating cPanel/WHM Accounts

I’m merely posting this to help whoever can be helped by this. There’s nothing really Earth-shaking here. :)

Say you’re in the situation I was in last month: migrating accounts from one cPanel/WHM-based server to another. You looking for some step-by-step advice on a best practice to move stuff? Here it is:

  1. Make a list of all your accounts to be moved. Double-check it. Use this list to develop your IP allocation plan [if you need one; if you don't have resellers, you don't need one].
  2. Break up the list into chunks; no one wants to move all the accounts in one sitting. The most I moved at once on this move was on Saturday, when I moved 12 accounts. Took me a good chunk of the day watching WHM do all the heavy lifting.
  3. Reset the DNS time-to-live [TTL] from 86400 to 1800 for each account around 24-36 hours before you’re ready to make the move. This will allow you to have DNS changes propagate smoothly and quickly.
  4. On the day of the move, initiate the account move first. You can use the single-account or the multi-copy under Transfers in WHM; I did the first few one at a time until I was fully familiar with the process. [I do this every couple of years or so as I move servers, but WHM usually has made changes in the interim.]
  5. Once the move is complete [or nearly so, if you're moving lots of data], go change the IP settings to the new IP you allocated for the account when you made that list at the beginning. You don’t want to do this too early and have the site appear offline.
  6. Once the move is complete and the DNS is changed, log in to WHM on the old server and suspend the account. This will prevent people from interacting with the old site on the old server [sending email, posting to it if it's a user-generated content site].
  7. An hour or so after the move’s been done, see if you see the site on the new server. If you didn’t, something’s wrong.
  8. The next day, terminate the account on the old server and change the DNS TTL record back to 86400. No sense hammering your DNS provider. [As to why you shouldn’t change the TTL when changing the IP: my experience is that changing both mucks up propagation. I can’t explain it, as it should work properly that way. This is a conservative way to do it, and I’ll take that.

There you have it. You should be able to do all this without a net here. The joys of using cPanel/WHM for account moves are many, including the fact that doing so abstracts away some of the local environment issues you might have.

Lastly, a plug: if you use cPanel/WHM, you ought to have your server tuned and hardened by the folks at ConfigServer. I don’t get anything for this plug but the satisfaction of your server being done right. At this point, I don’t run cPanel if they haven’t tuned it out for me.

AppleScript to Send Mail to spam@uce.gov, Move to Spam-Learning Folder

Okay, the title of this is pretty darn long, but I’m writing for Google. :)

Back some time ago, I saw this AppleScript to forward spam to the FTC via Mail and liked the concept. It makes me at least feel like I’m doing something, you know? [Probably not much; I'm a government contractor, so I know what government might not do well.] I adapted it to report PayPal phishing attempts to spoof@paypal.com, and well, that was really it. My main change was in deleting the email after sending the mail on forward.

Now that Fastmail provides a spam-learning option for folders, I’m wanting to improve its spam filters. It already does a solid job—most of the spam I get goes into Junk Mail. However, I do get false positives, so I didn’t want Junk Mail to become the spam-learning folder. I then devised this concept:

  1. Create a folder called ConfirmedJunk and set it in Fastmail’s Web interface to be a spam-learning folder. I also set this folder to auto-purge every month to keep my quota use down.
  2. Rework my AppleScripts to go from deleting the junk mail to putting in ConfirmedJunk.
  3. There is no step 3.

Well, it took a little while banging my head on this tonight, but here’s what I came up with:

tell application "Mail"
	set theMessages to the selection
	repeat with thisMessage in theMessages
		set newMessage to make new outgoing message at end of outgoing messages
		tell newMessage
			set content to thisMessage's source
			set subject to thisMessage's subject
			make new to recipient with properties {address:"spam@uce.gov"}
		end tell
		send newMessage
		set read status of thisMessage to true
		move thisMessage to mailbox "INBOX/ConfirmedJunk" of account "[$account]"
	end repeat
end tell

The above is “spam_uce_gov.scpt“.

tell application "Mail"
	set theMessages to the selection
	repeat with thisMessage in theMessages
		set newMessage to make new outgoing message at end of outgoing messages
		tell newMessage
			set content to thisMessage's source
			set subject to thisMessage's subject
			make new to recipient with properties {address:"spoof@paypal.com"}
		end tell
		send newMessage
		set read status of thisMessage to true
		move thisMessage to mailbox "INBOX/ConfirmedJunk" of account "[$account]"
	end repeat
end tell

That’s “spam_paypal_com.scpt“.

Use ‘em if you can. Be sure to put the name of the account in there as Mail knows it and change the folder name as appropriate. I will not know the specifics of your setup unless you mirror mine. This script is provided free of charge and is unsupported.

6 Jun 2010: The scripts shown in this post have been superseded by a more recent update.