Tom Hendrikx: > >> Otherwise, how might these invalid recipients be entering your queue? > > > > A good question. It appears to be only occurring with messages that are > > quarantined by DSpam and then subsequently redelivered. > > > > > > I've seen this issue before: dspam sends a garbled RCPT (binary data, > IIRC) when trying to deliver the quarantine message to postfix. Never > found out why, I stopped using dspam quarantine (and used tag and > deliver to spam folder). > > The original message as received by postfix has no problems. You could > try to find the postfix logs for the incoming message by looking at the > message id in the dspam quarantine, but the bug here is in dspam.
Perhaps related to this: http://marc.info/?l=dspam-users&m=132382086221854&w=2 To recap, the problem is that --user argument to the dspam binary ends up mangled when dspam delivers back through smtp to postfix. Like so, turning "firmapost" into "??D?n" : Dec 13 22:44:01 garbo dspam.cgi: Piping into |/usr/bin/dspam --deliver=innocent --class=innocent --source=error --user firmap...@alstadheim.priv.no -d %u Dec 13 22:44:02 garbo postfix/smtpd[14180]: connect from localhost[127.0.0.1] Dec 13 22:44:02 garbo postfix/smtpd[14180]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 550 5.1.1 < D n...@alstadheim.priv.no>: Recipient address rejected: User unknown in local recipient table; from=<> to=<??D?n...@alstadheim.priv.no> proto=SMTP helo=<localhost> But that was in 2011. Wietse
