New hijacking - Done via via good old-fashioned Identity Theft

Mailman List Mirror (Read Only)
1

[[ Note: There are three more apparently hijacked blocks that are related
   to the 75 specific blocks I am reporting on herein. I'll be reporting
   on those other three blocks later on, but right now I just want to keep
   it simple and report on just the ones relating to directnet.net. ]]

So anyway, presented below, as Rod Serling would have said, "... for your
approval..." you will find a collection of 75 separate IP blocks, all of
which appear to have been hijacked in one big gulp.

One /21, plus seventy four /24s.

This case was done, quite neatly, the good old fashioned way.... apparently
by trivial identity theft. (And I should say that no fault whatsoever
accrues in any way to ARIN in this case. They were not even involved in
the slightest, since all of the relevant WHOIS records have remained utterly
unchanged throughout this entire hijacking.)

The identity theft:

A company that was responsible for one /21 block and 74 separate /24
blocks (all of the latter of which had been originally allocated for
various U.S. elementary schools, middle schools, and high schools)
apparently went out of business. In due time, the company's domain
name (directnet.net) came up for sale. It was purchased for $4,000,
sometime between May 31, 2010 and June 13, 2010:

     http://www.dnjournal.com/archive/domainsales/2010/20100623.htm

Subsequently, the domain name was transferred to an anonymizing
registrar in the Cayman Islands. Sometime before or after that
purchase, whoever had purchased the directnet.net domain convinced
the fine folks at Reliance Globalcom Services, Inc., (AS6517) to
announce routes to 100% of this rather cleverly hijacked IP space.
(See complete IP block list attached below.)

Sometime after that, the IP blocks in question began to fill up with
snowshoe name servers and snowshoe spam domains.

The entire set of relevant ARIN WHOIS records for the hijacked IP blocks,
along with the new WHOIS record for the newly re-registered directnet.net
domain, and also a listing of the snowshoe domains and name servers that
have been created in, or moved into these hijacked IP blocks are all
avaliable here:

     http://www.47-usc-230c2.org/hijacked-schools/

Although it is impossible to be absolutely certain who engineered this
clever hijacking, some of the evidence available to me at this time
suggests that a particular company listed on Spamhaus' ROKSO list may
possibly have either either had a hand in engineeering the hijacking, or
else may possibly have benefitted from it, after the fact, i.e. obtaining
IP space which they could then sub-lease to their space-hungry customers.

Certainly, fine folks at Reliance Globalcom Services, Inc. could tell
us who is paying them to connect these hijacked blocks to their network,
but I rather doubt that they are actually going to come clean and do
that.

Regards,
rfg

Hijacked blocks:

204.194.184.0/21
205.196.1.0/24
205.196.14.0/24
205.196.28.0/24
205.196.29.0/24
205.196.30.0/24
205.196.31.0/24
205.196.32.0/24
205.196.33.0/24
205.196.34.0/24
205.196.35.0/24
205.196.36.0/24
205.196.37.0/24
205.196.38.0/24
205.196.40.0/24
205.196.41.0/24
205.196.42.0/24
205.196.43.0/24
205.196.44.0/24
205.196.45.0/24
205.196.46.0/24
205.196.47.0/24
205.196.49.0/24
205.196.51.0/24
205.196.52.0/24
205.196.53.0/24
205.196.54.0/24
205.196.55.0/24
205.196.56.0/24
205.196.57.0/24
205.196.58.0/24
205.196.59.0/24
205.196.60.0/24
205.196.61.0/24
205.196.62.0/24
205.196.67.0/24
205.196.68.0/24
205.196.69.0/24
205.196.71.0/24
205.196.72.0/24
205.196.73.0/24
205.196.75.0/24
205.196.76.0/24
205.196.96.0/24
205.196.97.0/24
205.196.99.0/24
205.196.100.0/24
205.196.101.0/24
205.196.102.0/24
205.196.103.0/24
205.196.104.0/24
205.196.105.0/24
205.196.106.0/24
205.196.107.0/24
205.196.108.0/24
205.196.109.0/24
205.196.111.0/24
205.196.112.0/24
205.196.113.0/24
205.196.114.0/24
205.196.115.0/24
205.196.116.0/24
205.196.161.0/24
205.196.162.0/24
205.196.163.0/24
205.196.164.0/24
205.196.165.0/24
205.196.192.0/24
205.196.193.0/24
205.196.194.0/24
205.196.196.0/24
205.196.197.0/24
205.196.198.0/24
205.196.199.0/24
205.196.200.0/24

2

Certainly, fine folks at Reliance Globalcom Services, Inc. could tell
us who is paying them to connect these hijacked blocks to their network,
but I rather doubt that they are actually going to come clean and do
that.

Ron, I haven't been following this anti-spam stuff much since it went
political with ARIN but I do have a few quick questions (relating to
US law and spam).

1) Is spamming from within the US criminal activity? What constitutes
spam in that case?
2) If you could justify the incoming spam as a DOS, is that criminal
activity? Could you justify it as a DOS?
3) Is providing ARIN with bogus information just to get around their
processes criminal activity?
4) Is obtaining disused IP space / AS allocations from assigned
entity, and not updating ARIN criminal activity?
5) Is advertising Prefixes or AS number assigned to another entity
criminal activity?

6) If any of the above could be classed as criminal activity, are
Reliance Globalcom (in this case) legally obligated to cut them off?,
or just help by switching on a packet capture (new law coming into
effect i think??)

Cheers
Heath

3

so ... should domains associated with asn(s) and addr block allocations be subject to some expiry policy other than "it goes into the drop pool and one of {enom,pool,...} acquire it (and the associated non-traffic assets) for any interested party at $50 per /24"?

Eric

4

Interesting idea, but how do you apply it to ccTLD domains with widely
varying policies. All it takes is whois records being legitimately
updated to use domain contacts using a ccTLD domain to circumvent.
Sounds like more of a stop-gap measure.

Regards,
Ben

5

Number resources are not and should not be associated with domain
resources at the policy level. This would make absolutely no sense
whatsoever.

Owen

6

hmm. ... "are not" ... so the event complained of ... didn't happen?

7

In message <AANLkTi=rH=kXm6ksK1gkyfu=nh4oazW=c+66Meo5HL+H@mail.gmail.com>,

Certainly, fine folks at Reliance Globalcom Services, Inc. could tell
us who is paying them to connect these hijacked blocks to their network,
but I rather doubt that they are actually going to come clean and do
that.

Ron, I haven't been following this anti-spam stuff much since it went
political with ARIN but I do have a few quick questions (relating to
US law and spam).

1) Is spamming from within the US criminal activity?

Sadly, it appears not.

In many cases it is however actionable. (And in other cases involving
actual criminal activity, e.g. as prohibited by 18 USC 1030, `Fraud and
related activity in connection with computers', it may, I think, be
considered as an aggravating factor in determining punishments.)

What constitutes spam in that case?

Are you asking what I think? Or what the majority of netizens think?
Or are you asking what U.S. courts think?

Those are three different answers.

2) If you could justify the incoming spam as a DOS, is that criminal
activity? Could you justify it as a DOS?

Yes. No.

3) Is providing ARIN with bogus information just to get around their
processes criminal activity?

In this case, nobody provided ARIN with *any* bogus information, ever.
(So your question is utterly irrelevant to this particular case.)

4) Is obtaining disused IP space / AS allocations from assigned
entity, and not updating ARIN criminal activity?

In this particular case, nobody appears to have ``obtained'' IP space
from the various High Schools, Middle Schools, and Elementary schools
involved, other than via deceit, trickery, and fraud. Were the various
schools involved here ripped off? I would say yes. Does the fraud in
this case rise to the level of being either criminal or actionable?
I am not a lawyer, but my guess is that the answer is probably yes to
both... *IF* anybody cared enough to persue it. I base that opinion
stictly and only on the definition of the English language word `fraud'
as given at www.merriam-webster.com.

As regards to updating ARIN, or the lack thereof, the _absence_ of such
``updating'', in this case... i.e. the absence of any notice to ARIN
that these blocks were being glomed onto... is part of the overall
pattern of fraud in this case which, as I have said, I believe to be
potentially both criminal and actionable... if anybody cared enough to
persue it.

But that's just my opinion, and I am not a lawyer.

5) Is advertising Prefixes or AS number assigned to another entity
criminal activity?

If it constitutes criminal fraud which deprives some party of some property,
or some right, or the full enjoyment of some property or some right, to which
they are otherwise entitled, under law, then yes, although I am not a
lawyer, my limited understanding of the law in these United States indicates
to me that yes, most probably such activity may well be considered criminal,
in at least some circumstances, perhaps including the ones being discussed
in this thread.

6) If any of the above could be classed as criminal activity, are
Reliance Globalcom (in this case) legally obligated to cut them off?,

The answer to that depends, I think, upon whether they are _knowing_
participants in the fraud. If they merely got duped... which is indeed
what is suggested by that fact that somebody paid $4,000 to get a specific
domain name so that they could then dupe _somebody_ (where that somebody
who was to be duped, in this case was clearly _not_ ARIN)... then in
that case, Reliance Globalcom is just another one of the victims, and not
one of the perpetrators.

Hypothetically, if, once they have been duly informed that this particular
fraud is ongoing, they do nothing, and continue announcing the routes even
after allowing them a reasonable amount of time to properly investigate what
is going on here, then at that point I think that yes, then they might in
fact be criminally liable, civilly liable, or both.

or just help by switching on a packet capture

What would be the point of that??

I can already tell you what the blocks in question are most probably being
used for, and have done so already, I think.

Regards,
rfg

9

1) Is spamming from within the US criminal activity?

Sadly, it appears not.

In many cases it is however actionable. (And in other cases involving
actual criminal activity, e.g. as prohibited by 18 USC 1030, `Fraud and
related activity in connection with computers', it may, I think, be
considered as an aggravating factor in determining punishments.)

Wouldn't it have to be illegal before punishments could be determined?
Isn't this kind of key to the whole issue of fighting spam?? (Is there
even a point if you cant nail them for it?)

What constitutes spam in that case?

Are you asking what I think? Or what the majority of netizens think?
Or are you asking what U.S. courts think?

Those are three different answers.

With regards to US court.

2) If you could justify the incoming spam as a DOS, is that criminal
activity? Could you justify it as a DOS?

Yes. No.

Ok.

3) Is providing ARIN with bogus information just to get around their
processes criminal activity?

In this case, nobody provided ARIN with *any* bogus information, ever.
(So your question is utterly irrelevant to this particular case.)

Not at all irrelevant, I'm talking generically here (not specific to
this case). Trying to cover all bases.

4) Is obtaining disused IP space / AS allocations from assigned
entity, and not updating ARIN criminal activity?

In this particular case, nobody appears to have ``obtained'' IP space
from the various High Schools, Middle Schools, and Elementary schools
involved, other than via deceit, trickery, and fraud. Were the various
schools involved here ripped off? I would say yes. Does the fraud in
this case rise to the level of being either criminal or actionable?
I am not a lawyer, but my guess is that the answer is probably yes to
both... *IF* anybody cared enough to persue it. I base that opinion
stictly and only on the definition of the English language word `fraud'
as given at www.merriam-webster.com.

As regards to updating ARIN, or the lack thereof, the _absence_ of such
``updating'', in this case... i.e. the absence of any notice to ARIN
that these blocks were being glomed onto... is part of the overall
pattern of fraud in this case which, as I have said, I believe to be
potentially both criminal and actionable... if anybody cared enough to
persue it.

But that's just my opinion, and I am not a lawyer.

Perhaps there is a method of class action, as opposed to individual
companies trying to sue?

5) Is advertising Prefixes or AS number assigned to another entity
criminal activity?

If it constitutes criminal fraud which deprives some party of some property,
or some right, or the full enjoyment of some property or some right, to which
they are otherwise entitled, under law, then yes, although I am not a
lawyer, my limited understanding of the law in these United States indicates
to me that yes, most probably such activity may well be considered criminal,
in at least some circumstances, perhaps including the ones being discussed
in this thread.

Well that might possibly be a start of a legal avenue..?

6) If any of the above could be classed as criminal activity, are
Reliance Globalcom (in this case) legally obligated to cut them off?,

The answer to that depends, I think, upon whether they are _knowing_
participants in the fraud. If they merely got duped... which is indeed
what is suggested by that fact that somebody paid $4,000 to get a specific
domain name so that they could then dupe _somebody_ (where that somebody
who was to be duped, in this case was clearly _not_ ARIN)... then in
that case, Reliance Globalcom is just another one of the victims, and not
one of the perpetrators.

Hypothetically, if, once they have been duly informed that this particular
fraud is ongoing, they do nothing, and continue announcing the routes even
after allowing them a reasonable amount of time to properly investigate what
is going on here, then at that point I think that yes, then they might in
fact be criminally liable, civilly liable, or both.

Might be worth pointing that out to them? Most companies don't like risk..

or just help by switching on a packet capture

What would be the point of that??

I can already tell you what the blocks in question are most probably being
used for, and have done so already, I think.

I was referring to new legislation coming into effect that gives the
FBI? the power to say 'flick the switch on now' and they then can log
traffic..

All in all, it just seems pretty pointless trying to fight spam if the
law isnt backing you. Filtering yes, fighting no.. Perhaps the law is
what needs to be worked on? (As a general comment to all)

Cheers
Heath

10

This conversation isn't really about spam. It is about being able to
obtain the number resources of a defunct organization by masquerading as
that organization by registering an identical business entity or
operating name. So foo.com has legitimately obtained number resources.
Foo.com goes broke and those resources are no longer in use. Joe Blow
registers an operation he calls foo.com and claims the right to use
those number resources. I don't care if those resources are being used
for spam or giving away free money to the needy, that is beside the
point. The issue as I see it is to raise awareness that just because
foo.com wants to announce resources and just because that WHOIS says
those resources belong to foo.com, it doesn't mean that the two are the
same foo.com

Having an organization come to you wanting to announce a /18 of network
space (that was allocated 10 years ago) and their domain was only
created a week ago might be a clue.

G

11

The key issue here is more the "should not" aspect, which I agree with,
but that these records are frequently used by netops to verify a
request. There really needs to be a greater standardised level of due
diligence regarding advertisement requests that checks more than whether
a request is coming from a seemingly legitimate email address.

Regards,
Ben

12

I'd like to see the I-D which explains how this is going to work,
with particular attention to (a) how the passwords will be exchanged
without using email (b) how it's going to handle the O(N^2) scaling and
(c) how it's going to work in an environment with at least a hundred
million compromised systems -- that is, systems that are now owned by
the enemy, who thus also owns the contents of all the address books
stored on them...including all the passwords. I think once these
issues are addressed it will be only a small matter of implementation
to convince everyone to swiftly move to a different protocol for mail.

---rsk

13

we have run a simular system for a while, the problem is still with mailinglists and online shops

(by lack of a standardised field the password was put anywhere in the email, all email not containing a password was rejected with a message to call sales)

a) you print unique passwords on each businesscard, and simply give them to your clients through other means (sales telephone number, etc)

b) there is no O(N^2) scaling. you currently have an email address, and maybe a name for everyone you want to email in your address book, or your database, all thats required is another field with the password they gave you.

c) totally fine, with us, it stopped 100% of all undesired email (normally 1500 a day just for me alone :wink:

If what you're asking under point c is "what happens if a system that contains such a password for your email address gets compromised" the answer is simple, you remove that specific password from your approved passwords list (note that on the receiver side, the password is not linked to the source email address, senders can use any source email address they want, as long as one of the currently active/accepted passwords is in the email)

remaining problems with this system are:
by lack of a standard header for Password: which should be supported by all clients, address books, online shops, mailinglists, we put the password in the email, which means, that on Cc:'s and forwards etc
the password got forwarded along with the email, potentially giving other people the password too.

Now, this is -100%- spam stopping, smtp can be as open relay and you want, the internet can be full of compromised windows boxes chunking out tons of crap, but you won't get any spam, just mail from people YOU choose to deal with, by actively -giving- them a password yourself, which you can also -revoke-.

(the initial contact, the equivalent of "accept contact" in skype simply needs to be done through other channels, but really, people that don't know
you have no business mailing you anyway :wink:

We have been watching these so-called "spam fighters" for a while now, and all they managed to do over the past 20 years or so is completely fuck up the smtp protocol itself, first they fucked up the concept of open relays, then it was stupid and unnessesary delays (graylisting), then there were
all kinds of blacklists run by arrogant fools that gladly blacklisted all
of level 3 because of one spammer, etc, and you still got spammed, and still get spammed today.

If i have to wait for 20 minutes for an email, i've started skype already.. You know what, why don't we simply turn the smtp servers -off-
and use skype and msn for everything... saves electricity :stuck_out_tongue:

It may be a bit too late to fix the protocol itself to be real-time and peer-to-peer again, but this time without spam ofcourse, as the market has been flooded with better protocols already anyway (the problem with these however is that they're propriatory and vendor dependant).

14

If what you're asking under point c is "what happens if a system that
contains such a password for your email address gets compromised" the
answer is simple, you remove that specific password from your approved
passwords list

140 million or so compromised systems. You may be spending a lot of time
removing compromised passwords from your list - and even more problematic,
notifying everybody of the *new* password(s) they should use to e-mail to you.
So far this month, I've seen 4,964 mails from 1,090 different From: lines
(mostly due to a subscription to the linux-kernel list, which is a true fire
hose), and some 250 different SMTP MAIL FROM: sources.

                         (note that on the receiver side, the password is not linked
to the source email address, senders can use any source email address they
want, as long as one of the currently active/accepted passwords is in the
email)

We'll overlook the fact that if the password isn't linked to the source
address, then *any* sender can use any source they want, as long as as it's
known that *some* sender used '97%-chicken-teriyaki' as a password. And with
140 million compromised boxes, there's a basically never-ending supply of
credentials to be stolen and used.

remaining problems with this system are:
by lack of a standard header for Password: which should be supported by
all clients, address books, online shops, mailinglists, we put the
password in the email, which means, that on Cc:'s and forwards etc
the password got forwarded along with the email, potentially giving other
people the password too.

And you recognize that your scheme leaks said passwords, but that's not a fatal
problem.

Now, this is -100%- spam stopping, smtp can be as open relay and you want,
the internet can be full of compromised windows boxes chunking out tons of
crap, but you won't get any spam, just mail from people YOU choose to deal
with, by actively -giving- them a password yourself, which you can also
-revoke-.

So explain to me in *detail* - you're in the To: line of this mail. I don't
believe I've sent to you in the past. I acquire a password valid to send you
this e-mail, how, exactly? After all, I can't e-mail you and ask for one...

After that, explain how a Hotmail user migrates to GMail (or vice versa) and
retains their ability to contact everybody they used to contact.

You might want to look at this:

http://www.rhyolite.com/anti-spam/you-might-be.html

and see how many of the entries in the list apply to your proposal. (Nothing
personal - I don't think *any* realistic anti-spam proposal can get much
traction unless they've at least *thought* about every single bullet point on
that list).

Further discussion is probably best on SPAM-L.

15

you just give contacts for the passwords with which you have received a new one.

each potential person that can send email to your email address, gets a unique password from you.

sending person/maillist 1 gets password abcdefg to send to bla@example.com (no matter from which email address)

sending person/maillist 2 gets password 123545 to send to bla@example.com (no matter from which email address)

email clients should be modified to include the password: field both in the email itself and in the header entry field (to: from: subjecT: or just store them together with the destination address in the address book

mailservers (the maildrop part) should be modified to parse the Password: header, compare it to the list of currently allowed passwords for the destination email address and then either drop to the mailbox, or bounce. (we did this in our test setup by simply parsing the entire email, so the password could be -anywhere- in the email :stuck_out_tongue:

ofcourse the Password: line should be only sent to the recipient, not to other Cc: or Bcc: target addresses of the same email, the first stmp server in the chain should solve this bit.

actually, durign our tests, we turned off all the header verifications, RBL's, etc on our smtpds, and the only spam that got through were emails that accidentially contained the password string in a binary attachment (as we parsed the entire email .. we should not do that, just teh Password: line in the final version :stuck_out_tongue: and stuff where we gave, for example, nanog, the password "nanog" and then nanog is cc'ed in a spam
both of which cases can be solved with the standardization of the Password: field

once this is in place, all smtpds can go open relay again, port 25 can be opened again on eyeball networks, RBLs and graylisting can remain at home, and the SMTP email system will be 100% spam free and reliable and real-time. (there are several other features which have been removed from most smtpds to "stop spam" such as accepting ip addresses rather than domain names in the target email address, which can then return)

all the other stuff never stopped spam, it just made smtp email unreliable slow and no longer an option for 99% of the things where email was used for before, and skype, msn and facebook are used for today.

this system -does- stop spam, but the disadvantage to this system is that by implementing it, smtp email is no longer suitable for "initial contact"

(well you could ofcourse place passwords in whois and on your website for your hostmaster/sales box so random people can still make initial contact over smtp, or simply accept all passwords on those boxes, on which then there WILL be spam.. :wink:

i'd say, smtp no longer being "open for any random idiot to mail any other random idiot without knowing each other first" is less of a disadvantage than taking the whole thing slowly die by making it less and less attractive as a means of communications (slow, unreliable and not real-time, and still with spam coming in by the 1000s, which it is due to "conventional" attempts to stop spam)

16

you just give contacts for the passwords with which you have received a
new one.

each potential person that can send email to your email address, gets a
unique password from you.

You missed the point. How does person37@gmail.com ask me for a password, if
I don't accept his e-mail without one? (Hold this thought, we'll be back to this)

sending person/maillist 1 gets password abcdefg to send to bla@example.com
(no matter from which email address)

sending person/maillist 2 gets password 123545 to send to bla@example.com
(no matter from which email address)

And if I've assigned 123545 to duct-tape-2010@yahoo.com, but he's since moved
to clawhammer101@gmail.com, how do I securely notify him of the new password,
keeping in mind that I'm probably changing the password *because the enemy
already has access to the old password*? "Hey Joe - somebody has enough access
to your system to get 123545 - so use fuzzy-wombat instead". What's wrong with
this picture?

With 140 million compromised boxes where sending the new password is basically
e-mailing to the enemy, and the scheme leaking new passwords to boot, "revoke and
issue a new credential" simply doesn't scale.

In other words, the only sane response is "revoke and don't bother setting new
one". At which point the person has to contact me and ask for a new password.
"Hey, this is duct-tape-2010, my password doesn't work, give me a new one".
Given that his old password doesn't work because I revoked it when a spammer
got hold of it, how do I know that I'm not giving the new password directly to
the spammer and the esteemed Mr Tape has no idea any of this happened?

Further discussion probably belongs on SPAM-L.

17

This is an excellent idea. I invite you to do everyone a favour and turn yours off first.

Nick

18

you just give contacts for the passwords with which you have received
a new one.

Hi Sven/others,

This very much sounds like TMDA:

http://tmda.net/

Where by each person that needs to contact you, you give a unique e-mail
address.

So you give out key1@domain.tld to user1 and key2@domain.tld to user2.
That way when you registered at that webshop or mailinglist
and that e-mail address gets used for spam, you just delete that one
unique key (and maybe, if you still want to communicate with them,
a new unique key).

There are 2 variants if I remember correctly:

key@domain.tld for when you have a personal domain
key-user@domain.tld for when you have a server which understand address
extensions

While there is software for that, I've been doing something similair to
this by hand for a long time for a lot of contacts.

The good thing about using a unique e-mail address instead of a password
is that you can block at the SMTP-level, without even receiving an
e-mail body.

Have a nice day,
    Leen.

19

Actually I think it's user+key@domain.tld for the second one. At least
that's what I've seen for Postfix. Not so sure about other MTAs.

Regards,
Ben

20

That's a good start, but for general use, if I'm handing out an
address like "sven@jgreco.net" to Sven, and "leen@jgreco.net" to Leen,
the real problem here is predictability. If Sven is a bad guy, he
can cause trouble by guessing that I'd use "leen@jgreco.net" for Leen
and proceed to pass that address out to spammers, making Leen look like
a bad guy.

That particular problem is reduced by generating random tokens for the
LHS, however, doing so introduces new problems, such as the fact that
"23ycs7ia877oij@jgreco.net" is no longer obviously associated with Sven.

I've been very successfully using a much better tagging system here.

Take a user-specified identifier, such as, say, "sven".

You run this through a one-way crypto function, such as MD5:

md5=`echo "${1}/SomeMagicSecret" | md5`
f8=`echo "${md5}" | sed "s:^\(........\).*:\1:"`
echo "${1}@${f8}.demo.jgreco.net"

This results in something like

nanog@e6ecd2ea.demo.jgreco.net

Now this has a bunch of interesting properties.

1) You make *.demo.jgreco.net a DNS wildcard zone that is rewritten to
   your actual mailbox address.

   If and when a problematic address is issued, you can add at the DNS
   level an MX (or whatever nasty you prefer) for the particular domain
   name that's troubling you; for example, set e6ecd2ea.demo.jgreco.net
   to NS from 127.0.0.1. Never even touches the mail server. Of course
   MTA or procmail deny works too.

2) By using a separate zone, it makes it trivial to configure your mail
   system so that these addresses blow completely by any normal spam
   filtering; the problem of false positives for things like transactional
   e-mail that spam filters often find "spammy" vanishes completely.

3) You need not keep a database of valid tokens; you can simply re-validate
   the LHS in Procmail. This means that you can do things like write a
   mobile app or web app that doesn't have to have access to your mail
   server's innards. The primary downside is that you need some way to
   compute the crypto-signed bit.

4) You can keep a database of issued tokens along with when and why they
   were issued.

5) If you make it a habit of using a LHS that's descriptive, it's hard
   for a sender to argue that the tag was not assigned to them. It's
   particularly entertaining for things like e-pending because it will
   reveal which companies you will no longer choose to do business with.

This turns out to be very powerful and very flexible. It can be extended
to include functionality such as single-use addresses or limited-age
addresses, etc. The big trick is to leverage the e-mail address field
itself rather than trying to add a password or something like that in the
body.

... JG