[Amavisd-new-debian-devel] Re: Bug reports

[Mark Martinec]

Brian,

Sorry for delay, your mail just arrived when I left for vacation,
and now it took me a while to catch up with my mail.

> I am going through old bug reports for amavisd-new in Debian,
> I suspect many are obsolete and can be closed.
> 
> Anyone know if any of these can be closed?
> Any help closing bug reports would be appreciated.


<URL:http://bugs.debian.org/193364>

  Can be closed, the default current log entry (2.3.2) looks like:
    Blocked SPAM, [10.11.12.13] [10.1.2.3] <...> -> <...>,
      Message-ID: <...>, mail_id: DLIEolNRsDou, Hits: 22.545+1.8, 11958 ms

  The corresponding macro is %c:
  %c spam level/hits (mnemonic: sCore) as provided by SpamAssassin,
     including a per-recipient boost when used in $log_recip_templ
     and a min of per-recipient boosts in other templates


<URL:http://bugs.debian.org/211740>

  Solved in amavisd-new-2.3.0 when feeding MTA->amavisd over LMTP.
  The problem does not have a better solution when using SMTP protocol.

  From the release notes:
- at last: when mail is received through LMTP protocol, gracefully handle
  a temporary failure 4xx reply from MTA to a RCPT TO command and pass it
  back to a LMTP client for tempfailed recipients only, instead of returning
  450 for _all_ recipients (needed the sending routine to be aware of the
  receiving side capabilities, which was previously not available);


<URL:http://bugs.debian.org/228766>

In 2.3.2 (and earlier) there are the following commented-out lines
in file amavisd. Uncommenting them achieves what was requested.

  # $hdr_edits->append_header('X-Spam-Checker-Version',
  # sprintf("SpamAssassin %s (%s) on %s", Mail::SpamAssassin::Version(),
  #         $Mail::SpamAssassin::SUB_VERSION, $myhostname));


<URL:http://bugs.debian.org/236482>

  In case of exceeded decoding quota or file number limit the
  current version (2.3.2) or amavisd-new no longer 'preserves evidence',
  it just tempfails the message.


<URL:http://bugs.debian.org/281752>

  The request is still valid, but has a low significance, because
  REJECT is only useful in pre-queue mail filtering setup, and
  amavisd-new is targeted at post-queue filtering, in which case
  the additional information would only be seen in one's own MTA log,
  which is not of much use. The REJECT destiny setting is pretty much
  useless in post-queue setup, the preferred settings are BOUNCE or DISCARD


Regards
   Mark