I should have noted this Outlook tip with the fixed font one earlier:
What are “extra line breaks” anyway? Removing them does bad things to code.
One less Outlook annoyance: How to show fixed font for plain text
Why is this not the default…
Given that I’ve successfully avoided spam by using me at example dot com as an “obfuscation” method for email addresses, I’m not surprised by the findings that spammers are lazy. But it is still interesting to read about good proof through a real test, and I’d hazard a guess that using hex entities may be a longer-lasting method.
I’d consider replacing the JavaScript I currently use, if it weren’t for the fact that people already seem to be able to find my email address just fine. Actually, Phil’s article would seem to support the case that disabling JavaScript is rare. He only got a couple of actual messages to the non-JavaScript address. I guess that’s good news for me.
Half a year ago I mentioned greylisting as an option to fight spam. A few months ago NetBSD.org enabled greylisting and it made a huge difference in the amount of spam and viruses being forwarded to me. Now I finally got around to deploying postgrey on the Global Wire mail infrastructure.
Greylisting is so simple that it seems strange that it is as effective as it is. I’m certainly going to enjoy it as long as it keeps working. Unfortunately I don’t expect that to be more than a year…
For implementations of greylisting on different platforms, have a look at greylisting.org.
I’m often way behind on my personal email, and many messages can go completely unanswered. When I get home from work in the evenings, I’m just not “in the mood” for writing email: there are all sorts of household chores that need to be taken care of, or I’ve just arrived home so late there is nothing else to do but sleep.
I’ve thought about portable before, but haven’t come up with any solutions yet that I could implement right away without having some concerns on feasibility in the long term. (more…)
Last night I upgraded the mail transport software to Postfix 2.1.1 and added a couple of new filtering rules from Jim Seymour’s list of ideas.
I now require that mail with freemail sender addresses arrive from freemail peer addresses (e.g. mail from “foo@yahoo.com” is only accepted from a *.yahoo.com peer). This has already blocked lots of mail from e.g. *.netikka.fi and *.surfer.at from machines that HELO with things like “msn.com” and use *@yahoo.com sender addresses.
I also added a check for bad MX records. I’m now blocking domains with MX records pointing to any private or reserved networks (i.e. that cannot be used for public connectivity):
0.0.0.0/8 REJECT Domain MX in broadcast network 10.0.0.0/8 REJECT Domain MX in RFC-1918 private network 127.0.0.0/8 REJECT Domain MX in loopback network 169.254.0.0/16 REJECT Domain MX in link local network 172.16.0.0/12 REJECT Domain MX in RFC-1918 private network 192.0.2.0/24 REJECT Domain MX in TEST-NET network 192.168.0.0/16 REJECT Domain MX in RFC-1918 private network 224.0.0.0/4 REJECT Domain MX in class D multicast network 240.0.0.0/5 REJECT Domain MX in class E reserved network 248.0.0.0/5 REJECT Domain MX in IANA reserved network
I thought I’d see results from this rule right away, but nothing yet…
Update (6/4/2004): It looks like not that many spammers are using “bad” IP’s for their MX hosts. However, there are a few hits, and this prevents unnecessary bounces to the local postmaster, so I’m certainly keeping these rules.
I’ve been looking at new spam prevention options with Postfix 2.1.1 and one of the most interesting features is SMTP Access Policy Delegation or “the policy daemon.” It seems an excellent framework — instead of having to constantly modify the MTA you can just hook up another external policy server. Current implementations of policy servers include greylisting and support for SPF.
While reading about SPF I decided to go ahead and add SPF records for a number of domains I run. I could do this because I’m not a travelling salesman and the domains I selected don’t have users that would suffer from the forwarding problem.
In general, though, it seems a bit tricky to define working SPF records for any complex domains with remote or mobile users. Maybe in a couple of years when everyone has an IMAP server with SSL or TLS support, and all MTA’s have SRS support…
The first revision of my Postfix configuration files was committed in RCS on February 19, 2001. By March 25th I had implemented a patch to allow me to use Postfix even on the central mail server. The patch allowed disabling canonical rewriting for the SMTP envelope recipient.
Traditionally the GW systems have supported the use of external mail redirection services (e.g. IKI ry and Pobox), and I did not want to discontinue this just because I switched the MTA. I think it is great that we can have mail headers correctly reflect the preferred mail address for all of our users, regardless how the mail enters our system. This is really just a “per-user configurable masquerading” of addresses. Doing it in the MTA avoids the need to modify all software to support configurable mail addresses (and the need to separately configure the address all over the place).
However, maintaining a private patch can take quite a bit of time, so I submitted my patch for inclusion in the official Postfix distribution. Unfortunately Wietse rejected it, but he encouraged me to model it after the masquerading classes. I’m hoping he will accept the new patch. I must admit, this approach is much nicer, allowing canonical maps to be enabled or disabled for any of envelope sender, envelope recipient, sender headers or recipient headers individually.
But I need to wait a couple of weeks to make sure the new implementation works without problems in production first. Brave souls out there can download the patch and try it out. Please let me know if you are using this feature, and how it works for you.
Provided that no problems surface, this feature should be part of the Postfix package in pkgsrc as well as in the NetBSD base system as they are upgraded to Postfix 2.1.1 or later.