On Thu, Feb 03, 2005 at 09:03:24PM -0500, Scot L. Harris wrote:
> On Thu, 2005-02-03 at 20:34, Jeff Kinz wrote:
> > On Thu, Feb 03, 2005 at 02:49:12PM -0600, David Hoffman wrote:
> > > I looked for any discussion lists about greylisting and haven't found
> > > any, so I thought I might try asking here.
> > >
> > > I'm considering adding greylisting to my postfix configuration, and
> > > some of the articles I have been reading about greylisting show that
> > > there can be any of several situations in which greylisting would not
> > > be a viable solution.
> > >
> >
> > It is inadvisable for anyone using email in a professional capacity
> > to use any form of TMDA (whitelisting/greylisting).
>
> Interesting rant. And I agree with most of what you state about TMDA.
> I refuse to respond to such requests.
>
> However don't lump greylisting in with TMDA.
Point taken. The exact definitions of what constitutes "whitelisting,"
TMDA and greylisting have shifted continuously since their recent rise
in popularity.
But -according to a Google definition lookup - You are right.
Greylisting is not a form of TMDA. Quote:
############################################################
Greylisting
How it Works
Typically, a server that utilises Greylisting will record the following
three pieces of information (known as a "Triplet") for all incoming
mail.
* The IP address of the connecting host
* The envelope sender address
* The envelope recipient address
The client is checked against the mail server's internal whitelists (if
any) and if the client has never been seen before it is greylisted for a
set period of time (how much time is dependent on the server
configuration). The mail is then rejected with a temporary error. The
assumption is that since temporary failures are built into the RFC
specifications for e-mail delivery, a legitimate server will attempt to
connect again later on to deliver the e-mail.
Greylisting is effective because many mass e-mail tools utilised by
Spammers are not set up to handle temporary bounces (or any bounces for
that matter) so the Spam is never received.
Advantages
The main advantage from the users point of view is that greylisting
requires no additional configuration from their end. If the server
utilising greylisting is configured appropriately, the end user should
not notice any delays in e-mail delivery
>From a mail administrators point of view, usually only minimal
configuration is required on the mail server for greylisting to work.
ENDQUOTE (it goes on for some length.)
This leaves the possible remaining objection centered around exactly
how long the email will possibly be delayed for, and/or the possibility
that some email systems mail never retry. (poor ones ;-) )
>
> It is a much different method that does not require senders to jump
> through hoops or incur significant resources on the senders part. It is
> essentially transparent to the sender and utilizes standard RFC rules
> that have been in place for many many years.
>
> The only real reason someone would not like greylisting is a false
> assumption that email is an instant messaging service. True, when it
> works well email can be very very fast. But the RFC does not guarantee
> delivery in any specific amount of time. Those users who have this
> perception will at some point have an email get stuck in a server some
> where for several hours or even days. And that is the result of normal
> email operations per the RFCs.
>
>
> --
> Scot L. Harris
> webid@xxxxxxxxxx
>
> Mundus vult decipi decipiatur ergo.
> -- Xaviera Hollander
> [The world wants to be cheated, so cheat.]
And I thought she only spoke Dutch and French.
--
Linux/Open Source: Your infrastructure belongs to you, free, forever.
Idealism: "Realism applied over a longer time period"
http://www.scaled.com/projects/tierone/
http://kinz.org
http://www.fedoratracker.org http://www.fedorafaq.org
http://www.fedoranews.org
Jeff Kinz, Emergent Research, Hudson, MA.
