Prevent blacklistings

We use google for email.  I have blocked smtp at the firewall on our network.

We recently just got blacklisted again... not sure how yet.... I will be looking into that... but in the meantime I am trying to figure out if this really needs to happen.

So say we have a spambot on our network... why should people be refusing email from google's servers?   It's not as if the spam bot on our network can send mail from googles servers.  I assume this probably has something to do with the fact our domain name has subdomains that point to the firewall for our network... and so it's being blocked because the domain on the email matches the domain tied to an IP that someone saw some spam from.  

I don't know a lot about it, but this seems excessive to me.  I mean, sure, block email originating from the same IP as the spam... but if it comes from an IP (i.e. google) that you don't see spam from, them why block it?  

In any case - is there something I can do, DNS wise, to prevent a spam bot on our network getting use blacklisted such that people are refusing our email send from google servers?  (Granted... I know we need to get rid of the spam bots.... but not interrupting our perfectly safe business email in the meantime would be preferable)
XetroximynAsked:
Who is Participating?
 
XetroximynAuthor Commented:
I figured out what happened... I temporarily disabled the smtp block on our network when I was toubleshooting something... (Setting up our NAS to send warning emails to me via googles smtp relay...)  (As you may have guessed the smtp block has an excaption for the NAS and certain servers that send warning emails to myself like this)

That said...

if you're using Gmail for mail, your block may (must) be coming from THEM, not the endpoint (recipient) -- otherwise, you wouldn't have even noticed it!
         if your messages are bouncing due to blacklists, you must NOT be sending via gmail's servers... you must be routing directly, which is out-of-compliance with your gmail hosting agreement...

Actually the block is from the endpoint servers... and I am seding through google, not directly smtp.... google sends a message back to me telling me the end recipients server rejected the message due to "greylist"

Technical details of temporary failure:
Google tried to deliver your message, but it was rejected by the server for the recipient domain redhat.com by mx1.redhat.com. [209.132.183.28].

The error that the other server returned was:
451 4.7.1 greylisted for 10 minutes and 0 seconds.

Open in new window



NOTE on being a good netizen: if you're using Gmail for mail, set your SPF record to indicate as much:
             v=spf1 include:_spf.google.com -all

Aha!  I guess this is it... I have spf set up to google but also our self for those limited cases where we send emails to ourselves... like warning emails from NAS's or scans emailed to ourselves from our scanner.  (the only devices that SMTP is not blocked for)

I guess that is why a black list on our IP, causes email from google to still be rejected?  Still seems really odd to me... So what I have 2 things listed in my SPF... if only one of them is blacklisted why block mail from the other one?

Guess I don't need to understand really... seems strange to me though
0
 
btanExec ConsultantCommented:
typically if you have client (or becoming a spambot) sending out bulk emails or bounce email storming out using the domain, the chance of blacklisting is pretty high. indeed it is to identify that client and block its outbound email..likely also that the client is infected with malware (like waledec) hence the spam storming. ideally is to clean up that client (or clients). See this use case
I recently took over a client network with the same issue as yours and was running into road blocks at getting them delisted with a few of the more questionable RBL list providers. So, I contacted my clients ISP and obtained a second public side IP address, setup a one-to-one NAT from the new public IP to the internal IP of the Exchange server, updated the DNS / MX / SPF / PTR records with the ISP and hoster, and the problem was resolved. I have since successfully removed the original public IP from all RBLs. This will provide some level of future protection in the event my client gets hit with another spambot, etc., in that the Exchange server public IP should not be affected by the issues with the browsing public IP.
an online  tool to check for spambot specifically
http://fspamlist.com/checkspammers/
http://cbl.abuseat.org/lookup.cgi (if are in the CBL listing, you can delist it, see its FAQ first)
http://mxtoolbox.com/ (checking your email server)

also other case is that your dns server is being used as inadvertently as Open DNS servers for recursive call OR email server being used as Open Relay to send out email storm per se and causing distress to other machine and in turn is being blacklisted. Do check out using dnstuff on your domain to see your DNS and Email (MX) checks on the security posture to further lockdown if required, replace the "google.com" with your domain e.g. http://www.dnsstuff.com/tools#dnsReport|type=domain&&value=google.com

Having publish SPF records and sign messages with DKIMused for email server and authentication will be good and if poss even to go for DNSSEC (they are part of the dnsstuff checks too...). Also make sure your client is not doing mass mailing from their Exchange server (as opposed to using a service like Exact Target or Constant Contact).

Regardless, further on the preventive front, some good practice to avoid being blacklisted are as below for considerations
To help ensure that your messages aren't flagged as spam, we also recommend that you:

Automatically unsubscribe users whose addresses bounce multiple pieces of mail.
Periodically send confirmation messages to users.
Include each mailing list they are signed up for, and offer the opportunity to unsubscribe from those in which they are no longer interested.
It's possible that your users forward mail from other accounts, so we recommend that you:

Explicitly indicate the email address subscribed to your list.
Support a URL method of unsubscribing from your mailing list (this is beneficial if your mailing list manager can't tell who is unsubscribing based on the 'Reply-to:' address).
If you send both promotional mail and transactional mail relating to your organization, we recommend separating mail by purpose as much as possible. You can do this by:

Using separate email addresses for each function.
Sending mail from different domains and/or IP addresses for each function.
If others use your service to send mail (for example: ISPs), you are responsible for monitoring your users and/or clients' behavior.  

You must have an email address available for users and/or clients to report abuse (abuse@yourdomain.com).
You must maintain up-to-date contact information in your WHOIS record, and on abuse.net.
You must terminate, in a timely fashion, all users and/or clients who use your service to send spam mail.
0
 
gheistCommented:
You need to monitor traffic, at least by recording all 25/tcp attempts or by netflow, for same traffic.
How do you think spambot bypasses firewalls that block the port?
0
Managing Security & Risk at the Speed of Business

Gartner Research VP, Neil McDonald & AlgoSec CTO, Prof. Avishai Wool, discuss the business-driven approach to automated security policy management, its benefits and how to align security policy management with business processes to address today's security challenges.

 
Daniel McAllisterPresident, IT4SOHO, LLCCommented:
OK - I was thinking about adding to this discussion, but it then dawned on me:
 - 1 - if you're using Gmail for mail, your block may (must) be coming from THEM, not the endpoint (recipient) -- otherwise, you wouldn't have even noticed it!
         if your messages are bouncing due to blacklists, you must NOT be sending via gmail's servers... you must be routing directly, which is out-of-compliance with your gmail hosting agreement...
 - 2 - if you're using Gmail for mail and your own IP address appears on a blacklist, other than being thorough and a good netizen, why do you care? You don't send LEGITIMATE mail from your own servers ANYWAY, so you shouldn't really care
       NOTE on being a good netizen: if you're using Gmail for mail, set your SPF record to indicate as much:
             v=spf1 include:_spf.google.com -all
       This way, if someone ACCEPTS mail from your own location (not GMAIL), it's their own fault -- you already TOLD them (in the SPF record) that your mail is supposed to come from Gmail

My point is that something is either fishy or missing here...

Dan
IT4SOHO
0
 
btanExec ConsultantCommented:
greylisting happens if either below happened.
an anti-spam technique whereby a recipient MTA does not allow a message triplet (Sending Server IP, Mail From and RCPT To combination) that has not been recorded as having successfully delivered an email within a configurable amount of time.
https://support.google.com/postini/answer/1408989?hl=en

a) you use to send email is not RFC 821 compliant

b) misconfigured to not automatically retry email messages that gets rejected with the "try later"-message. Maybe it's timing is off and it retries immediately (which it shouldn't)

c) recipient email server has got greylisting misconfigured, ie. an implementation that just doesn't let mails through even on later retries. Or maybe their error message is actually wrong: greylisting was not the reason your mail bounced - but something else.

Eventually, Google has this to say - Message delays due to greylisting. The long short is the whitelisting via SPF should work if those domain is added like google (which they have it done) and yours (which you added in).
With greylisting, the recipient domain temporarily rejects messages from IPs that it may not recognize, with the expectation that if the message is legitimate the sender will try again. However, Gmail may not always retry from the same IP. As a result, messages sent from Gmail to a domain that employs greylisting may be delayed.

If you are a domain owner and you're finding that messages from Gmail are delayed, we recommend not using greylisting, and instead use SPF or DKIM authentication to ensure fewer message delays from Gmail. If using SPF or DKIM isn't feasible, then we recommend whitelisting gmail.com and googlemail.com specifically.
But SPF is not foolproof, it fails if someone forwards email to another server.  By default, the forwarding server is not listed in the SPF entry and the destination mail server will (correctly) reject the email.
0
 
XetroximynAuthor Commented:
I figured out why the blacklisting happened on my own... but I appreciate everyone's advice!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.