[Greylist-users] Looking for updated list of bad (but good)senders

[Ken Raeburn]

Scott Nelson <scott at spamwolf.com> writes:
> Although IPs are bad in theory, 
> in practice I'll bet it would work well enough.

It would make it a hassle to submit more than one new entry if a
problem is discovered while travelling (and using random DHCP or
dialup addresses), unless you have a host with a stable address from
which you can remotely run a web browser or whatever.

>>>  to give him the ability to
>>> submit domains for whitelisting.  Allow that registered user to submit, say
>>> 1 whitelist per month to the system.  As time goes on, that user becomes
>>> more and more trusted.  If the user abuses the system, the account is
>>> yanked.
>>
>>Nice approach.
>>
>
> IMO, a terrible approach.
> In many cases, the first submission would be a few dozen IPs, 
> and after that nothing.

The initial submissions would be large if we take both categories of
whitelist entries I described.  I'd suggest going with only the first,
more critical set.  Or maybe make them two lists, which might get
managed slightly differently.  (At least virtually.  Being more
cautious about deleting submitted entries with a special flag set
would have the same result.)

> And rate limiting is only meaningful if there is no way to get 1000 accounts.
> So you put an obstacle in the way of people who want to help,
> and don't really affect the people who want to be "bad".

As was pointed out, any spammer wanting to get around it could
probably just start using a mailer that retries.  Though I guess a
spamware virus could be created that signs itself up and submits its
own address, or something like that.  If the first entry isn't
permitted for a week or so after registration, though, and
registration involves submitting an email address to which some magic
cookie is sent, maybe that could be avoided.  And maybe reject
submissions for the /24 block from which the submission is sent, so a
spamware-infected box can't register itself, even if it's up and
running for a week or more.  Maybe prevent registration of entries on
block lists without special intervention.  Etc.

It doesn't need to be foolproof.  As with greylisting itself, it's a
matter of raising the bar high enough to work most of the time.

>>I think the second kind is more important, but do we want this
>>whitelist to include the first kind as well?
>>
>
> If they retry 100% of the time, why not white list them?
> You won't be blocking any spam from that IP anyway.

That could certainly be done, but it's a matter of mail delay, not
lossage.  I'm just concerned that the non-broken category will
dominate, and because it's okay to just drop one of those entries if
someone complains, management of the overall list could become lax.

It would also probably increase the size of the data set and frequency
of changes quite a bit, so depending on the distribution mechanism, it
could be fine, or it could be a hassle.

> In an ideal world, the list would include all kinds of information
> about the IPs, who submitted them, why they're submitted, when they
> were submitted, how many complaints they generated.
> It'd be easy enough to remove the "whitelisted because they retry" 
> category after the fact.

True.  But in the "whitelisted because they're legit but broken"
category we should be much more careful about removal.  I think
that's probably the most important way in which the two categories
need to be distinguished.

> Minor quibble - I've never /lost/ mail because of greylisting.
> Occasionally some email that was /bounced/ that wouldn't have been.
> The worst case was actually the GroupWise servers, and that was only
> because they reported the tempfail incorrectly.
> They still generated a bounce.
>
> Please call it "bouncing" or even "rejecting" but not "losing".

When you consider that some senders (newsletters, other big list
senders) will ignore bounce messages, or never generate them, or just
examine them to decide whether to drop you from a list, I think
whether or how "losing" applies is a subtle point.  I don't think I'd
say that any specific system "lost" the message, since each performed
as it was instructed to, but especially since no one on the sending
side is going to do anything or know anything about the problem, I
can't think of a better way to describe the overall result than that
the message is lost to me.  If my workstation's disk crashes, I lose
(saved) mail too.

When describing that end result, the distinction between "bounce sent
to a list server that ignored it" and "mail system hiccupped and threw
the message on the floor" and "disk died" seems unimportant.

Ken