Re: greylisting on debian.org?
On Sun, 09 Jul 2006, Thomas Bushnell BSG wrote:
> I don't think I understand just what you're saying. Can you spell out
> the details for me?
Does the second email I sent (with the missing stuff) provides the
clarification you asked for?
> It distresses me that I have said twice now that a "solution" which
Read below. When you do, please remember that many of us consider that a
fully-open system which drowns us in SPAM is also broken, because you do
lose information for failure of locating it among the noise.
> dumb one in my book. I want a solution which specifically *never*
> needs any preset hardcoded "this set of addresses/domains gets a
> pass".
There is no hardcoding. Please use more exact terms. I think I understood
what you wanted to say, but whitelists are not *hardcoded*. They have never
been, they are updated in runtime. So use the proper terms next time.
> > In their dumbest form, match using big, static netmasks like 255.255.128.0.
> > That should give you a hint of what I am talking about.
>
> A hardcoded list is the problem. Got it? A loose hardcoded list is
> still a problem.
What I believe you mean is that for you, a non-perfect solution for
identifying outgoing SMTP clusters is not acceptable, as it gives a non-zero
possibility of permanent delivery failure to a graylisted destination.
Well, there are solutions that are good enough in practice. If you do not
like them because they are not perfect (as in guaranteed zero fail rate),
then there is no solution I know of that will be acceptable to you.
But please remember that people operating outgoing SMTP clusters *want* to
deliver email, and that they are aware of graylisting practices and also of
the diminishing probability of sucessful delivery when the sending site has
broken DNS configuration, or is listed in popular blackists and dial-up
IP space lists.
Also, keep in mind that the Debian graylisting proposal specifically states
that graylisting is not to be applied to every single incoming connection,
but rather to those coming from broken DNS sources, and blacklisted sources,
which are extremely unlikely to be the class of sending cluster that would
break graylisting in the first place.
So you do NOT need a perfect theorical solution to get zero fail rate in
practice for the proposed graylisting scheme. You don't get any guarantees
of a zero fail rate, however.
> > Here's what I understood of what you wrote:
> > Alice wants to send email to Bob. Alice graylists incoming email. Bob does
> > sender verification trying to email people back before accepting a message.
> >
> > You claim Alice cannot send mail to Bob because Bob will attempt to "almost
> > send email back to Alice", thus Bob's verification attempt will be
> > graylisted (with a 4xx), causing Bob to deny the delivery of Alice's message
> > with a 4xx.
> >
> > If that's not correct, please clarify.
> >
> > If it is correct, I am asking you *why* Alice's system will never let Bob's
> > verification probe through (thus allowing her email to be delivered to Bob).
>
> Because Bob never sends a complete email message to Alice.
That is a broken graylist implementation, then. It should be fixed (or
avoided at all costs). Which graylister was that one?
For graylisting, you need to verify that the sender will retry. This is not
done through verification of completed email delivery! It is done as soon
as you got enough information to identify it as the same sender and message.
If the sender will retry, you are to approve him through the graylist
regardless of any delivery taking place.
> > I *can* see a scenario where delivery might never happen (I am ignoring
> > configuration error scenarios on Alice's side), but it depends on Alice also
> > doing the same type of sender verification, and on one or both sides
> > violating RFC 2821.
>
> Doing sender verification and graylisting are both violations of the
> RFCs. You can hardly say "this will work as long as everyone else
> follows the RFC" when you aren't doing so yourself. My point is that
Agreed, you cannot say that. But nobody did say it. And the scenario you
experienced for Alice's failure to deliver email to Bob requires a broken
graylisting implementation that acts in a specific *wrong* way, and that was
the answer to my question.
Now, I am a bit annoyed with the "graylisting violates the RFCs" generic
statement, so I'd really appreciate if you could make it more specific.
Please explain how the idea behind graylisting ("force a host to retry a
SMTP transaction at a later time") violates RFC 2821. RFC 2821, AFAIK,
requires that the sending side deal with that scenario, and anyone who
doesn't deal with it is the one violating the RFC.
There is an issue with current graylisting implementations that *I know of*
(and I certainly am no expert in the area), in that they *will* fail to
recognize shared-queue outgoing clusters in theory, and *may* fail to do so
in practice (depends on such cluster deployments failing to match known
patterns). This has nothing to do with RFC 2821 except if you go into
subjective "in spirit" violations. Was this the violation you were talking
about when refering to graylisting?
> If your system causes any RFC-compliant mail to lose, then your system
> loses. So far you have argued at best that you are willing to ignore
> the cases where it loses. Great. I'm not.
Actually, I am ALSO arguing that these cases are probably not going to
happen in practice, now that graylisting is far more mature and widely used.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: