[Mimedefang] Spam to inactive accounts

[jmiller at purifieddata.net]

<snip> rest of message removed, cause the conversation doesn't
apply, though this is on topic</snip>


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?

(note: the current implementation may not work, as filter_recipient is
called once per RCPT To:. If anyone in the list of RCPT To:'s were
rejected, I'm not sure if it'd reject the whole message, or just that
recipient. If it'd reject the whole message, we might be able to
implement a "filter_recipients" call to solve it).

filter_recipient get's called right after the client issues an "RCPT To:",
and before the "DATA". So, instead of setting up complex access.db or
virtusertable solutions, and ldap databases, we could do something like
the following:

sub filter_recipient
{
	my ($recipient, $sender, $ip, $hostname, $first, $helo) = @_;
	# get server we are forwarding to
	my $server = &get_fwd_server($recipient);
	# figure out if the end recipient exists
	my $smtp_user_check = &check_recipient($server,$sender,$recipient);

	if ($smtp_user_check)
	{
		return(1,"ok");
	} else {
		return(0,"550 unknown user <$recipient>");
	}
}

where "check_recipient" would be a small smtp handler to login to $server,
send "HELO $ourhostname\n", "MAIL From: $sender\n", and
"RCPT To: $recipient\n" getting the result of the RCPT To: from the server,
and returning 1 if it was ok.
and "get_fwd_server" would check our local virtusertable and mailertable
and such, and figure out what server we're forwarding to (or on a simpler
basis, just build our own hash for that stuff).

This could allow all the same stuff people here seem to be asking for,
without the need for constant updates to files on the mimedefang box.

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.