On Sat, Dec 30, 2006 at 05:14:30PM +0100, Francois Petillon wrote:
> Marco d'Itri wrote:
> >For a start that sites performing sender verification will partecipate
> >in a DDoS on the mail infrastructure of domains forged by spammers.
> [...]
>
> There are two things I really dislike in sender verification. First, you
> are using someone else ressources to fight spam. Second, spammers may
> adapt in an annoying way (either they will use domains who always answer
> a 2xx to rcpt to, or they will use verified emails).
that's true, and IMHO the real reason why sender verify is harmful
(the latter, not the former).
> >Also, sender verification when seen from the side of the victims is
> >indistinguishable from a dictionary attack, and may cause deliverability
> >issues to the hosts attempting it.
>
> I confirm it : we already have blacklisted IPs as they were issuing too
> many rcpt-to on not existing emails. These were dued to sender
> verifications...
yeah, I know, you're very keen on blacklisting the whole earth :]
On Sun, Dec 31, 2006 at 03:44:40AM +0100, Francois Petillon wrote:
> Josip Rodin wrote:
> >Yes. Just like any other large amount of traffic could be harmful on
> >big domains.
>
> I will be more precise. Answering a rcpt-to is, in my case, around 20 to
> 30% of the job of the "storage cluster" to deliver a mail (I am not
> talking about CPU, just disks IOs). If the number of mails sent as from
> our domains is equivalent to the number of mails we receive and if
> everybody use sender verify, it would mean we have to increase our IOs
> capacity by 20 to 30% (I know, there is 2 "if" and it is a very rough
> figure).
Then honestly, you have a big problem. On the mail servers I
co-administrate, the database lookups that are performed at rcpt-to time
are far less CPU-intensive than the clamav check, and the bayesian
filter check that are done before our redirection service is activated.
If your system is correctly sized, your recipients database should fit
in RAM, and rcpt-to lookups costs 0 IO. So that argument is IMHO
pointless.
> > I guess the counter-argument could be - all those services are
> > explicitly created in order to voluntarily serve requests, but
> > nobody volunteered their server to answer sender verification
> > requests. Yet, a sender verification request is nothing but a
> > three-command SMTP conversation. If someone puts an SMTP server
> > online, and connects it via DNS, it's not exactly strange that other
> > people talk to it.
>
> No, a rcpt-to is not intended to verify an email but to deliver an mail.
> You may use VRFY if you want to 1) verify an email and 2) check if you
> are allowed to verify... :-)
bwahahaha, I suppose you know the amount of bad faith in such an
argument. Every serious SMTP server disables VRFY for obvious reasons.
And technically, I don't see which specifical task RCPT-TO should do on
your mail server than VRFY would not do.
> IMHO, using rcpt-to to verify sender is just like using resume download
> to do segmented/parallel downloads. It works but you are using the
> command in an perverted/antisocial way.
True, that's a perversion of the protocol. Though, you know, a lot of
antispam measures are protocol perversions, and should not be used if
you are so pure. For example, blacklisting someone because you /think/
he relays more than some fraction of spam[0], by shutting every
connection attempt with a 500 error is a very bad RFC violation,
specifically prohibited in the rfc 2821, whereas it's completely allowed
to issue a QUIT at any point of the SMTP dialog. So sender verifying is
at least 100% compatible with the RFC, even if diverting a command[1].
So if you see what I'm alluding to, maybe you should avoid to serve us
the SMTP white knight's arguments, from you that seems quite beyond
belief.
[0] obviously without trying to reach their abuse@ or postmaster@
address before, that would not be enough fun else.
[1] For the record, I don't like Sender Verify either, it has very
poor properties, but the sole argument against it, that has some
kind of value is that spammers can use it the same way to validate
their databases. Hence it can make genuine hosts be considered as
spammers, and that's A Bad Thing ™.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgpMNqiwdgfri.pgp
Description: PGP signature