postgrey question

[Bart Silverstrim]

On Jun 2, 2005, at 1:14 PM, Chad Leigh -- Shire.Net LLC wrote:

>
> On Jun 2, 2005, at 8:49 AM, Kirk Strauser wrote:
>
>> On Thursday 02 June 2005 06:54, Bart Silverstrim wrote:
>>
>>
>>> If people keep accepting broken implementation as the status quo, 
>>> we're
>>> going to keep getting people who leave broken implementations in 
>>> place.
>>>
>>
>> I have to agree with you on that one.  Greylisting is no more 
>> non-standard
>> than saying "I'm kind of having problems right now; please try again
>> later".  If a machine breaks on greylisting, then any number of other
>> unintentional problems with also break it.  On the positive side, so 
>> many
>> servers are adopting greylisting that I suspect servers that can't 
>> handle
>> it will get fixed rather quickly.
>
>
> That is not the issue though.  Lots of servers, especially public mail 
> providers,  have tried greylisting and rejected it because  their user 
> base complains that mail is delayed and they want to know that their 
> mail that their client, support people, etc just sent to them will get 
> there quickly, not 15 minutes, or 30 minutes, or whatever, later.  The 
> biggest problems with greylisting are not the broken servers who do 
> not retry -- you can work around them -- it is that the incoming mail 
> is delayed and users don't like it.  Now if you have a mail server 
> just for yourself or a special userbase this may not apply to you.  
> And this is why combining greylisting with spamassassin or other 
> antispam software is appealing -- you only grey list those mails you 
> have a good suspicion are actually spam.  You do not greylist all 
> mails and so your userbase is happy since their expected email is not 
> delayed.

According the postgrey's website, it supports automatic whitelisting, 
so in theory only a few emails from commonly-transacted email servers 
would be delayed.  After that their favorite emails will come in 
quickly as if they were whitelisted.

  In fairness, there are other factors that could delay an email with 
the same effect as greylisting.

Our users don't want to take the time to learn anything about managing 
their email properly, to do filtering at the MUA level, etc.  We still 
have users who would run executable attachments from spoofed senders in 
their email and wonder why their computer is suddenly acting funny.   A 
great many users abdicate responsibilities in order to not have to 
think...they want their ISP or sysadmins or techies to do the thinking 
for them.

This is a question of tradeoffs.  The problem with spam and abuse and 
malware has gotten to the point where I (and I suspect many others) no 
longer have the time or energy to keep chasing ways to make things 
better, and educating users can only be just so effective when they 
don't want to learn.

It's been a long day, I guess.  From what I can tell I'll probably be 
implementing postgrey, whether on the current server or on a rebuilt 
server, in the very near future.  BOFH or not, I'm tired of the 
spam/malware hammering us and the jerk spammers that do slip past, and 
if the users need to wait a few emails before a site becomes 
whitelisted, so be it.  If someone's email server is so broken that it 
can't handle a request to retry in a short future time, bleh.  I don't 
want their email and my users can complain to them until they fix their 
server.  I try to fix problems with my servers when they're brought to 
my attention.  Other people should try to do so as well, and if you 
make it inconvenient for your users to do business with them and 
encourage the users to complain to them about the problem or switch to 
another service, you'll end up doing a service to other Internet users 
in the long run.