[snip]

> And this is my point. SA *DOESN'T* work on messages after they have been
> received. Since I use spamass-milter, SA sees the messages before
> reception is completed. (You're free to do otherwise.) Then when SA
> decides that the message doesn't conform to its high standards, the report
> of that fact goes back to spamass-milter which then returns status back to
> sendmail. The current result is a reject 5xx status. So all we need is for
> SA to manage one extra table and to allow some sort of reportage that
> spamass-milter could be mucked to understand.
>
> Is this making sense?
>

Why re-invent the wheel. While I'm sure most of the greylist milters out there are similar, I can only comment on milter-greylist. It will do almost everything you're looking for. The first time it receives a message it will send out a 451, it'll continue rejecting messages until a user defined time limit is reached. Two minutes in our case, although I suppose you could specify 4 hours as you stated, but I don't know why you'd want your mail delayed that long.  I've noticed that most servers will try to resend their messages within 5-15 minutes.

Once the second message is received, the tuple is stored in memory, and the table is dumped to disk at a user defined time interval. When you re-start the software, it'll attempt to read in the last dumped file to rebuild it's in memory table.  You also, define how long each entry is valid in memory, 7 days in our case, since yours is a home server, you should be able to bump this limit way up. As long as you keep receiving mail from a particular sender within this time period, their mail will not be delayed.  If no messages are received in that time period, the entry is dropped and they'll get a 451 the next time.  If you know specific email addresses, or domains, or mail servers that you never want to delay, you can white list them ahead of time using the config files.

Practically everything you want, and nothing needs to be re-coded.

Andy

Reply via email to