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

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

 



On Fri, 2008-04-11 at 16:16 -0700, Les wrote:
> On Fri, 2008-03-28 at 11:06 -0700, Craig White wrote:
> > 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.
> > 
> This is the same sort of nonsense that the carmakers spouted about
> quality in the 70's.  See where it got them.  
> This is an end user product.  Clarity is the way the user sees it, not
> the way the provider sees it.
> 
> 	I know there is no sense arguing this, I have dealt with engineers and
> quality issues for years.  The only way that attention comes is when
> someone provides the user with higher quality and the engineer is
> provided with a pink slip when his job goes away.
> 
> 	It is coming.  Wait for it... wait for it....
----
aside from your resurrecting a discussion that is 2 weeks old and
completely cold...

aside from your continued insistence to inject user level concerns on a
topic that was completely about SMTP/MTA administration...

aside from the fact that you have now tried to render a technical
discussion on strategic mail handling to a metaphor that has no
relevance...

I'd say you have contributed nothing to the discourse at all.

I will repeat...you are in control over your own e-mail.

If you don't like how your e-mail provider handles your e-mail, you can
change providers.

My comments on this topic were directly solely to a system administrator
handling a mail account that was job jobbed. How did this concern you? I
still have no idea.

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