Re: greylisting on debian.org?
On Sun, 09 Jul 2006, Thomas Bushnell BSG wrote:
> Henrique de Moraes Holschuh <hmh@debian.org> writes:
> > You can, for example, use dynamic IP supersets to do the greylisting
> > "triplet" match. Now the problem is a matter of creating the supersets in a
> > way to not break incoming email from outgoing-SMTP clusters.
>
> Is there a way of doing this which doesn't require you to know in
> advance the setup of remote networks and such? Does it scale?
Yes. The most absurd way is to consider every non-stolen, valid for the
public Internet IPv4 netblock as belonging to a single IP superset, and
flushing the graylisted database often (but mind your outgoing email retry
policy!).
Another is to
> > You can also only graylist sites which match a set of conditions that flag
> > them as suspicious. Depending on what conditions you set, you do not have
> > the risk of blocking any server farms we would want to talk SMTP to.
>
> You don't have the risk? Are you saying that there is exactly *zero*
> risk? Please, if you don't mean that, be more precise.
We == Debian.
Server farms we want to talk to == those professionaly run by
non-botnet-<censored>. We also want to talk to MTAs run by geeks on their
home connections, but those are *not* outgoing SMTP farms, so they are not
an issue.
If you graylist only people on DUL and with severily broken DNS, you don't
hit professionaly run SMTP farms like the one for gmail, yahoo, or any other
gigantic email provider. Chance is not zero, it is very small. And it is
even smaller if you consider it over a three-days retry window.
Never mind nobody suggested using a dumb, deprecated graylister for @d.o.
> >> So far, all I have seen in response to this particular problem is to
> >> say that "properly configured" includes an exactly accurate hardcoded
> >> list of all such sites on the internet.
> >
> > Then you are hearing differently now.
>
> What ar the "dynamic IP supersets" you speak of, then?
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.
> >> Another problem is with hosts that do not accept a message from an MTA
> >> unless that MTA is willing to accept replies. This is a common spam
> >> prevention measure. The graylisting host cannot then send mail to
> >> such sites until they've been whitelisted, because when they try the
> >> reverse connection out, it always gets a 4xx error. I've been bitten
> >
> > Why will the host implementing incoming graylisting *always* get a 4xx error
> > on his outgoing message? I am curious.
>
> The other way round.
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).
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.
--
"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: