postgrey question

Vizion vizion at vizion.occoxmail.com
Thu Jun 2 13:07:43 PDT 2005


On Thursday 02 June 2005 12:27,  the author Bart Silverstrim contributed to 
the dialogue on-
 Re: postgrey question: 

>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.

I do not know I buy that argument. The way I see it as a user of this list - 
it ain't broken as far as I am concerned and so I'd rather it not be fixed. 
My feeling is that you would be doing people a bigger favor by letting them 
sort out their own junk mail problem. It is not a listserver's job to fix it. 
It is up to the user/isp combination to fix.

My view is that as lo0ng as your set up the server to combat denial of service 
-- from then on it is up to the user to deal with any remaining spam. 
You may think there is a strong argument, for increasing the stringency of 
identification processes for people who do subscribe. 
You might wish to not just restrict postings from subscribers but also pass 
all postings from new subscribers through a rigorous spam filter for a month 
or two as well as adding a newbie character to identify them  in the subject 
line. You might think setting up a special email address for subscribers to 
forward copies of any spam that gets through so that a decision to cut off a 
subscriber can be made as quickly as possible. That is the way to end up 
doing a service to subscribers and other Internet users in the long run.

I say leave the rest to users and ISPs -  do not take on more responsibility 
than you need to
Whatever you decide to do has my support
David

-- 
40 yrs navigating and computing in blue waters.
English Owner & Captain of British Registered 60' bluewater Ketch S/V Taurus.
 Currently in San Diego, CA. Sailing May/June bound for Europe via Panama 
Canal.


More information about the freebsd-questions mailing list