Author: Christian Schmidt Date: To: exim-users Subject: Re: [exim] Greylisting
Hi Carl,
Carl Inglis, 17.02.2005 (d.m.y):
[greylisting] > > It's not just that there may be a delay in mail delivery - greylisting
> > on the one hand side needs the "corresponding" ressources to queue
> > "good" (i.e. non-spam) messages on _each_ other hand side...
>
> RFC2821 states "while mail that cannot be transmitted immediately MUST
> be queued and periodically retried by the sender."
>
> That "MUST" means that regardless of my use of greylisting or not, the
> sender *has* to provide resources on the assumption that I won't be able
> to accept the messages.
Sure, but when using greylisting on the remote server, the local
server is urged to queue the mail only because of the greylisting on
the other hand side. And that's why I hold the opinion that the
implementation of greylisting is somewhat equal to "wasting other
people's resources".
And I hope I got it right: When a spammer succeeds in using rudimental
queueing mechanisms, greylisting on the destination server doesn't
prevent him from spamming either.
=> IMO greylisting may be a temporary solution, but goes to the cost
of others and will successful as long as spammers don't use any
queueing mechanisms.
Thank God there are several other means to fight spam using exim. ;-)
