The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Thursday, June 03, 2004

Still more lack of time management

Sigh.

It's Thursday! Not Wednesday.

I hope this isn't a recurring theme in my life …


Some anti-spam ideas

SPF was originally designed to prevent joe-jobs. In this mode, an MTA uses SPF to verify the envelope sender (SMTP MAIL FROM) address during SMTP time. But some people pointed out that SPF can also be used to verify headers to prevent phishing. When used to verify headers, the agent could be an MTA or an MUA, and slightly different rules apply: you have to consider Sender and Resent-From as well as just the “From:” header. Header verification is one of the central themes of the May 2004 merger between SPF and Microsoft CallerID For Email.

SMTP+SPF: Sender Policy Framework

The other day Mark sent me email pointing me to the SPF site. Interesting idea, and one I've come across before and thought about, but didn't think it had enough of a following to warrant doing (although, given the contents of the DNS zone files I have, it's odd that I haven't adopted this yet). But seeing how Microsoft has jumped on board …

Oddly enough, while reading an article about antispam measures I had a sudden brainstorm about a way to make it more difficult for spammers to send mail out. It's a combination of two methods, one in current use, and one that just popped into my head.

The first method is to allow only email from designated MX hosts. That's currently being done, and is a method that SPF was designed to help facilitate. The upshot of this is that a spammer can't just slap a machine on the Internet and spam from that—no, it has to come through a machine that is designated, via DNS, as an MX host. But there are two ways around that: going through the ISPs SMTP server (which the ISP monitors and they are usually aware of heavy use and can cut off the offending customer) and by registering a domain and setting the IP address they get as an MX for that domain.

And it's the second idea that counters that problem. Each DNS record has a “time-to-live” value—how long that record is considered “valid.” Simply reject any connection from an MX host who's MX record's time-to-live is less than, say, a week (actually, I would check all MX records and reject it if any are less than a week).

If I get spam from a domain, one quick check of the MX records and I can stop receiving spam from that domain for a week. Not much in the scope of things, but easily doable and scriptable even. But enough servers do that, and the spammer has to wait a week to send email. It's not enough to change IP addresses—that's easy enough. But the MX records have to change and propagation takes at least a week …

One way around that is to register as many MX records for a given domain as possible, but if you also dump the connection if there are more than say, a dozen MX records (AOL gets by with 4, so does MSN; IBM on the other hand, uses 11). Another way is to register a whole bunch of domains. Possible, but that does tend to cut into the profits a bit …

And really, that's the only way to make spam go away, but making it too expensive to send.

Update later today

Well, I went through some of my email today, applying the rules mentioned above to them, and while all the spam emails would have been stopped, I also recieved two false positives—one from a mailing list I'm on, and one for the guy I work for.

Looks like there are still some issues to work out here …

Obligatory Picture

Trying to get into the festive mood this year

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

Obligatory AI Disclaimer

No AI was used in the making of this site, unless otherwise noted.

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site: https://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

https://boston.conman.org/2000/08/01

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.