On 2007/01/18 07:12, Darrin Chandler wrote:
> On Thu, Jan 18, 2007 at 07:41:07AM -0500, Seth Hanford wrote:
> > 1) Does it make sense to have spamd discard malformed sender / recipient
> > addresses? In this case, there is no envelope sender address at all,
> > which I seem to recall violates an RFC
>
> I have often though about this. It's a statistical solution, since there
> are some "legit" servers out there sending with <> as sender. Mostly
> it's spammers, but mostly they get caught by spamd anyway.
RFC2821 6.1 - also see 3.7, 4.5.5:
If there is a delivery failure after acceptance of a message, the
receiver-SMTP MUST formulate and mail a notification message. This
notification MUST be sent using a null ("<>") reverse path in the
envelope.
-> do not drop these.
But try not to generate these notification messages by email. Teaching
your backup MXes which usernames are valid and which aren't avoids many
of these. This reduces backscatter, avoid filling your queues with spam
related bounces to failing addresses, and you avoid a possible method
to bypass greylisting.
> There are things you can do behind spamd to help. In addition to spamd
> and SA, I use relaydb. Relaydb is cool. If something gets through spamd
> and gets flagged as spam by SA, I send it to relaydb (from procmail)
> which extracts the IP and adds it to a database. This can be used in
> spamd.conf as a blacklist (it's even in there already, commented out).
smtp-vilter can handle this too (it has 'reactions' which add addresses
to PF tables for a certain length of time), I use it with both Sendmail
and Postfix.
