Milter-greylist

This seems not particularly useful to me.  We get very little mail
addressed to non-existent users.  Furthermore, any mail addressed to
non-existent users is already rejected by sendmail anyway,
so I don't see the need for greylisting to deal with it.
A complete reject is preferable to greylisting in this case.
Is there something here I don't understand?

It's not clear to me that tweaking the delay will have that much
of an effect.  If one is going to the trouble of resending mail,
the easiest solution is to be fully compliant, so the mail would
eventually be delivered anyway.  I don't know what spammers are
currently doing in this regard, however, so that's just speculation.

Gary

>  > Could you post a more detailed plan of the way you think this
> should be
>  > handled? The idea of a reputation system sounds appealing to me,
> but I
>  > don't see how you would increase or decrease the delays exactly.
> 
> Have this table:
> +--------------------+-----------+--------+
> | IP or SPF verified | "Badness" | Last   |
> | domain             | index     | update |
> +--------------------+-----------+--------+
> 
> On incoming mail to non-existent user (or other indication of "bad"
> behavior, e.g. DCC positive), increase badness index by
> constant_coefficient/(time_now-last_update+1), and set last_update to
> current time.  Or maybe just increase it by a constant.
> 
> On "good" incoming mail (e.g. that would cause autowhitelisting) reset
> badness index to zero.  And set last_update to current time.
> 
> On any incoming mail, set
> new_delay=default_delay+another_coefficient*(badne
> ss_index/(time_now-last_update+1))
> 
> Formulae may be more sophisticated, such as logarithmic or
> exponential, but you get the idea.