<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<pre wrap="">Claus, maybe this will make it less grey...
<span class="st">Greylisting</span> 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 essentially <span class="st">greylisting everything from Postini.
Internet > Postini > </span><span class="st">greylist-box > client Inbox. </span>
<span class="st">Greylisting</span> is only designed for this scenario:
<span class="st"> Internet > </span><span class="st">greylist-box > client Inbox. </span>
You will <i>have to</i> decide which method you want to roll with to make your life simpler. Together they will cause head-aches.
Now, I have been using <span class="st">Greylisting</span> 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. <a href="http://postgrey.schweikert.ch/">Postgrey</a> plugs right into it easily by configuring a <i>postfix config file</i>. This will get you 97% of the way home. My solution works on its own or with ms-exchange:
<span class="st">Internet > </span><span class="st">greylist-box > Exchange Server: client Inbox. </span>
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 out <a href="http://www.zimbra.com/learn/zimbra-demos-cheat-sheet.html">Zimbra</a>. 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't <a href="http://blog.zimbra.com/blog/archives/2009/09/announcing-zimbra-collaboration-suite-60-50-million-users-have-spoken.html">scale</a> 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.
</pre>
<pre class="moz-signature" cols="72">I Hope this helps,
Todd E Thomas
C: 515.778.6913
"It's a frail music knits the world together."
-Robert Dana
</pre>
<br>
On 11/23/2011 12:16 AM, Pixel // pinterface wrote:
<blockquote cite="mid:095501cca9a7$769635d0$3100a8c0@trinity"
type="cite">
<pre wrap="">Claus Niesen wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">
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:
<a class="moz-txt-link-freetext" href="http://postmaster.mbmacorp.com/">http://postmaster.mbmacorp.com/</a>
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.
</pre>
</blockquote>
</body>
</html>