Pierre Habouzit wrote:
> Le Lun 27 Juin 2005 10:14, Stig Sandbeck Mathisen a écrit :
> > Since this is contrary to my experience with greylisting, I'd like to
> > hear more about your experiences with it, and why you consider
> > greylisting "really painful".
>
> I already did : for personnal use (and I use my @debian.org address for 
> some debian related personnal discussions, like discussions with an 
> uploader I sponsor or alike) I find that 30minutes delays are not 
> acceptable (and I know that greylisting last only 5 minutes, but it's a 
> fact that requeue of a mail is done 30 minutes after the first try for 
> most of the SMTP server on the planet).
>
> I don't ask a <5s delay for every mail I send/receive, but if a mail 
> takes more than 2-3 minutes to be delivered, then this is useless.

I think you misunderstand.  Remember that only the first exchange with
a new address is delayed.  After the initial exchange there is no more
delay.  Your continuing conversations will not have a delay.

> > I'm also interested in hearing about the size of the mail platforms
> > you've used it on, and wether the mail platforms are list-heavy or
> > user-heavy, and mostly incoming or outgoing traffic.
> 
> On a mail platform where you use greylisting, you generally have a boost 
> in performances. *BUT* you punish all the MX that deliver mail to you. 
> greylisting put the charge on the SMTP server before you, and those MX 
> will deliver mails slower to you.

There is no valid reason for an MX exchanger as a backup mail relay on
the internet today.  These days MX records are only useful for routing
to private subnets.  Greylisting in the presense of MX backup relays
means that all must have the same rules.  Because otherwise there
would be no delay as mail was delivered to the MX backup and then
proceeded immediately to the primary.  Attempting to deliver mail to
the MX secondaries hoping they will have lesser restrictions is a
common spammer technique.

> like I said many times in that thread, greylist is a good solution to 
> filter spam with quite no false positive, that's true. *BUT* it's a bad 
> idea to use it for *every* mail. A mail that (e.g.) :
>  - is SPF-clean
>  - comes from hotst that are RBL-clean
>  - <put your own fast test here>
> should not suffer from greylisting.

Remember that all subsequent messages after the first one are not in
any way delayed.  The effect there is the same as not having
greylisting.

Bob

Attachment: signature.asc
Description: Digital signature

Reply via email to