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

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

 



On Thu, 2008-03-27 at 21:43 -0700, Craig White wrote:
> On Fri, 2008-03-28 at 12:45 +0900, John Summerfield wrote:
> > Craig White wrote:
> > >
> > 
> > > 
> > > You are correct of course, that nowhere does it state that sender MUST attempt to re-deliver. I do wonder if you would find an SMTP server that by default didn't attempt re-delivery on temporary failures to be acceptable. It MUST be configurable - that's it. 
> > 
> > 
> > Okay, so Tim wasn't sure, but now we agree retrying, while it might be 
> > good practice isn't essential.
> ----
> not essential in that the RFC does not say MUST
> 
> essential only if the intent was to surely deliver e-mail
> ----
> > 
> > I've just done a "host -t mx" for several companies. Most have four mail 
> > exchangers, one had a dozen. While those are for incoming email, it's 
> > likely that they generally have a similar number for outgoing email. 
> > Without information, I assume that to be so. In many cases they will be 
> > the same machine.
> > 
> > I don't know what their retrying policies are, but I can imagine that 
> > retrying might involve an attempt by each of several machines, each 
> > getting a 4XY response.
> > 
> > It might be a lengthy delay, it might result in email getting returned 
> > to sender.
> > 
> > Tim is right in his belief that greylisting can cause delivery problems. 
> > You don't have to think it's as big a problem as he does, but I don't 
> > criticise him for seeing it as a risk he doesn't want to take.
> > 
> > 
> > Here is one list of recommended delays between retries:
> > http://www.mailenable.com/Help/Files/smtpdelivery.htm
> > 
> > 
> > The use of fake mx records suggested here looks enticing:
> > http://wiki.apache.org/spamassassin/OtherTricks
> > 
> > I discontinued using a second mx because it seemed only to receive spam, 
> > and senders _should_ retry if I'm not listening.
> ----
> the 'fake mx records' suggests the use of Temp Fail codes on the highest
> fake MX
> 
> *** sigh *** 
> 
> I guess that if you think that NOT running greylisting means you get
> delivery 100% of the time and running greylisting means that you only
> get delivery 99.99% of the time (referring of course only to legitimate,
> non-UBE e-mail) then you must be be indulging in willful sabotage and
> not worthy of hire (Tim's words).
> 
> Temp Fail codes exist, are stipulated and understood by RFC and by ALL
> SMTP servers.
> 
> The alternative is to run user level spam filtering. I submit that it is
> for most businesses, a stupid, wasteful, inefficient plan but I
> acknowledge that ISP servers cannot necessarily adopt these aggressive
> tactics.
> 
> Craig
> 
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.

Regards,
Les H

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