Skip to main content

Greylisting hasn't blocked a single email

Comments

9 comments

  • Infopro
    i don't see a single email address where greylisting has refused to deliver.

    Where are you looking? If I look here: Home "Email "Mail Delivery Reports And I UNtick, Show Deliveries, Show Deferrals, Show In-Progress, leaving only, Show Failures and click Run Report, I see results like this one for example:
    Deferred due to greylisting. Host: '182.22.xx.xx' From: 'someuser @gmail.com' To: 'myclient @ example.com' SPF: 'softfail'
    When I click the looking glass for this entry under the Actions column, it shows me, Rejected.
    0
  • keat63
    in WHM >> Email >> GreyListing, under the reports tab. I have about 820 entries, everyone showing emails have been delivered.
    0
  • mtindor
    I've had greylisting configured now for about two weeks and looking in the log, i don't see a single email address where greylisting has refused to deliver. 800+ entries and every one has been delivered. So i'm guessing, we are really lucky and don't get as much spam as i thought or something isn't configured right. I know there are only 3 entries and a tick box to configure. What config settings work for others ?

    grep 'Deferred due to greylisting' /var/log/exim_mainlog If you don't see a lot of entries with that grep, or if you don't see any, your greylisting simply isn't enabled or isn't working. But that's a quick and easy way to tell if your server is greylisting at all. You can also look in /usr/local/cpanel/logs/cpgreylistd.log and see what the greylisting daemon is up to. If you "Bypass Greylisting for Hosts with Valid SPF Records" IS checkmarked, you can expect to accept quite a bit of spam that otherwise may have been deferred / never delivered. Most non-zombie spam these days does pass SPF / DKIM. So NOT whitelisting if SPF is valid will help you out a lot more. CAVEAT: If you do NOT checkmark that box, you can expect more customers to complain about delayed [and even possibly not delivered] legitimate emails, and you will have to get down and dirty in the logs and determine for them what IP addresses need to be whitelisted in order for those specific delayed or non-delivered mails to be delivered. So although greylisting is much more effective if you do NOT whitelist based upon valid SPF, you as a systems administrator will have more work on your hands. Mike
    0
  • keat63
    When running a mail delivery report, i see lots of "deferred due to grey listing", so I know that greylisting is working. However, if i go to GreyListing >> Reports, then any email beyond the first page have all been delivered. The ones on the first page that havn't been delivered are still in the so called GreyListing window. I would have expected to see some which havn't been delivered ??
    0
  • mtindor
    Hmm, well it sounds like whatever is sending you email is meeting the greylisting requirements to retry after a certain amount of time. If the sending iP meets those standards, then it goes through. Not sure there is anything you can do about that other than [if you know its spam] add the IP address or ###.###.###.##/## netblock to /etc/spammerips You should expect to see a lot of mail making it through greylisting [after having been deferred], because after all you do have legitimate email coming in, right? And you didn't say if you have whitelisting for hosts that pass SPF checkmarked or not . If you do, you can expect to not have a lot of spammer IPs go through the deferral to begin with. Did you adjust the greylisting settings, or are they default? The defaults work great for me. If you adjusted the greylisting timers, perhaps you adjusted them incorrectly and are making it too easy for sending IPs to pass through quickly and easily. mike
    0
  • feanorknd
    If you "Bypass Greylisting for Hosts with Valid SPF Records" IS checkmarked, you can expect to accept quite a bit of spam that otherwise may have been deferred / never delivered. Most non-zombie spam these days does pass SPF / DKIM. So NOT whitelisting if SPF is valid will help you out a lot more. Mike

    Hello: This is a problem along with Greylisting... there are too many important companies sending legit emails, but from 10/20 MTAs cluster, each one with different IPs... For one email, there are 10% possibilities that the current legit MTA retrying is the previously greylisted through IP... I mean, I have several cases where a legit mail, cannot arrive, just because greylisted data is being expired before the same MTA IP retries... there are many mail relays with different IPs sharing the spool of mails to retry. This way: - SPF pass could help a lot, just because this mail clusters are usually specified at SPF TXTs.... - If activate SPF pass, greylisted is just a poor antispam measure... I think, the good solution could be one of these: - using ability to whitelist by full/partial PTR match (Greylisting -- requesting enhancements) - IP match at greylisted database may not be /32 match.... I mean, if IP is trying to retry a mail and it belongs to /24 of an existing previous greylisted IP, the mail may be accepted. Why? the most of the time, all the MTAs are at the same /24... I think these two could be pretty more effective that a simple SPF validation to skip greylisting, cpanel guys. Regards.
    0
  • mtindor
    - using ability to whitelist by full/partial PTR match (Greylisting -- requesting enhancements) - IP match at greylisted database may not be /32 match.... I mean, if IP is trying to retry a mail and it belongs to /24 of an existing previous greylisted IP, the mail may be accepted. Why? the most of the time, all the MTAs are at the same /24...

    If cPanel implements this, I hope it is an admin-selectable option. I sure do not want this. auto-whitelisting other IPs in a /24 if a previously greylisted IP from that block makes it through simply assures that any spammers dumping spam from a larger block of IPs will be able to deliver their spam. On the other hand, I really hope cPanel would forget about what any ridiculous RFC says (who says rules can't change) and add the ability to whitelist based upon full/partial PTR despite the claim that it isn't part of the RFC. SMF-Grey and others have been providing this feature for years. It is very useful and works great. cPanel Folks: Please grab a copy of SMF-Grey off the web and see how they have inplemented whitelisting based upon full/partial PTR. Mike
    0
  • feanorknd
    If cPanel implements this, I hope it is an admin-selectable option. I sure do not want this. auto-whitelisting other IPs in a /24 if a previously greylisted IP from that block makes it through simply assures that any spammers dumping spam from a larger block of IPs will be able to deliver their spam. On the other hand, I really hope cPanel would forget about what any ridiculous RFC says (who says rules can't change) and add the ability to whitelist based upon full/partial PTR despite the claim that it isn't part of the RFC. SMF-Grey and others have been providing this feature for years. It is very useful and works great. cPanel Folks: Please grab a copy of SMF-Grey off the web and see how they have inplemented whitelisting based upon full/partial PTR. Mike

    I think whitelisting a C class is perfectly possible without risks, but only for same sender and same recipient... This way, for that sender/recipient, you may accept mails whitelisted from the C class, but not other emails... If the sender/recipient is different, the C class is not considered.
    0
  • RWH Tech
    I've seen no benefit from Greylisting on my server (low volume) and even had issues with Amazon deliveries (Looks to be a well-known issue). I am very happy with using abuseat, barracuda, reverse DNS and deny SPF failures to control spam. I disabled Bayes because I didn't want to deal with it screwing up due to training/poisoning issues.
    0

Please sign in to leave a comment.