Pat Traynor wrote: > Benny Pedersen wrote: > >but you can pastebin the rejected msg if possible then ask how to make > >that spam tagged before leveing your ip, possible do remove > >permit_mynetworks in postfix so only authed senders can spam, if that > >happens, then close that domain > > Pardon my ignorance, but is pastebin an external site for this sort of > thing?
The problem with discussing spam on any mailing list is is that it will be spam and will therfore be rejected by the anti-spam on the mailing list or on user's systems. Talking about the details of spam can therefore be difficulit. One typical solution is to take the message to be discussed and to post it to a pastebin site and then post just the URL to the message. That way anyone interested may look and then comment. There are many pastebin sites on the internet. http://pastebin.com/ is probably the best known. But there are many others. I don't think it really matters which one you would use. Note also that you can set an expiration such that the posting will automatically expire when you choose. I usually expire these types of pastes after one month. > However, I'm not seeing rejected messages. I'll just get a call from > one of my clients saying they're not getting email. I'll send a test > message to them, and see this in the maillog: > > Our system has detected an unusual rate of unsolicited mail > originating from your IP address. To protect our users from spam, mail > sent from your IP address has been temporarily rate limited. Please > visit http://www.google.com/mail/help/bulk_mail.html to review our > Bulk Email Senders Guidelines. At the same time that you see this happening if you look in your mail queue you will probably find other messages that are spam and are being rejected by google. You can look at those messages and determine details of the message. mailq ... look for mail addresses that are being rejected ... ... observe the queueid of the message ... postcat -q CB64C1BC3 | less That will emit the message along with other details to stdout where it can be browsed. Here I prefer the 'less' pager. But it could easily be redirected to a file (postcat -q CB64C1BC3 > spamfile) and so forth. If you know a message is spam then you can delete it from the queue as spam with "postsuper -d CB64C1BC3" and reduce the impact of the retries upon your site's reputation. The important things for me to look at are the originating client system that sent the message to your system. For example a spam that I am looking at. named_attribute: log_message_origin=unknown[123.64.199.228] named_attribute: log_helo_name=example.com recipient: hostmas...@example.net Postfix reports that the message came from 123.64.199.228, has no reverse DNS, the client system said it was regx.com (it's not, so I redacted it here) and the recipient address was to the hostmaster at a domain that I have obscured since it was forged. Things like the HELO name can be a clue. It is clearly a spammer if they say they are localhost, literally example.{com,net,org}, 127.0.0.1, other things. I like looking at the envelope information. Following that will be the standard mail headers. The first will be the one inserted by your system. That is the only one you can trust. Assume that all other headers inserted by other systems are forgeries. Trust only your own system's headers. And then the body of the message. The body is good for Bayes training. But otherwise the body is not so interesting. I find the envelope information to be the most useful. I suspect that if you look that you will find that you do have many samples of spam in your mailq. If you have not been looking it may be perhaps a lot! I have a cron task that runs periodically and does a brute force mailq piped to grep of custom patterns looking for some egregious things that I want to look for and if there is a hit then I am notified. Then I look, observe, learn, decide what I am going to do about it, do it, tune the ad-hoc grep patterns. Just to keep me on top of new types of spam that are causing problems. > >for your own domains, start with spf / dkim / dmarc > > > >and then only accept spf pass in mta stage, from that point you can begin > >whitelist if needed, but keep the whitelist in spf since a single ip can > >have a million domains :) > > I'm sorry, this is the "beyond my level of expertise" that I was referring to. Postfix has the potential for several different checks. One check for HELO (check_helo_access) . One check for the client system sending you the message (check_client_access). One check for the sender domain (check_sender_acces). And so forth. Details of postfix would be a better topic on the postfix-users list. Always remember that domains are trivially and routinely forged both by spammers and by real people just trying to send email. Many people routinely send mail forging their receive address. Therefore while the above suggestion is perfectly valid I tend to do nothing with domains. Instead I tend to blacklist or whitelist only client host IP addresses. However there is no single way. It takes a combined arms strategy of many different things in order to effectively deal with spammers. I say, do them all to some extent and then you will be mostly covered. :-) Bob
