August 20, 2007

  • More SPF Stuff

    OK, so SPF is kind of interesting, in that: a) You have to wait for DNS servers to propagate it before you can really test it, and b) not all servers will do what you'd think with it.

    Here's what I have for my SPF record: v=spf1 +mx +a:my.main.smtp.server -all

    The v means SPF version 1. +mx means any mail server listed in the DNS record gets a pass. +a means that specific smtp server gets a pass, and -all means if it didn't pass any of those tests, it's a fail.

    So I sent email to my gmail account through an smtp server that's not allowed, and sure enough, gmail's server failed it. But the thing is: It let the mail come through. So I can see it and read it like any other mail; it's just marked as failed *in the headers.*

    Authentication-Results: mx.google.com; spf=hardfail (google.com: domain of spamtest@mile23.com does not designate 204.127.225.92 as permitted sender) smtp.mail=spamtest@mile23.com

    Also, I'm sending these through comcast's smtp server, which should also mark them as failed, but doesn't.

    I guess there's still much to learn.

    Also, on top of all this.... The reason I got started on the SPF jag is that my inbox got clogged with bounces yesterday, for emails sent spoofing my domain name. That is, [randomname]@mile23.com. So clogged, in fact, that Apple's dainty Mail.app couldn't keep up and died. (Well, actually all it did was hang on receiving mail from the clogged mailbox... the rest of it was working just fine.) The point being that I had to force-quit it, which meant that the mailbox indexes were all screwed up, and also meant that when I re-started it, it started downloading all of them *again.* I went through a number of these cycles, and now there are approximately 154 emails I can't delete. None of the regular maintenance procedures work; I move them to the trash, empty the trash, and then they reappear.

    ZOMBIE EMAILS.

    I'm going to have to poke through about 300 individual email files (.emlx files in ~/Library/Mail/POP-myaccount/INBOX.mbox/Messages/) to determine which are worthwhile and which are not. If I were super shell scripter, this would be no problem.

    Solution: OK, maybe I don't need to sift through them, exactly. It turns out that if you open these orphaned mails in Mail.app, then Mail.app does the right thing. And then you can delete them. Of course, that means you're staring at this for a while:

    spamscreen

    Mail.app doesn't follow the decades-old Mac convention of command-option-W closing all windows, so I just hit the delete key 154 times.

Comments (7)

  • i love the tag "i am a nerd".

  • Le nerd, c'est moi!

  • oh tish is that french?!

    [kisses your whole dang arm in slightly creepy but sweet way]

  • Could you explain the +mx rule a bit more? What exactly do you mean by "any server in the DNS record"?

  • heeeeey you themed your site!

  • I sort of themed my site. The private page is still unthemed, which seems kind of silly.

    A given DNS record has an MX (mail exchange) field, so MTAs can look it up and find out what mail server to look for. The SPF mx rule says that if the mail comes from that server then it's cool.

    I'm just kind of miffed that I went to the trouble to learn what MX and MTA and all that stuff means, and then gmail lets the forged mail through anyway.

  • yeah, the un-themed private page is sort of a drag.. but they're working on it :)

Comments are closed.

Post a Comment