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 12:02 -0430, Patrick O'Callaghan wrote:
> On Fri, 2008-03-28 at 08:29 -0700, Les wrote:
> > 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.
> 
> That's up to you, but if your business model is based on email never
> being lost then I suggest you need to rethink it. Email is a best-effort
> service. It works reasonably well precisely because it's not designed to
> be ultra-reliable.
> 
> An example: on our site, a university with about 20000 user accounts,
> eliminating greylisting would mean the collapse of our mail server (this
> isn't just a guess, it's based on real measurements) and consequent loss
> of many more emails than we might lose to false positives.
> 
> There are no hard and fast rules here. You need to understand your
> specific needs and situation and act accordingly.
----
Oh oh...Tim thinks you are sabotaging your mail system by implementing
greylisting and he would never hire you either.

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