Re: Preferred/maintained greylisting options?
On 21 May 2020, at 12:49, Charles Sprickman wrote: > I was wondering if greylisting might be a good option here. It's a matter of how much Nanking you are willing to do and how much legitimate mail your are willing to lose. The usual method of greylisting where you tell a server to try again later (4xx error) will cost you legitimate mail as many senders, including very large senders, will retry from different servers (google, Amazon). Others, in the idiotic belief they are being "secure", will never retry. Many of the latter are banks. Other forms off greylisting, like slowing the connection rate and making the transaction take a bit longer than usual are far more effective and less likely to cause issues with legitimate senders. Greylosting also really screws up the "authenticate your email right now. No, right this second. We sent you the code, enter it now in the next ten seconds or we delete your account and ban your IP" idiocy on the web that, nonetheless, some of us are forced to deal with. It's impossible to keep up with the list of domains doing that, especially when most of the verification emails originate from other servers. Postscreen, out-of-the-box, works exceptionally well and blocks more spam than any thing else I've used. Sure, I run SpamAssassin as well, but it sees very little use. Add an RBL or two, and it's kind of like magic. -- Knowledge equals power... --... Power equals energy... People were stupid, sometimes. They thought the Library was a dangerous place because of all the magical books, which was true enough, but what made it really one of the most dangerous places there could ever be was the simple fact that it was a library. Energy equals matter... --... Matter equals mass. And mass distorts space. It distorts it into polyfractal L-Space. --Guards! Guards!
Re: noreply email technisch und für Empfänger zum Ausdruck bringen
On 23 May 2020, at 08:52, Thomas wrote: > or The norm is to use an address along the lines you describe there. I use no-reply@. Emails to that address are accepted and discarded. Do not use a fake domain or someone else's domain, of course. You can certainly have the address be invalid so it generates a rejection, but which you chose is really just up to you. It is also normal to put a note in the email somewhere that says "do not reply to this email" or "the email address does not accept mail" or "emails too this address are deleted unread" or words to that effect. If this is a LEGAL issue, however, your country may have specific regulations on what exactly you can and cannot do. For example, it may require you to keep email that is delivered, so you may want to out-right eject the mails. -- 'I knew the two of you would get along like a house on fire.' Screams, flames, people running for safety…
Re: Preferred/maintained greylisting options?
> > I’ve been sort of opposed to greylisting in the past due to a userbase that’s > sensitive to delays, but… the spam is worse. > IMHO Greylisting is rather pointless. Its a blunt tool, and not only that it does that unforgivable thing of annoying genuine people. I would hazard a guess that if you are being innundated with spam, then your RBL setup is less than adequate. Both the choice of RBLs ***AND*** the correct configuration thereof is critical. I should also add that you should not be afraid to pay for access. The good lists will (a) block you if you hammer them with high volumes of requests (b) save some of their better content (or new innovations) for their paid subscribers. RBLs these days are pretty darn good, with everything setup correctly you can easily be in the very high 90-percentiles of catching spam and pretty much zero false-positives.
Re: Preferred/maintained greylisting options?
> On May 24, 2020, at 3:59 PM, Laura Smith > wrote: > >> >> I’ve been sort of opposed to greylisting in the past due to a userbase >> that’s sensitive to delays, but… the spam is worse. >> > > > IMHO Greylisting is rather pointless. Its a blunt tool, and not only that it > does that unforgivable thing of annoying genuine people. > > I would hazard a guess that if you are being innundated with spam, then your > RBL setup is less than adequate. Both the choice of RBLs ***AND*** the > correct configuration thereof is critical. As I described in my original email, this isn’t a failure of RBL setup. I’m just being inundated with: - Correctly configured hosts that don’t fail any obvious protocol checks - Hosts that are not on any RBLs until 5-10 minutes after delivering As I see it, I have limited options: - Do more filtering on content (blech - these only score +1 or so in SA) - Delay the mail (from non-whitelisted senders) until the hosts are listed. > I should also add that you should not be afraid to pay for access. The good > lists will (a) block you if you hammer them with high volumes of requests (b) > save some of their better content (or new innovations) for their paid > subscribers. I’ve trialed the major ones with no improvement. The greylisting suggestion came from Abusix because they looked up a day of “leaks” and found they were simply delivering before they were being listed. > RBLs these days are pretty darn good, with everything setup correctly you can > easily be in the very high 90-percentiles of catching spam and pretty much > zero false-positives. Sadly, we seem to be at the head of most spammer’s lists. One of these “paid” services should give us free access in return for a spamtrap. :) It’s also incredibly obvious there are some colos that are catering to these people, esp. that firm out of Buffalo… Charles >
Re: Preferred/maintained greylisting options?
Laura Smith writes: > I should also add that you should not be afraid to pay for access. The > good lists will (a) block you if you hammer them with high volumes of > requests (b) save some of their better content (or new innovations) > for their paid subscribers. We paid for access to spamhaus for a while, but they jacked up the prices and now its far too expensive even for their non-profit rate. What RBLs do people find to be effective now days? I was looking at SpamRats, which I did not know about before, but it looks decent. -- micah
Re: Preferred/maintained greylisting options?
> On 24 May 2020, at 13:05, Charles Sprickman wrote: > > > >> On May 24, 2020, at 3:59 PM, Laura Smith >> wrote: >> >>> >>> I’ve been sort of opposed to greylisting in the past due to a userbase >>> that’s sensitive to delays, but… the spam is worse. >>> >> >> >> IMHO Greylisting is rather pointless. Its a blunt tool, and not only that it >> does that unforgivable thing of annoying genuine people. >> >> I would hazard a guess that if you are being innundated with spam, then your >> RBL setup is less than adequate. Both the choice of RBLs ***AND*** the >> correct configuration thereof is critical. > > As I described in my original email, this isn’t a failure of RBL setup. I’m > just being inundated with: > > - Correctly configured hosts that don’t fail any obvious protocol checks > - Hosts that are not on any RBLs until 5-10 minutes after delivering > > As I see it, I have limited options: > > - Do more filtering on content (blech - these only score +1 or so in SA) > - Delay the mail (from non-whitelisted senders) until the hosts are listed. > >> I should also add that you should not be afraid to pay for access. The good >> lists will (a) block you if you hammer them with high volumes of requests >> (b) save some of their better content (or new innovations) for their paid >> subscribers. > > I’ve trialed the major ones with no improvement. The greylisting suggestion > came from Abusix because they looked up a day of “leaks” and found they were > simply delivering before they were being listed. > >> RBLs these days are pretty darn good, with everything setup correctly you >> can easily be in the very high 90-percentiles of catching spam and pretty >> much zero false-positives. > > Sadly, we seem to be at the head of most spammer’s lists. One of these “paid” > services should give us free access in return for a spamtrap. :) > > It’s also incredibly obvious there are some colos that are catering to these > people, esp. that firm out of Buffalo… I ran an ISP for a number of years and we had to deal with a lot of spam. When greylisting first became available, I added it into our mix of spam protection. While I don't recall the exact number, over 95% of received mail was blocked. There were a few issues with some legitimate mailers who refused to retry, eventually we whitelisted enough that our users had no issues. This worked because at that time virtually all spammers were drive-by spammers. They sent the email once, and didn't bother to queue it if it couldn't be delivered. The cost of diskspace and internet connections were too high for them. With time, those costs came down. Effectively today there is no additional cost to queue spam. Hence, virtually all the spammers are now using high quality mail servers like postfix. They seem to retry forever. Greylisting has become pretty much useless. When I disabled it a couple years ago, the spam levers did not increase by any measurable amount. We now use just 3 RBLs and that seems to be a relatively acceptable level of spam. -- Doug
Re: Preferred/maintained greylisting options?
Charles Sprickman: > Hi all, > > I have a site with a very old domain that's at the front of the > alphabet. For some reason (age, alphabetical order, ???) that > domain gets bombarded with spam before the senders make it onto > any of the blacklists I use (even trialed a few for-profit > blacklists). Literally some of these miss getting caught by 2-3 > minutes. Aside from the general jaw-on-floor reaction I have to > just how so many new 'clean' IPs are enlisted in these spamming > efforts on a daily basis, I was wondering if greylisting might be > a good option here. One of the folks that runs the Abusix service > suggested this since he pointed out that I'm really missing these > spammers by minutes > > What is your 'go to' greylisting solution these days? My main > concerns are that it's something that's well-maintained, does not > need babysitting, and is here for the long haul. > > I've been sort of opposed to greylisting in the past due to a > userbase that's sensitive to delays, but the spam is worse. With any form of greylisting you will need to whitelist senders that have a large pool of sending IP addresses. Those can take an excessive amount of time to whitelist, because each attempt is likely to come from a different IP address. I would suggest using postscreen (supported with Postfix) with postwhite for whitelisting large senders. Steve Jenkins wrote postwhite (available from github) for postscreen. It mines the SPF records from major email senders and creates a whitelist for their (outbound) IP addresses. Postwhite has been updated for some 6 years; and its data source, SPF records, isn't likely to change soon. Is that stable enough? Apply the whitelist as described on postwhite documentation, and enable some postscreen after-220 protocol test. You don't even have to drop clients that fail the test. postscreen_pipelining_enable=yes postscreen_pipelining_action=ignore postscreen's after-220 protocol tests implement a weaker form of greylisting (based on IP address only) that should eliminate most clients that are ahead of DNSBL lists. The clients won't know that it's fake greylisting. Wietse
Uninstalling postgrey
Based on another thread here, I want to move to using postscreen/postwhite and ditch postgrey. Just want to make sure I don't bungle stopping postgrey. So... - edit main.cf and remove "check_policy_service inet:127.0.0.1:10023" from smtpd_recipient_restrictions. - restart Postfix - purge the postgrey package. Then go about getting postscreen working. Thanks.
Re: Preferred/maintained greylisting options?
On Fri, May 22, 2020 at 5:43 AM Ralph Seichter wrote:
> Yeah, delays... Used to be people understood the difference between
> asynchronous messaging (i.e. email) and instant messaging. Nowadays it
> seems that no day goes by without somehing along these lines:
>
> "Hi. We have not seen you login using this browser, this IP address or
> during this week. Therefore we have just sent you an email containing
> a verification code, which will remain valid for 10 minutes."
Personally, I've hacked together a mixed SPF check + greylist milter.
If SPF check passes, the greylist is skipped, and any other result
("do not reject any mail" approach modulo greylisting) goes to greylist.
The companies which send such emails are likely (in my experience)
to have a properly setup SPF, so this solved these issues for me.
I'm not planning on releasing the source, it's really an ugly milter, but
I'm putting the idea out here - and maybe I'll learn it has already been
done and properly implemented...
Regards,
--
Vincent Pelletier
