Re: ****Re: ****Re: [OT] HELP!!! mail attack

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2008-03-28 at 10:17 -0700, Les wrote:
> On Fri, 2008-03-28 at 09:35 -0700, Craig White wrote:
> > On Fri, 2008-03-28 at 08:29 -0700, Les wrote:

> > > > 
> > > But is 99.99% delivery sufficient?  I receive more than 150 emails per
> > > day (ones that I am interested in), and every few days I need to receive
> > > certain emails about customer relations and ongoing projects.  99.99
> > > percent means I would miss one every 66 days.  If the one that I miss
> > > cost me a contract, it might not matter whether I received the rest or
> > > not.  Currently I have to parse through the junk mail locally and
> > > remotely about once a week.  the ISP junk folder often has more than
> > > 1200 emails in it.  THe local one about 30.  This adds about 1/2 day of
> > > overhead every week to recapture what should have come through.
> > > Personally I think the world needs to eliminate spam, or at least make
> > > every effort to seriously reduce it.
> > ----
> > but your example completely misses the point.
> > 
> > the 'Junk' directory is a result of some type of agent parsing accepted
> > e-mail, scoring it and redirecting it based on a score.
> > 
> > The point of greylisting is always about (or virtually always...depends
> > upon various implementations anyway) sender/recipient/smtp server
> > 'tuples' and 'Temporary Failure' /SMTP result codes 450 and whether the
> > sender attempts redelivery.
> > 
> > http://www.greylisting.org/
> > 
> > I would suggest that rather than prove the argument about the problems
> > with greylisting, you have proven the opposite because if you can lop
> > approximately 70% of that junk mail off the top via greylisting, you
> > wouldn't have to look through so much 'junk' to find the false positives
> > that inevitably occur with any type of spam scoring system.
> > 
> > Craig 
> 
> I cannot argue the value of greylisting.  But efficiency is in the eye
> of the beholder.  My time is limited.  My work valuable, and my customer
> correspondence is dictated by my customer, not my email policy.  I am at
> the mercy of the ISP here, and the customer.  Yet I am the one who
> suffers loss, not the ISP, not the customer who will find someone to do
> his work.  Yet you as the web person thinks this is effective.  I cannot
> speak to school systems, only professional uses.  Time is money and lost
> opportunity is even more valuable, resulting in loss that cannot be
> measured, yet ultimately may determine the success or failure of my
> business.
> 
> 	I would like to take this thought "out of the box".  The methods
> currently in place, grey listing, parsing for key words, and other
> simplistic means, while effective at reducing traffic are not really the
> desired solution by users, who would like 100% success in getting their
> desired email.  And while I cannot spout statistics about loss, I know
> it happens from personal experience.  The question at hand is how to
> avoid even more loss.  It is a quality issue, and today the quality
> standard is not 99.99%, it is 99.9999% (six nines or six sigma) in most
> industries.  To say that 99.99 is good enough is the path for GM and
> Ford, not Toyota and Nissan.  Think of it that way.  So how do we
> improve by two decades of quality in this "war" against spam?
----
greylisting is just one of a lot of tools available to the mail server
administrator - all of them are calibrated to minimize the junk mail
delivered to the end users and of course minimizing delivery failures
and false positive scoring by various mechanisms.

End users of course are the ones ultimately affected and you seemingly
want to open an end user discussion about a server level
technology...please don't as it won't provide clarity to anyone.

If you are losing e-mails, evaluate the filtering system that you use at
end user level and discuss the methodologies employed by your mail
provider with them.

Craig

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux