Re: greylisting on debian.org?
Henrique de Moraes Holschuh <hmh@debian.org> writes:
> 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.
You may lose that information; I do not.
> 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.
Then how do you know which things to add to the white list *in the
case I mentioned*?
> 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.
I want you to be explicit and clear about which new rules you are
writing into the RFCs, so that people can conform to them. You are
making up new standards and hosing people who do not comply; at the
very least you have an obligation to document the new standards you
are making up.
> 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.
You must be willing to retry the transaction, but there is *not* a
requirement that you retry it from the same address, or the same
netblock, or the same anything.
If the graylisting waited until DATA, and cached the message contents
(or a hash of them, say) in such a way that it could detect the
retransmit no matter what address it came from the next time, this
would work just fine AFAICT.
Still, making up new standards is a risk-prone thing. The fact that
nobody has thought of the case where this will fail does not mean it
won't fail. Graylisting was a wonderful idea, but the people who
first thought of it didn't even notice the failure modes. This is the
danger, and a clear and open statement "these are the specific cases
where we know that our scheme will fail" would be a very nice thing.
Thomas
Reply to: