> How exactly are legitimate messages lost through greylisting? I've
> come up with these:
>
> 1. legitimate messages that don't retry (someone mentioned Amazon
> newsletters)
The postgrey whitelist included in the build covers some of the major
ones. I'd question these being legitimate emails and I'd question this
being a legitimate way to run your mail system, but this is where you'd
likely see mail lost.
Nice. I didn't know postgrey had a default whitelist.
> 2. legitimate messages that take longer than the maximum specified
> retry period to retry (has anyone run into a mail server that takes
> longer than a day to retry?)
No. Most I've seen is 12 hours at a small DSL provider in LA. The
fastest is Hotmail at 30 seconds.
Good news.
> 3. legitimate messages that retry from a different server each time
> they retry (someone mentioned that they have seen this)
I've seen Dreamhost do this and I still can't fathom the idea behind it.
unless webserver outgoing connections are originating from a NAT DHCP
pool or something weird. However setting the IP check to be the first 24
bits, aka match on the class C, makes this go away in every case I'm
aware of.
Any drawbacks to that? Is this what you mean:
# --lookup-by-subnet strip the last 8 bits from IP addresses (default)
or this:
# --lookup-by-host do not strip the last 8 bits from IP addresses
or something else?
In cases 2 and 3 the original mail sender would get their email returned
after the standard four day timeout whereas the mail goes completely
into the ether in case 1.
Why wouldn't the email be returned to the sender in case 1?
By the way, I've been greylisting for about 24 hours and spam has been
reduced by about 99.5%.
- Grant
--
gentoo-user@gentoo.org mailing list
