[Cialug] Postini and Graylisting

[Todd E Thomas]

Claus, maybe this will make it less grey...

Greylisting  is a great method of spam blocking. So is Postini. But the 2 don't compliment each other. Pictures are good, so...

As Pixel said, you are essentiallygreylisting everything from Postini.
	Internet>  Postini>  greylist-box>  client Inbox.

Greylisting  is only designed for this scenario:
	Internet>  greylist-box>  client Inbox.

You will/have to/  decide which method you want to roll with to make your life simpler. Together they will cause head-aches.

Now, I have been usingGreylisting  for many years with great success. Coupled with Spam-Assassin it's an unbeatable solution for the cost, which is basically energy and time - no cost :)

If this appeals to you, bounce Exim, and try postfix. It's used more than anything else for a reason.Postgrey  <http://postgrey.schweikert.ch/>  plugs right into it easily by configuring a/postfix config file/. This will get you 97% of the way home. My solution works on its own or with ms-exchange:
	Internet>  greylist-box>  Exchange Server: client Inbox.


After Postgrey, pass it through spam-assassin and you'll be 99.9% spam-free. That's what I'm seeing. One of my clients got approximately 1,200 spam messages a day (multiply that by 5 additional users). Now they get a few per month, sometimes less.

If you don't want the hassle then check outZimbra  <http://www.zimbra.com/learn/zimbra-demos-cheat-sheet.html>. It has the best Web-mail UI in the business. Spam-Assassin rules are built when users right-click on a message and tag it as "Junk". Postgrey plugs right in. If you're using anything else you're making your job more difficult that it has to be. If you think it won'tscale  <http://blog.zimbra.com/blog/archives/2009/09/announcing-zimbra-collaboration-suite-60-50-million-users-have-spoken.html>  think again: Belgacom, Mediacom, Webmd, The DEA, et al, use it.

Or, if you don't have the time or inclination, sack it altogether and run with Postini. Its not as good as a hand-crafted system but it's close enough for jazz.


If you want the best and just don't have the time. I can help get you into the right solution. Call for details.


I Hope this helps,

Todd E Thomas
C: 515.778.6913
"It's a frail music knits the world together."
-Robert Dana





On 11/23/2011 12:16 AM, Pixel // pinterface wrote:
> Claus Niesen wrote:
>> I'm running my own email server and have been running it with gray
>> listing happily for many years.  Now I'm doing some beta testing for
>> a company that decided to send their emails through Postini and I
>> found out the hard way that I wasn't getting their emails.
>>
>> Postini (Google) apparently ignores the RFC 5321 Section 4.2.5&
>> 4.5.4.1 which states that failed emails must be queued and retried.
>> All I found was one attempt to send the email in my logs.
> We must be reading 4.5.4.1 differently.
>
>      ... mail that cannot be transmitted immediately MUST be
>      queued and periodically retried by the sender.
>
> I would consider "cannot be transmitted immediately" to be a rather
> different condition than "can be transmitted but was deferred by the
> receiving server".  E.g., the first might be satisfied by the client
> being offline, or having a network failure, whereas the second requires
> an ability to connect to the receiving server.
>
> At any rate, SMTP doesn't require any particular retry strategy.  If
> Postini wants to give up immediately, that's their call.  It's not a
> call I would necessarily agree with--there are plenty of reasons to
> issue a 4xy response that have nothing whatsoever to do with
> greylisting--, but c'est la vie.
>
>> What are you guys doing?  Are you really adding an exception for the
>> Postini SMTP servers?  If I do white list Postini's IPs how likely is
>> it that I get bombarded with spam through them?
> Greylisting isn't meant to be applied against real e-mail servers like
> Postini, it's meant to combat your typical pump-n-dump zombieware.  You
> know, the stuff you should be rejecting outright anyway because it
> doesn't have a PTR record, or has rDNS that looks something like
> 1.0.0.127.residential.some-isp.example.com.
>
> Greylisting is not terribly dangerous when the sending side only uses
> one IP (small operation); but when dealing with a larger mail
> sender--well, your first link to Postini explains probably the biggest
> problem with (most implementations of) greylisting, and it'll cause
> trouble for more than just Postini.  Many large mail systems attempt to
> send mail via one set of IPs immediately (fast lane), and retry on a
> separate set of IPs (slow lane).  That means even if you manage to
> accept the mail before it times out on the sending side it will likely
> be significantly delayed.
>
> I use Exim, rather than Postfix, so I can't help with your config, but I
> can tell you this: I don't use greylisting, /and/ I don't get much spam.
>
> Much of what I /do/ do is listed at:
>    http://postmaster.mbmacorp.com/
>
> As a rough idea, for the week of 11-13 to 11-20, my stats were roughly:
>    3000 mail attempts, 500 accepted, 100 deferred, 2500 rejected
>    Of those rejected messages:
>     44% rejected for lack of PTR
>     20% rejected for being on multiple DNSBLs
>      2% rejected for being on my local blacklist
>      2% rejected by SpamAssassin
>     <1% rejected by ClamAV
> With most of the remaining rejections for an assorted mixture of
> multiple failings.  Defers were almost entirely for transitory
> DNS issues.
>
> My acceptance rate for incoming mail was about 12%, which is a little
> high--I generally try to err on the accepting side, but it's also been a
> while since I've updated my local blacklist.
>
> And now I've probably completely obscured my point.  Yes, you should be
> exempting known mailservers from greylisting--especially large mail
> operations like Google, but really anybody listed in dnswl is going to
> be a sender with retries.  Greylisting won't prevent any spam from such
> sources; best case it will delay it, worst case you won't get the mail
> at all.
>
> Aside:
>
> You might also be interested in perusing the archives of the mailop
> list.  Archive are private, which means you'll have to sign up to read
> them (also means they aren't really searchable; sad!), but the list is
> very low traffic, and populated by people who run mailservers.
>
> There's also the SDLU list, which is higher traffic and oriented more at
> combating spam.  May or may not be useful.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cialug.org/pipermail/cialug/attachments/20111128/41a304f8/attachment.html>