2009/5/23 Carlos Williams <carlosw...@gmail.com>: > Thanks for all the info and I guess I am still worried because the > user who the logs indicate is sending this message is 100% not sending > this. She has been on vacation for the past 2 weeks as no webmail > activity either. I used "postcat -q" to check the message ID and the > output is listed below:
Aha, are they using an autoresponder? As already stated, this sounds like someone is sending replies to spam. Spammers almost always forge the sender address, so autoreplies with go to invalid/incorrect destinations, and generally fail. You're probably seeing that failure here. > On Thu, May 21, 2009 at 8:58 PM, Sahil Tandon <sa...@tandon.net> wrote: >> s/message/queue/ :-) > > I have no idea what that means :-( That's sed-style search and replace (sed is a stream-based text editor); it means replace 'message' with 'queue', in whatever is being referred to; it's quite common to use as shorthand. > Yes, this scares me even more because the user indicated that she > herself is not initiating the message. The recipient domain is not > listening on port 25 so that is really the only reason I am aware that > there is a problem. If the SMTP server had accepted these messages, > nothing would have backed up on my Postfix queue. I just don't > understand what is causing this or how to stop this on my Postfix > server... We haven't suggested that your user is actively sending these messages. postqueue shows the sender address is 'MAILER-DAEMON', which basically means no real address (there's no return path). If your user sent it, the user's email address would probably be there. > Why do I keep getting these? How did they get this address to use for > bulk mail? You should basically assume that Bad People have your address nowadays. By all means don't post your address everywhere if you don't have to, but it's impossible to protect entirely. This is a sad fact of being on the internet. >> PS. make sure to validate recipients at the edge of your network, >> instead of accept-then-bounce. don't be an outscatter source... > > How do I make sure of this in main.cf? I'm not sure I know how to > avoid that based on my original postconf -n. This basically means not to accept mail that you can't deliver (reject it during the initial connection). Postfix is setup in a sane fashion by default, but this can break when you start doing filtering or forwarding, or a number of other things. If you cannot be sure you'll be able to get the message to the destination, you should not accept it. This used to be considered okay, but given that >90% of mail nowadays is spam, failure notifications in response to spam either don't get delivered, or go to innocent parties who never sent a message in the first place (due to forged addresses). I see you've got a content filter there, let's pretend it's a spamfilter instead of amavis. If it detects a spam message the options are to tag it and let it through, drop it, or send back a non-delivery message (a "bounce"). Dropping it is considered bad practice because a legitimate message might be incorrectly identified as spam; the sender doesn't know their message didn't get through, and the recipient doesn't see a message from their friend. Sending a bounce is bad because most mail is spam and most spam has a useless return path anyway. By tagging it, you can (hopefully) make it the the user's responsibility to filter out the spam based on a threshold. There's no trivial option to set in main.cf to Just Always Do The Right Thing; it'd be set correctly by default if there were such a thing! It means learning and understanding how the whole system works, which takes time and practice.
