Re: [exim] UCEPROTECT, APEWS and the truth about Marc Perkel

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Rick Cooper
Dátum:  
Címzett: exim-users
Új témák: [exim] Advantages of using Sender Address Verification
Tárgy: Re: [exim] UCEPROTECT, APEWS and the truth about Marc Perkel


> -----Original Message-----
> From: exim-users-bounces@???
> [mailto:exim-users-bounces@exim.org] On Behalf Of Johann Steigenberger
> Sent: Monday, April 23, 2007 7:31 PM
> To: exim-users@???
> Subject: [exim] UCEPROTECT, APEWS and the truth about Marc Perkel
>
> Hi all,
> sorry to bug you with this thread, but we want to give you a
> statement
> after all those lies we have seen here by Marc Perkel here after he
> has started the thread: Who is APEWS?
>

[...]

> 3. SAV is a bad idea. It is not an Exim invention.
> It is an invention made by spammers, long before Exim had
> that "feature".
> Spammers are using the same technique for dictionary attacks.
>
> What Lusers as Marc Perkel do not understand is, that if
> there is a Spammer
> faking to be you@??? (assuming that would be your
> address) and he
> would
> send out 15 Millions of spammail with that forged from, you
> will get about 1
> Million
> "Verification Requests" from Systems around the globe, where
> each of them is
> just doing ONE try to "Verify" you@??? is deliverable.
>
> That results in a very high load on your server, and delays
> for your regular
> mails,
> because all of your sockets are busy with lamerz just
> "veryifiing" your
> address.


I just had a joe-job spam incident against one of our domains and let me
tell you I would MUCH prefer a million verification attempts to the
thousands of freaking postmaster bounces that include a portion of the
original email. See, in a prefect world every server that received the email
would have checked our spf records that list every conceivable host that
does/might deliver mail for our domain(s) and hard fails everything else.
It's not a prefect world and I got thousands of bounces (why did they accept
them in the first place) and "spam returns" that end up costing FAR more
since they end up being passed on the SpamAssassin and the virus checking
routines. We don't spam check or virus test verification attempts believe it
or not. The truth is sender verification should be the last test on the list
but it is valid, or acceptable for me on BOTH sides of the connection. Until
someone decides it's time to expand the protocol, or better yet design a
system that operates like DNS but has only the purpose of validating hosts
and users, this is a better tool. If a message makes it past all our other
tests to sender validation then we do verify the sender, and I must admit we
don't catch as many forged addresses as we did two years ago, but I think if
everyone stopped SAV the problem would return at an even heavier rate as
before.

>
> It is not the problem that you do it, the problem is that some million
> others are too.
> Millions of Systems connecting to one target at nearly the
> same time are
> the problem. That leads to a DDOS. And you are part of it ...
>
> And last not least:
> RFC 821 knows a command "VRFY" to do that test.
> Most Administrators have chosen to disable this, because Spammers were
> abusing it.


Exactly so what is left?


> Anyone trying to circumvent a restriction on a remote system
> is an Abuser.
> So faking to be a null sender and going up to RCPT TO means you are an
> Abuser.
> That is what Exim's SAV does.


Again, then what is the answer? Just open the door to anything just because
they say they are slkjjksd@???? Then accept their message, check it
for spam, then viruses and thank our stars all our resources are not being
taken up by a light weight helo/mail from/rcpt to: and are instead devoted
to the virtually resource free spam and virus checking? Boy, I know I would
much prefer all the disk thrashing of the former over the terribly expensive
latter.

Rick