Slashdot Mirror

Please stop roleplaying someone stupid with your current game of presenting the incorrect suggestion that the greylisting time set on the recieving server doesn't matter.

Lol.. Even if the particular grey listing you are using allows you to set the interval between reconnection attempts, you do not need to do so for grey listing to work. 90% or better spam email sent will never reconnect after being dropped once. The legitimate SMTPs will reconnect in a couple minutes if it is legit and the email will be received then subjected to other spam filtering processes if present on the servers. There is no pretending involved other then maybe your supposed experience with it.

http://projects.puremagic.com/greylisting/

I literally get 0 spam in my inbox. The only spam I ever get is from businesses that I have a "relationship" for (ie., created an account on their site, said no thanks to junk, but got it anyway). Easy enough to block them since each site gets their own alias.jan-1-2007@mydomain.com that I can filter later on and never bother to "unsubscribe."

I use sendmail with greylisting as my frontline defense, then dul.dnsbl.sorbs.net, `sbl-xbl.spamhaus.org, list.dsbl.org, and lastly bl.spamcop.net. Thunderbird is great at picking up all the stupid "business relationship" junk based on the servers spamassassin's markings (but I don't have spamassassin dropping anything, just marking it up), but mostly just gets in the way of me permanently rejecting their mail (just a few a month ever come in).

I found many of the sendmail configuration lines from http://www.sdsc.edu/~jeff/spam/Sendmail.html if you'd like to give it a try.

4 days worth of spam filtering shows the following were blocked (this is just for my little list of personal domains, mind you):
# grep -c sorbs /var/log/maillog
16048
# grep -c spamhaus /var/log/maillog
13246
# grep -c dsbl.org /var/log/maillog
230
# grep -c spamcop.net /var/log/maillog
897

Combined spam blocked (each file is 7 days worth of spam count, except the top one which is only 4 days):
# grep -cF $'sorbs\nspamhaus\ndsbl.org\nspamcop.net' /var/log/maillog*

/var/log/maillog:30486

/var/log/maillog.1:43508

/var/log/maillog.2:41687

/var/log/maillog.3:36868

/var/log/maillog.4:35687

Filtering may work decently, but it is resource intensive and depending on your email load, you may need a scanning box as big as your regular email server.

Try http://en.wikipedia.org/wiki/Greylisting
or
http://projects.puremagic.com/greylisting/whitepaper.html

Our own office only has about 150 mailboxes but we don't do any filtering at all because of our greylisting as implemented by http://www.openbsd.org/spamd

Even better we can greylist at the perimeter instead of letting all of that pointless traffic onto our own network.

And if you're feeling particularily vindictive start posting trapped email address on your own publicly available webpages. Make them invisible or hidden under other content but still harvestable by bots. And soon enough a significant percentage of email addresses out there will point to tarpits. Making botnet spamming a much slower proposition, and should therefore decrease the total ammount of spam.

If you use a garbage collector, you're deciding that it's worth a small performance penalty and a memory footprint that's slightly higher than optimal, and in exchange having vastly fewer memory leaks than is otherwise likely.

Well, sometimes not that small. You have to keep in mind that collection is far from free. At a conference I attended recently, there was a talk on avoiding garbage collection strain with certain applications using array slicing -- which basically works out to pointer aliasing, with the caveat that the alias can fall anywhere in the range allocated to the original pointer.

Still, I'd rather work with a garbage collector than without. I can be clever and use those techniques to reduce the work that the collector has to do, but if I screw up -- and no matter how good I am, I will; and when I do, it's going to be damned hard to find -- the garbage collector will take care of that.

For you, try a garbage collector that records a stacktrace for each allocation, and when it collects, log how much memory was allocated and where. Much faster and easier than hunting down memory leaks manually.

We use Postgrey to filter the spams out.
It works wonderfully even without additional filtering (blacklists, for example.. Which we do still use, though).

Postgrey is a grey-list system por Postfix (for a description on how it works, click here), and there are probably other good greylist filters around.

We've had (like everyone else has) massive amounts of spam going through Spamassassin, our server was down its knees all the time.
Now the machine is typically 95-98 percent idle and the spams we receive (remember I've said we use blacklists aswell) is only the ones which come from our intranet (from hijacked machines we quickly disable when discovered).
That tool saved the day.

Eventually those bastards will have a way around it, but for now it works very well.

Sadly, the way this was done, there is no way to test how well Greylisting would have helped.

IMarv

Greylisting is the answer, because it works on the behavior of the spammer, something that cannot change easily, not on the content, something that changes with every message. If spammer cannot send as many emails as possible, as fast as possible, then the price of spam goes up dramatically. To overcome greylisting, a spammer must be willing to implement a full mail-server on thier end. In current implementations they must be willing to queue messages for resending, and must be on a traceable, non-changing IP that will not go down for at least an hour after the last message they sent went out. It forces spammers to be responsible. No more "fire and forget" style mass mailings. And the great thing about it is there is no defense, no way a spammer can change his stripes and still be capable of the volume of email that made spamming so profitable.

If you don't implement even a five minute greylist on yur mailserver, stop what you are doing and go implement it now.

For anyone using Postfix, I would highly recommend setting it up to work with Postgrey http://isg.ee.ethz.ch/tools/postgrey/.

This reduced the spam at our installation by over 80% overnight, and has so far had no complaints of false positive.

For a detailed explanation of how this works, see here..http://projects.puremagic.com/greylisting/

Yeah, greylisting is superb as a first-pass filter. It's cheap, it's fast, it's completely automatic, and above all, it will reject the spam before you've even received it --- which means it's not taking up any bandwidth! If you have a spam problem, getting a greylister is the first thing to try.

As TFA says, check out greylisting.org for more information. This is also a good site. If you want a greylister, I strongly recommend Spey: it's an SMTP proxy that sits between your existing MTA and the outside world, and so will work on anything. I think it's particularly good because, er, I wrote it...

I know that this is going to start a religious flame war. And I apologize in advance. But since I started using challenge/response (specifically TMDA [tmda.net]) I just don't care. I give anyone my email whenever they want.

Greylisting is a very powerful spam reduction technique that works transparently. The OpenBSD spamd daemon has a greylisting modus, and has reduced my spam to a trickle.

Challenge/response can be quite irritating, in particular when someone post to a public mailing list and uses C/R. Any C/R request goes to my trash folder.

They shuld greylist instead, that way at least SOME legit mail would get through.

http://projects.puremagic.com/greylisting/

At the University where i work we cut spam to about 10% of former bulk with Evan Harris' greylisting software 'relaydelay' (thanks Evan!). It let's through all legit mail as long as the sending server follows SMTP-standards and allows for a temporary failure.

Some problems with mailinglistsoftware that uses different envelope senders for each mail, but you can whitelist those servers.

you mean like this? Looks like it's already been done, and is quite effective.

This method is for the mail server to refuse to accept mail for the first hour or so -- because then a spammer has to keep retrying and uses up more of several types of resources. When mail from a certain mail server, a certain sender, and a certain recipient, is attempted... a greylisting server will not even accept the mail until a minimum time has passed (might be an hour, might be longer). Standard mail servers will retry, and "recent" mail is remembered so frequent correspondents do not get the delay.

Spammers simply aren't diligent when it comes to maintaining their list, they don't remove bounced emails... I don't know what this guy did but he is thoroughly mistaken.

He isn't mistaken. He simply discovered that spammers don't retry. If you shut off your computer for two days out of three, legitimate mail will sit in the queue until the server gets through. Spammer software tries once to send, and moves on if it fails. Voila! On your "on" days, your signal/noise ratio is tripled.

He will discover that around 4-5 days, legitimate mail starts bouncing back to the senders. Two days is probably the limit of safety.

If he decides to tinker with his MTA instead of power-cycling his server, and if he takes a programming course, he will re-invent greylisting.

--Len.

I heard this all the time when I worked at a natural foods store. I call bullshit. From QuackWatch.org:

It can be terrifying to believe that one's body is being poisoned by toxins from within. But if this were true, the human race would not have survived, says Vincent F. Cordaro, M.D., an FDA medical officer. "A person who retained wastes and toxins would be very ill and could die if not treated. The whole concept is irrational and unscientific."

Best link I could come up with on short notice.

That said, this anti-spam method sounds interesting. I've been Greylisting on my mailserver for a while now, and it's certainly helped. It would be interesting to compare & contrast and get some hard numbers on how well these (and other) approaches work.

Isn't this just a variant of greylisting? (the link is the first hit on google for 'greylisting')

In case of our university mailserver it worked like magic. I was getting 100 spams per day and now I get 4-5 and these are mostly from 'professional' "spamming houses" (the ones with proper mailing lists and proper mailservers, but which don't like poeople who try to unsubscribe).

That sounds to be like a really inefficient form of greylisting.

By the way, I started greylisting on my mail server a couple of days ago, and my spam has gone down to virtually zero.

Greylisting is a very powerful spam reduction technique (with no false positives). This can be done at the firewall, and will consume little resources. It will stop much of the e-mails sendt by viruses that has it's own SMTP engine. Your other spam filtering daemons will have less work to do.

OpenBSD has a daemon spamd that can do greylisting. Just put an OpenBSD box in front of your mailserver, and you can test it out for yourself.

Greylisting is when you configure your mail server to reply, the first time a message is sent to it from a particular originator, with a SMTP try-again-later message. This requires the upstream server to hold the message in their spool for a certain amount of time. The next time they try, it'll be accepted.

I use it. It works, brilliantly; it's reduced the flood of incoming spam from several hundred messages a day to about 5. And it means that the spam gets blocked before it gets transferred, which means it doesn't use up my (or anyone else's) bandwidth.

Get more information here. My favourite greylisting SMTP proxy is Spey, but then, it would be: I wrote it...

To me greylisting seems like the best thing to do. See:

http://slett.net/spam-filtering-for-mx/greylisting .html

and/or:

http://projects.puremagic.com/greylisting/

In a nutshell, it simply uses a standard 451 SMTP response that says "Hey, I'm busy now, can you call back in a minute or so?" To my knowledge, all standard SMTP servers respect this request, and little to none of the mass mailers do. And if they do, their bandwidth will triple.

Here's a log example:

Oct 15 15:18:17 example1.example.com sendmail[6955]: [ID 801593 mail.info] i9FJIGH06953: to=, ctladdr= (168/601), delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=121994, relay=example2.example.com. [123.390.141.456], dsn=4.3.0, stat=Deferred: 451 4.7.1 Greylisting in action, please come back in 00:01:00

If the mail never comes back, then the sender is now blacklisted. If the mail does come back, the sender is whitelisted.

Simplest and most standards compliant thing that I've heard of, and it seems to work.

Our experience with greylisting has been (1) an 90%+ reduction in passed-through email (with no complaints from users about lost mail (yet)), (2) a dramatic decrease in server load because SpamAssassin doesn't see the message until after it gets past greylisting, and (3) people rediscover how useful email is once you get all of the crap out of their inbox.

Marketing Guy: What's the worst that could happen?
Dilbert: Our beta product could turn into an evil robot that annihilates the galaxy.

You've just described greylisting, and I doubt that's what they exclusively use. Or, rather, if that's all they use, then their claim of the only spam-firewall in existence is false. Many SMTP servers include greylisting.

By their definition, qmailscanner is a firewall too. It stops (quarantines) spam and only lets legitimate email through. Semantics.

Agreed. I'm running spamd (that implements greylisting) on my firewall. Very efficient, but I would not call it a "firewall", though.

1. I am hardly the first person to "explain" greylisting. A far better (and therefore, I suppose, more "damaging") explanation is secretly hidden in the whitepaper at the Greylisting website,
2. ideas for how to get around it have been well known, almost since its inception,
3. there is a real difference between someone knowing that a workaround exists and having the spamming "community" actually having two neurons to rub together to implement that workaround.

So here it is, more than a year later, and Greylisting still blocks approximately the same percentage of spam today (85-95% reduction) as it did a year ago. After more than a year, spammers still haven't changed their behavior.

"You are caught in a maze of twisty little Sendmail rules, all obscure."
-- "Sendmail: Theory and Practice", Avolio and Vixie

1. I am hardly the first person to "explain" greylisting. A far better (and therefore, I suppose, more "damaging") explanation is secretly hidden in the whitepaper at the Greylisting website,
2. ideas for how to get around it have been well known, almost since its inception,
3. there is a real difference between someone knowing that a workaround exists and having the spamming "community" actually having two neurons to rub together to implement that workaround.

So here it is, more than a year later, and Greylisting still blocks approximately the same percentage of spam today (85-95% reduction) as it did a year ago. After more than a year, spammers still haven't changed their behavior.

"You are caught in a maze of twisty little Sendmail rules, all obscure."
-- "Sendmail: Theory and Practice", Avolio and Vixie

1. I am hardly the first person to "explain" greylisting. A far better (and therefore, I suppose, more "damaging") explanation is secretly hidden in the whitepaper at the Greylisting website,
2. ideas for how to get around it have been well known, almost since its inception,
3. there is a real difference between someone knowing that a workaround exists and having the spamming "community" actually having two neurons to rub together to implement that workaround.

So here it is, more than a year later, and Greylisting still blocks approximately the same percentage of spam today (85-95% reduction) as it did a year ago. After more than a year, spammers still haven't changed their behavior.

"You are caught in a maze of twisty little Sendmail rules, all obscure."
-- "Sendmail: Theory and Practice", Avolio and Vixie

I wasn't using Bayes at the time. It was pretty immature and the implementations that were available didn't work too well. It's infinitely better now though. I had a procmail recipe that auto-munged and posted copies to NANAS. It also forwarded a copy to the FTC. Finally it submitted the spam to Pyzor and Razor. That recipe worked great until I was joe-jobbed. I never did get manage to get that recipe to filter out those bounces before performing the various actions. I was getting too much spam per day to confirm each and every message. When I moved and changed the DNS entries to point to localhost I was getting just over 120,00 pieces a day. I couldn't archive it. I had to trash it. I need to get it started again now that I have a permanently co-lo'd server. capable of handling anything I'll ever throw at it.

If you aren't already doing it, I highly recommend you implement greylisting. I'm implementing it soon. I hear it's wonderful. Canit has built in greylisting capabilities. Best of luck.

I run a friends-and-family hosting site (DNS, mail, web) for about 50 domains, almost all of which have catchall enabled. One user was getting 500+ spams a day, day in and day out. I was seeing 200-300 per day myself.

Four weeks ago I built the latest sendmail with Milter turned on and installed relaydelay.pl. The next day that user received two (2) emails, both of which were from friends. I got 7 emails, only one of which was spam.

Greylisting is the single most powerful anti-spam system out there. It blocks over 95+% of the spam and it doesn't "false positive" because it isn't doing pattern matches, Bayesian filtering or anything like that. It simply gives a TEMPFAIL to any email that has an unknown (from, to, server-IP) triple. If they come back more than X minutes later and less than Y minutes later, they are let through. Spammers almost always are using fire-and-forget SMTP servers so they don't retry, and so you never see their garbage. Positively elegant.

If you are the sysadmin, check it out and install it. Otherwise, hound your admin/ISP to install it. It saves bandwidth, aggravation, and time.

The corks just don't come out the way they used to.
-- My Wife, dealing with one of the new Corqs(tm)

The problem with this approach is that you run the risk of throwing away ham. Because you're starting with mixed spam and ham, and you're picking out the ham, you don't know for sure that what's left is pure spam. Traditional approaches are safer, because the take mixed spam and ham and throw away only what is known to be spam. Therefore (unless the spam selection process is overeager) they won't throw away ham.

(I feel hungry now...)

I use a greylister. It's brilliant. It reduces the amount of spam I get from about 100 to 150 messages per day to about 5 --- and because it does this before the messages are transferred to my machine, I don't even get the overhead of running them through spamassassin or even my MTA.

Greylisting implements the old sender-pays spam filtering system by exploiting the SMTP system. It requires messages to be sent twice: the first time it's rejected with a try-again-later reply. This makes it the sender's responsibility to store the message and resend it --- this is the cost. As most spam engines aren't real SMTP servers, they usually don't bother to retry. Real messages, however, will arrive about half an hour late. (You then implement lots of optimisation so that you don't bother greylisting messages from known good senders, etc.)

Advantages? It's highly effective. It's completely standards-compliant. It's 100% safe; it won't lose ham unless an upstream mail server goes wrong. It can work before the message body is transmitted. It works against a lot of Outlook Express email viruses too. And, best of all, it's completely invisible to both sender and recipient: set it up, get it going, and it Just Works.

If you're interested, I strongly recommend the one wot I wrote<BLATANT ADVERTISING/>, because it's simple to set up and works on any MTA, but there are lots more around --- the earlier link is a major resource.

...disable your catchall-address on your 4 domains, and only set up the addresses you need. You will see that the rate of spam you get will drop.

Furthermore the overall traffic you cause on the net will drop also, because the spam will be blocked directly at the mailserver with a 550. The mail will not be transmitted at all.

There are at least a dozen of other methods to block mail from entering a mailserver (given you really have admin-rights on the MX of your domains). There is no need to forward 3000 mails a day to some unlucky bureaucrat.

Please see:
Greylisting - the next step in the spam-control war (generic)
Anti-UCE Cheat-Sheet (Postfix)
Security-Sage Anti-Spam Guide (Postfix)

• listed in a DNSBL(***) of your choice or
• contain several digits in their resolving hostname which would indicate a dial-up host.

• listed in a DNSBL(***) of your choice or
• contain several digits in their resolving hostname which would indicate a dial-up host.

OpenBSD has added greylisting support to spamd in 3.5, and that feature is very efficient in dealing with spam as well as e-mails from infected Windows machines. SpamAssassin has much less work todo now :-)

It works by initially by "greylisting" e-mail from unlisted mail servers by sending a "451 4.7.1 Please try again later". If the server resends the e-mail within 4 hours, but minimum 30 min, the server is whitelisted. These timings can be configured, of course.

For now, this works very well for me, since few virii bothers to resend an e-mail, and the same goes for many spammers.

I set it up on one of my spam-filled accounts on Friday.. (averaged about 45 spams/day on an account I never had actually used anywhere)..
I've only had one piece make it through that since (but was immediately tagged by the virus scanner).
So I've been honestly spam free for nearly 4 days.

a) SMTP HELO's with names whose IP addresses don't match the originating IP

That's interesting.. when you send a mail from a windows machine, it uses its NetBIOS name as it's HELO.

Indeed, I might be willing to discriminatorily greylist all mail from any remote Windows system. (Greylisting: Sending a 4xx temporary failure the first time a host tries to send mail to a particular recipient. This causes a normal MTA to retry in a few minutes, but fire-and-forget spamware and worms generally abort.)

How to apply this to Windows only? OpenBSD's passive OS fingerprinting would be a start. It allows one to selectively redirect traffic based on the detected OS, and thus to offer different quality of service based on the quality of the client system. Since there is a much greater likelihood that a given Windows host's connection to my MTA is delivering spam and worms than that a given Solaris or Red Hat host is delivering spam and worms, there is a good reason to deteriorate service (as by greylisting) for Windows hosts -- as long as it can be done in a way which retains (eventual) delivery of real mail.

If Unix mail server admins all chose to greylist remote Windows hosts -- including Windows MTAs as well as client hosts -- then Windows servers would eat the cost of keeping messages in queue during the greylisting period. This would, effectively, be the cost of proving you're a real Windows MTA, not a worm or spamware. This lays part of the burden of the Windows system's susceptibility to malware back upon those responsible for it (deployers of Windows) whereas currently they are able to offload it upon the rest of us in the form of junk mail from worms.

(Incidentally, yes, the majority of mail exchangers run some form of Unix. Less than half, however, run Sendmail.)

Link to more information here, just to make sure that people don't get the wrong idea: a greylisting server will respond to all attempted deliveries from unknown sources with an RFC-compliant deferral, which should cause the sending MTA to queue the message for later delivery. The theory here is that most spam (as well as viruses) is sent by crap software which doesn't understand how to attempt a true "retry." No retry on a deferred message, no delivery for messages from the sending server.

I don't recall having seen any data on effectiveness -- would be interested in hearing from anyone actually using this approach in the wild.

I've said it a thousand times.

1. Mutt
2. Spamassassin
3. Greylisting
4. Profit!

If it weren't for /., I'd have never noticed.

Agreed. Fight technology with technology. So far the best solution I've tried is Greylisting. Since implementation SPAM is almost non-existant for us. It works by initially delaying (temp fail) incoming e-mail. When the sending mail server retries after X amount of time they will be automatically whitelisted for future mail so as not to be delayed. This is effective because 99.9% of spammers don't use mail server software that retries failed sends. It's too costly for spammers to retry sending failed delivery attempts. It seems to me most SPAM is a "hit and run" campaign.

Think about graylisting instead. The machines do the work for you. Whether this turns out to be a temporary solution or not will be seen.

because spammers react on them. An other alternative (SMTP-with-a-delay)
greylisting

Amid all these ads I thought I would throw mine up: Softhome

I have been using them for several years now I find them a good provider. The only drag is that they limit the number of times that you can access your mailbox per hour but they have web & stmp access in both free and non-free accounts

They also use greylisting to limit spam which involves only letting email through that makes several attempts. I find it very effective

A Tarpit will work if the spammer tries to send mail directly to the tarpit box. Dont think they do this very often these days, since they (as i assume) either use open proxies or minions from their trojaned box zombie army.

The open proxies black lists are imho a good thing to use but suffer from the typical disease: black list hosts get ddosed (afair 3 lists gave up over the last few weeks becaus of ddos), so this theatre of war might be lost soon. And of course there are probably millions of open proxies out there, unlikely to find them all before some spammer got the chance to send several million mails through them.

I dont think spammers care very much about poisoning - else they wouldnt have tried 4-5 dictionary attacks on my domains this year. They will send spam to any string having an @ and on . in it, bounces go to innocent third parties...

One approach i really, really like is greylisting. (Ill probably end up putting it in my sig since i love to post this url;))

There are some really nice proposals to get rid of spam, i believe that the first thing would be to use the greylisting approach. Next thing we need is to get rid of SMTP, remember the AMTP idea we just saw recently. For some time (probably years) we could have two mail protocols (SMTP and the new, safe one) while more and more mail servers would be switching to the new protocol. During this period i would use whitelisting for SMTP mails where every unknown sender would receive a message to either use the new protocol or undergo some painful procedure to get whitelisted.

Maybe you are looking for greylists?

Read about a project here [puremagic.com] to implement a grey list at the MTA level.

It basically involes inspecting the sending ip, sender envelope, and recipient envelope. If the receiving MTA has never seen this particular combination of the three before, it does not accept delivery of the mail piece with a temporary failure message. The vast majority of spam would then be ultimately rejected because it is often sent through open MXs and not a valid MTA with valid sender and recipient envelope information.

It is designed to be a compliment to other anti-spam measures without being as inflexible and cumbersome as black/white lists.

Along those same lines, you could also do a quick reverse check to verify reply-to addresses at the MTA level.

The battle against spam is not totally lost, and we shouldn't cut off our nose to spite our face the way blacklists do.

The great thing about greylisting is that spam never makes it to the user's folder, there is no possibility of false positives, and it's impossible for spammers to detect that we're using the feature.

This takes a lot of the workload away from SpamAssassin (which we consider to be a rather blunt weapon that generates a lot of false positives) and doesn't upset the users.

-BvB

http://projects.puremagic.com/greylisting/

The example is a Milter for Sendmail. There's also ways of getting it working in Exim and Qpsmtpd. Wietse Venema is putting it into Postfix (at which point I start using it...aw yeah). I'm sure there's lots of other examples; sign up for their mailing list like I did.

Time again to discuss greylisting?

Looks to me to be an elegant, viable alternative to traditional black/white -listing, both of which require lists be maintained -- and well maintained. Sometimes very large, very centralized lists, which have ugly consequences when they fail.

From the Greylisting Web site (with bolding from me):

The Greylisting method is very simple. It only looks at three pieces of information (which we will refer to as a "triplet" from now on) about any particular mail delivery attempt:

1. The IP address of the host attempting the delivery
2. The envelope sender address
3. The envelope recipient address

From this, we now have a unique triplet for identifying a mail "relationship". With this data, we simply follow a basic rule, which is:

If we have never seen this triplet before, then refuse this delivery and any others that may come within a certain period of time with a temporary failure.

Anybody know where we are as far as a working implementation of this idea goes?

Time again to discuss greylisting?

Looks to me to be an elegant, viable alternative to traditional black/white -listing, both of which require lists be maintained -- and well maintained. Sometimes very large, very centralized lists, which have ugly consequences when they fail.

From the Greylisting Web site (with bolding from me):

The Greylisting method is very simple. It only looks at three pieces of information (which we will refer to as a "triplet" from now on) about any particular mail delivery attempt:

1. The IP address of the host attempting the delivery
2. The envelope sender address
3. The envelope recipient address

From this, we now have a unique triplet for identifying a mail "relationship". With this data, we simply follow a basic rule, which is:

If we have never seen this triplet before, then refuse this delivery and any others that may come within a certain period of time with a temporary failure.

Anybody know where we are as far as a working implementation of this idea goes?