| 1 |
Grant wrote: |
| 2 |
> How exactly are legitimate messages lost through greylisting? I've |
| 3 |
> come up with these: |
| 4 |
> |
| 5 |
> 1. legitimate messages that don't retry (someone mentioned Amazon |
| 6 |
> newsletters) |
| 7 |
|
| 8 |
The postgrey whitelist included in the build covers some of the major |
| 9 |
ones. I'd question these being legitimate emails and I'd question this |
| 10 |
being a legitimate way to run your mail system, but this is where you'd |
| 11 |
likely see mail lost. |
| 12 |
|
| 13 |
> 2. legitimate messages that take longer than the maximum specified |
| 14 |
> retry period to retry (has anyone run into a mail server that takes |
| 15 |
> longer than a day to retry?) |
| 16 |
|
| 17 |
No. Most I've seen is 12 hours at a small DSL provider in LA. The |
| 18 |
fastest is Hotmail at 30 seconds. |
| 19 |
|
| 20 |
> 3. legitimate messages that retry from a different server each time |
| 21 |
> they retry (someone mentioned that they have seen this) |
| 22 |
|
| 23 |
I've seen Dreamhost do this and I still can't fathom the idea behind it. |
| 24 |
unless webserver outgoing connections are originating from a NAT DHCP |
| 25 |
pool or something weird. However setting the IP check to be the first 24 |
| 26 |
bits, aka match on the class C, makes this go away in every case I'm |
| 27 |
aware of. |
| 28 |
|
| 29 |
In cases 2 and 3 the original mail sender would get their email returned |
| 30 |
after the standard four day timeout whereas the mail goes completely |
| 31 |
into the ether in case 1. |
| 32 |
|
| 33 |
kashani |
| 34 |
-- |
| 35 |
gentoo-user@g.o mailing list |
Archives