[Mimedefang] Spam to inactive accounts

jmiller at purifieddata.net jmiller at purifieddata.net
Thu Oct 17 15:59:01 EDT 2002


On Thu, 17 Oct 2002, Geoff Thornton wrote:

> I've been thinking along those lines as well for some time now.  My only
> humble thought was that I would use a file, almost like a whitelist, to
> store recipient names, whether the recipient is valid or not, plus a value
> similar to a TTL that would allow caching of this information.  The names
> and TTL values would be checked, added, deleted, or have their TTL values
> renewed (for example, if their current TTL is half the original, then
> re-check recipient and update values).  I was thinking that this would save
> the effort of checking every recipient real-time, but also allow for
> automatic updating of the recipients, without having to rely that the
> destination server is always available.

I think this is a very good idea. Since the file might grow quite large
on some systems, this could also be expanded upon to allow multiple
storage formats (flat text file, sql via DBI, dbm files, ldap, etc)
which would allow for faster queries if needed. You could also provide
"none" as a storage, and have every check done fresh.

>
> My only dilemma is what to do to a message for a "new" recipient if the end
> mail-server is unavailable.  I was thinking the best response was to send a
> 400 series 'message deferred' error to have the originating server to try
> later.  Hopefully by the time the message retries, the end mail-server would
> be available again.

You could simly accept it. This would be no more harm than the current
situation. I timeout could even be put in place for when it does see
the server as down, so that if it's found to be down once, it won't
do any network checks to it for another XX minutes.

This would also answer David's concern of what to do when the server is
unreachable, as most people currently use the box to queue messages
when the desination is down.

>
> Also, when I use the term TTL, I don't mean a numeric value that is
> decremented each second, but a value like a future timestamp that indicates
> when the information expires.  For example, newly added recipients could
> start off with a future value like 8 days.  For the first 4 days, recipient
> checks would be purely cached.  For the next 4 days, recipient checks would
> be cached, but also include a request to the end mail-server to check for
> that recipient.  If that recipient is still there, then the future timestamp
> would be incremented by like 4 days.  If the recipient is not there, then
> the recipient is immediately marked as invalid and the future timestamp
> incremented by some amount.  After 8 days (or when the timestamp expires),
> the information is purged from the file.
>
> My thought is that would cache both valid and invalid recipient information
> without holding stale records forever.
>
> Just my $.02
>
>
> --Geoff Thornton
>
>
> -----Original Message-----
> From: jmiller at purifieddata.net [mailto:jmiller at purifieddata.net]
> Sent: Thursday, October 17, 2002 1:16 AM
> To: mimedefang at lists.roaringpenguin.com
> Subject: Re: [Mimedefang] Spam to inactive accounts
>
> >Since mimedefang is usually placed on a server that acts as a gateway to
> >internal mail systems, and we now have the "filter_recipient" call in
> >place, couldn't this problem be solved once and for all by a well designed
> >filter_recipient function?
>
> <snip>
>
> >Please let me know if I'm totally off base here, or if anyone has any
> >suggestions. I know there would have to be some workaround in place
> >(for outgoing messages, as one example), but it strikes me as something
> >that'd work really well if done right.
> >
> >If enough people are interested, (and multiple RCPT To:'s won't be an
> >issue) I can throw something together, or maybe someone else would
> >be interested in running with this idea.
> >
> >--
> >Josh I.






More information about the MIMEDefang mailing list