Re: [OT] HELP!!! mail attack

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

 



On Thu, 2008-03-27 at 06:03 -0700, Craig White wrote:
> See, it's like this...
> 
> Greylisting issues a 450 code... Temporary Failure - why would you
> compare it to 'throwing away' ?

When it fails and doesn't work again, that's throwing it away.

> Temporary Failure codes are part and parcel of the SMTP protocol. It
> means try again later.
> 
> You don't have a clue what you are talking about.

I most certainly do.  You don't seem to have a clue about the difference
between theory and practice.  

When greylisting was first touted, I looked into it.  On the face of it,
it sounded simple and effective, but under the surface it has flaws,
like all other approaches to combating spam have.  Most other approaches
leave the recipient to deal with handling spam, this one throws back
mail in the face of the sender, who mayn't be able to do anything about
it, and your spam problems are hardly something that they should have to
deal with.

You are aware, I hope, that there's a lot of mail services that aren't
RFC compliant?  You should be aware that there most definitely are
reports of greylisting killing mail.  You should be aware that many
errors never get reported (making reliability reports as useless as
other statistics).  And that such reports, when they do get made, get
ignored or glossed over, as you're doing now.

As it stands, unless you vigorously read logs, or have a sender find
some way to notify you that they couldn't mail you, you will not know
anything about lost mail.

Anyone who argues that email shouldn't be a reliable mechanism is
skirting the issue.  It should be.  There's no excuse it not to be.

We know it isn't, of course, and greylisting is yet another thing that
makes it so.  It doesn't work 100% like people expect it to.  Yet some
seem to think it is, and try and convict you for heresy for daring to
say to.

And as I said before, go into this with your eyes open.  It *may* help,
it *will* hinder, and you generally won't know about the losses.  I
don't recommend destructive technologies.

I don't recommend hair-trigger anti-spam techniques.  I don't recommend
anti-spam systems that make users trawl through their junkmail box to
find that message that you sent earlier that they never saw.  There's
little point in filtering if you then have to double check by hand,
anyway.

I would recommend systems which have sufficient numbers of rules which
set very high levels of spam confidence (i.e. detected spam gets a very
high score for passing lots of bad rule checks), and that you only
filter spam with a very high confidence score.  I would recommend
honeypot schemes, where additional bogus addresses receiving mail are
marked as 100% confidence spam, and identical messages are killed in
transit to any other real addresses.

If we could rely on genuine mail being resent, then I would recommend
greylisting.  But we can't, so I won't.

When it comes to anti-spam systems, don't burden the person trying to
contact you.

-- 
(This computer runs FC7, my others run FC4, FC5 & FC6, in case that's
 important to the thread.)

Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.

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