Re: TLG GREATFN - unauthorized $8.99 credit card charge

>No, just implementation details. I have been using Greylisting for 1
>year now, and all the problems you posted are not problems, or at
>least problems that are known for a long time and have been addressed.
>
>>1. Some legitimate SMTP servers do *NOT* retry sending the email.
>>Yahoo Groups seems to stand out in this regard. Certain Windows
>>desktop clients don't, either, even though these act like servers
>>by routing by MX records.
>
>The easiest way is to just whitelist the IP addresses of such servers
>from Greylisting. There are not that many:
>http://cvs.puremagic.com/viewcvs/greylisting/schema/whitelist_ip.txt
>Frankly, no one cares about Windows desktop clients acting like
>servers.

I admit I didn't know that there was anyone maintaining a whitelist,
and figured it was painful to assemble one from complaints. Does
AOL or Yahoo Groups notify the list maintainers when it starts
adding more mailservers?

The customers operating Windows desktop servers do, if they happen
to be our customers or someone our customers care about getting
mail from.

>>2. SPAM relayed through a legitimate SMTP server (perhaps because
>>the spammer has signed up for a throw-away account and hasn't been
>>caught yet) will be retried, and many of them seem to try every 5
>>seconds until the mail goes through, greatly increasing the load
>>on the servers. The same applies to non-SPAM from some servers.
>
>Most greylisting implementations have a initial delay of a previously
>unknown message, say 1 hour. During this time, a failure is returned.

I hope you mean a *temporary* failure is returned. 1 hour is I
think a bit longer than necessary for it to be effective. (I do
use it for some personal machines but I can't figure out how to use
it well for an ISP. 5 minutes seems to be plenty to weed out the
spamming engines. For that matter, 0.5 seconds may be 95% as
effective as 1 hour, as about 95% of the {sender address, sender
host, recipient} triples rejected by greylisting are never tried
again.) During that hour some of the legitimate servers have tried
720 times to deliver the mail. That's a *LOT* more load. I haven't
figured out a pattern of what kind of servers do this.

>Or see #1.
>
>>3. Some SMTP servers consider a temporary failure to temporarily
>>block retries for any mail destined for that host. If you've got
>>a small amount of SPAM (or just new correspondents) and a lot of
>>legitimate mail, this can significantly slow down the legitimate
>>mail as it backs up behind the greylisted stuff.
>
>This is absolutely fine with me. The same problem would've happened
>if there was a real temporary failure. This is not a problem with
>Greylisting; it's a problem with such SMTP servers.

No, it's definitely NOT fine. A 5-minute greylist combined with a
lot of traffic, 95% of it NOT spam, and a server that does exponential
backoff on temporary failures on a host-by-host basis can combine
to get 2-3 days mail delivery delay (at which point some sending
servers start bouncing mail left in the queue that long). I've
seen it happen. Trying to blame this on the sender (say, AOL) will
just get a customer response of "but it goes to my {Yahoo, Gmail,
etc.} account just fine".

The effect of a few real temporary errors does not cascade like
this. I have seen them produce the effect, but only for a continuing
repetitive error: at one point AOL had 32 MX records, 3 functioning
MX servers, and all of them were rejecting about 1 in 5 attempts
with a timeout. This was backing up the queue for AOL by a day and
a half, and it was pretty big news since most others were having
the same problem (I don't remember exactly when this was; maybe
6-7 years ago).

AOL backlogs get noticed. Similar problems with someone smaller
might not.


> >>4. If the mail is from a large ISP and it uses lots of outgoing
>>servers with a common queue, it may be a long time before the
>>mail is tried with the same sending IP again. AOL seems to operate
>>this way.
> >See #1. >

Gordon L. Burditt
.

Relevant Pages

  • Re: postgrey question
    ... >> servers are adopting greylisting that I suspect servers that can't ... According the postgrey's website, it supports automatic whitelisting, ... want their email and my users can complain to them until they fix their ...
    (freebsd-questions)
  • Re: Which greylist milter is least maintenance
    ... If you have multiple mail servers and MX records a sending system, on receiving a tempfail, will try the next. ... If that also has greylisting it will move to the next until it has exhausted your mx list. ... If you have greylisting enabled on one but not all MX servers you effectively have no greylisting for sending systems that are smart enough to retry. ... If you have greylisting on all your systems and they each maintain their own database you effectively have greylisting from hell. ...
    (comp.mail.sendmail)
  • sendmail sending to greylisting mta
    ... I could run the queue more often, but that could hit both my server and other receiving servers unfairly if the time were reduced enough to just pass the greylist on the second attempt. ... ISTM that what's needed is an adapting retry time - say every couple of minutes to start (which will deliver nearly as soon as the receiver's greylisting window ends), and dropping to hourly maybe if the receiver continues to refuse to accept. ... Please use the corrected version of the address below for replies. ...
    (comp.mail.sendmail)
  • Re: why I cant post?
    ... At least some of the Redhat list servers use greylisting. ... It appears, looking back through your posts to the list, that your ISP uses several different servers to deliver mail to the list. ... If your ISP uses a pool of servers to deliver mail where a different server can attempt to deliver mail each time a delivery is tried then greylisting can effectively block your messages until the same server at your ISP tries to deliver a second time to the same Redhat list server. ...
    (Fedora)
  • Automatic Harvesting of AOL Instant Messenger Screen Names!
    ... The AIM default privacy setting is 'Allow ALL users to contact me'. ... OSCAR protocol to communicate with AOL IM clients: ... Should AOL prevent these tools from accessing their servers? ... OSCAR is a proprietary protocol ...
    (Bugtraq)