Dealing with backscatter, revisited

Back in January, I wrote about how I deal with email backscatter nowadays. Since then, I’ve made a notable tweak.

This is that I no longer reject “null-sender” traffic during the SMTP transaction. It turned out that it broke Exim’s implementation of Sender Address Verification, which performs the SAV check using a MAIL FROM of <>, rendering it indistinguishable from a bounce during the SMTP transaction.

Now, I’ve complained about SAV, but I have to be pragmatic anyway (Postel’s law and all that!) — so it was better to just allow other sites to perform SAV lookups against our server, and fix the anti-bounce stuff some other way.

The new method (below) does this, by allowing null-sender SMTP traffic just fine; it detects bounces in Postfix if they arrive via SMTP in RFC-3464 format, and bounces that slip past are then dealt with in a more CPU-intensive manner using the SpamAssassin “VBounce” ruleset (which is part of the now-released SpamAssassin 3.2.0, btw).

This increases the load, since some bounces cannot be rejected at MAIL FROM time now, and instead we have to wait ’til DATA — but CPU hasn’t been a problem recently, so this is ok.

Here are the updated instructions:

In Postfix

In my Postfix configuration, on the machine that acts as MX for my domains – edit ‘/etc/postfix/header_checks’, and add these lines:

/^Content-Type: multipart\/report; report-type=delivery-status\;/  REJECT no third-party DSNs
/^Content-Type: message\/delivery-status; /     REJECT no third-party DSNs

Edit ‘/etc/postfix/main.cf’, and ensure it contains:

header_checks = regexp:/etc/postfix/header_checks

Then run:

sudo /etc/init.d/postfix restart

This catches most of the bounces — RFC-3464-format Delivery-Status-Notification messages from other mail servers.

In SpamAssassin

As before, install the Virus-bounce ruleset and set it up. This will catch challenge-response mails, “out of office” noise, “virus scanner detected blah” crap, and bounce mails generated by really broken groupware MTAs — the stuff that gets past the Postfix front-line.

Tags: , , , , , , , ,

Comments (4)

How to deal with joe-jobs and massive bounce storms

As I’ve noted before, we still have a major problem with sites generating bounce/backscatter storms in response to forged mail — whether deliberately targeted, as a “Joe-Job”, or as a side-effect attempts to evade over-simplistic sender address verification as seen in spam, viruses, and so on.

Sites sending these bounces have a broken mail configuration, but there are thousands remaining out there — it’s very hard to fix an old mail setup to avoid this issue. As a result, even if your mail server is set up correctly and can handle the incoming spam load just fine, a single spam run sent to other people can amplify the volume of response bounces in a Smurf-attack-style volume multiplication, acting as a denial of service. I’ve regularly had serious load problems and backlogs on my MX, due solely to these bounces.

However, I think I’ve now solved it, with only a little loss of functionality. Here’s how I did it, using Postfix and SpamAssassin.

(UPDATE: if you use the algorithm described below, you’ll block mail from people using Sender Address Verification! Use this updated version instead.)

Firstly, note that if you adopt this, you will lose functionality. Third party sites will not be able to generate bounces which are sent back to senders via your MX — except during the SMTP transaction.

However, if a message delivery attempt is run from your MX, and it is bounced by the host during that SMTP transaction, this bounce message will still be preserved. This is good, since this is basically the only bounce scenario that can be recommended, or expected to work, in modern SMTP.

Also, a small subset of third-party bounce messages will still get past, and be delivered — the ones that are not in the RFC-3464 bounce format generated by modern MTAs, but that include your outbound relays in the quoted header. The idea here is that “good bounces”, such as messages from mailing lists warning that your mails were moderated, will still be safe.

OK, the details:

In Postfix

Ideally, we could do this entirely outside Postfix — but in my experience, the volume (amplified by the Smurf attack effects) is such that these need to be rejected as soon as possible, during the SMTP transaction.

Update: I’ve now changed this technique: see this blog post for the current details, and skip this section entirely!

(If you’re curious, though, here’s what I used to recommend:)

In my Postfix configuration, on the machine that acts as MX for my domains – edit ‘/etc/postfix/header_checks’, and add these lines:
/^Return-Path: <>/                              REJECT no third-party DSNs
/^From:.*MAILER-DAEMON/                         REJECT no third-party DSNs
Edit ‘/etc/postfix/null_sender’, and add:
<>              550 no third-party DSNs
Edit ‘/etc/postfix/main.cf’, and ensure it contains these lines:
header_checks = regexp:/etc/postfix/header_checks
smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/null_sender
(If you already have an ’smtpd_sender_restrictions’ line, just add ‘check_sender_access hash:/etc/postfix/null_sender’ to the end.) Finally, run:
sudo postmap /etc/postfix/null_sender
sudo /etc/init.d/postfix restart
This catches most of the bounces — RFC-3464-format Delivery-Status-Notification messages from other mail servers.

In SpamAssassin

Install the Virus-bounce ruleset. This will catch challenge-response mails, “out of office” noise, “virus scanner detected blah” crap, and bounce mails generated by really broken groupware MTAs — the stuff that gets past the Postfix front-line.

Once you’ve done these two things, that deals with almost all the forged-bounce load, at what I think is a reasonable cost. Comments welcome…

Tags: , , , , , , , ,

Comments (15)

Automatically Invoking screen(1) on Remote Logins

If you routinely log into one or more remote systems using SSH, and have a flaky internet connection or an incompetent ISP, you probably already know about screen’s ability to detach and reattach sessions.

However, you still have to manually type screen -r to resume a detached session, each time — and sometimes you’ll forget, start working in an SSH session, get logged out, and lose your state.

Here’s the next step — automatic screen-sessions for any remote logins: RemoteLoginAutoScreen.

Tags: , , , , ,

Comments (14)

HOWTO: invalidate a patent application with prior art

Patents: here’s an interesting technique I heard recently. (credit: I’m not sure who told me about it, but I think it may have come from or via John Levine.)

If you become aware of a patent application (note: not an issued patent!) for which you are aware of possible prior art, you may be able to help invalidate it, or at least ensure any resulting patent is narrow enough to be relatively sane. Here’s how.

  • If you have knowledge of techniques that you believe may be prior art, you can send them on to the filers or the patent examiner. At this stage, the onus is on them to prove that the technique is not prior art for the application (once it’s granted, the onus would be on you to prove that it is).
  • The filer also must indicate techniques that they are aware of, that may be prior art, during filing; so CC’ing a public forum with a copy of whatever you send to them, may at some point in the future help indicate that they did not do this.

Of course, you have to go find the patent application number, the contact addresses of the filers, and the contact address for the patent examiner to do this ;) But it beats posting a whinge to Slashdot.

An unnamed patent agent comments:

‘I believe an examiner is not under obligation to review art sent directly to them, but certainly the applicant and his agents are required to report any art they come across. That means the inventor as well as the law firm representing them.

You should include a cover letter that you saw their application (give details), and that you believe that what you are sending them is prior art, and that now that they have it, they are obligated to report it to the PTO. The same can be done to their counsel.

Probably, anything sent should be sent with some sort of delivery confirmation, and to make sure that the sending of the prior art is of public record, create a Web site where all sent art is listed, along with destination and confirmation information. This would help show inequitable conduct should the patent later be asserted and the art you provided not be shown as of record in the examination.

Mind you - I have not heard of these being done before (bombarding listed inventors and their agents with prior art, forcing them to have to disclose it), but I think it’s a great idea. One caution - if you send too much, you over inundate the examiner, and then really good art could get overlooked during examination.

Separately, please keep in mind that the claims in a published application have probably not yet even been seen by the examiner at the PTO. These are the claims that the applicant would love to have the examiner accept, but until prosecution of the application actually commences (and completes), there’s no way to know what claims will ultimately result.’

Update: some good additional points:

‘The prior art must have been published or been publicly available at least as early as the earliest priority date of the patent. The priority date is either the filing date, or the filing date of a parent application. This information can be found on the cover page of a patent.

A patent’s scope is covered by the claims. The claims define what the invention is. All other material in the patent is supporting material, and usually non-binding. In order to be anticipatory (the best kind) prior art for a particular claim, the piece of art must contain or described every element of the claim you are seeking to invalidate. Note that dependent claims add additional elements that the prior art needs to contain if you want to invalidate the dependent claims as well.

Prior art which is not anticipatory may be used in combination with other art or knowledge at the time to show obviousness. This type of art may have some impact during prosecution of a patent, but if a patent has already been issued, obviousness is a real uphill battle to fight in the courts. Few patents have been invalidated because of obviousness in trials.’

Another attorney notes: ‘You can actually send it anonymously if you want. Just keep the certified receipt to prove they got it. As long as they know it exists, the onus is on them to disclose it to the PTO.’

‘It’s best to send them something printed out or on tangible media, along with a brief note explaining what it is and most importantly, when it was first publicly available. Certified means using certified mail or FedEx or something where you have a valid receipt.

As far as (discovering) who the (filer’s patent lawyers) are … it’s usually listed on the patent applications. you can search the USPTO website for them.’

And a report that this technique is now in use: ’some patent attorneys are reporting that this approach is a valid one that people have started using.’

Update 2: More assent from another unnamed patent lawyer:

‘Anyone who wishes to do so can send a letter to the Patent Office letting them know of any prior art of which they are aware. The Patent Office will then place it in the application file. Anyone who cares about this patent will surely order up a copy of the application file from the Patent Office, and will come into possession of whatever you sent.

Later you can see whatever you sent them. Go to
http://portal.uspto.gov/external/portal/pair and plug in the serial number (for the desired patent). Click on “image file wrapper”.’

It’s the right thing to do for any patent or patent application.’

Tags: , , , , , ,

Comments (2)

(Untitled)

Due to a set of advocacy and plain show-off mails recently, regarding sub-pixel font rendering under Linux, my hand has been forced ;)

As a result, here’s a little HOWTO document I’ve written up for getting sub-pixel rendering working under Linux. Check it out if you’ve got a Linux laptop and want some sweet-looking fonts!

Tags: , , , , , , , , ,

Comments