mouss escreveu:
João Miguel Neves a écrit :
Charles Marcus escreveu:
Here's a link informing why indiscriminate use of SAV is bad, and what
it should be used for:

http://www.backscatterer.org/?target=sendercallouts
OK, I've finished reading and analyzing that text. My conclusion is that
there's no reason not to use reject_unverified sender.

In this answer I'm assuming 1) the postfix implementation of SAV and
that any implementation and 2) that MTAs implement the RFCs (so they
have a configuration that matches, for instance, the Book of Postfix).

There are 3 claims in that text:

1) That by disabling VRFY, a sysadmin has decided to disable all kind of
email address verification.

Most people disabled VRFY to prevent spammer tests for email addresses,
nothing else. If you want to disable all tests for email addresses you
accept all email for all email addresses, even non-existing ones and
later discard the invalid ones.

where did you get this? I disable VRFY because _I_ don't need it. you
have no business validating addresses on my server unless you want to
send me mail. my server is not here to help you filter your spam. I
already have my share.

I have no problem if the SAV client implements enough spam filtering
before knocking on my door, but this is not your case: you do SAV even
if the clien is listed in zen. you are free not to use zen, but you are
not free to mirror zen listed connections on my server.
Not the case. I'm doing SAV as the last anti-spam measure. Charles Marcus said that it shouldn't be part of my anti-spam measures, and I'm trying to understand if that's correct.
That's the only way to do it (and the
reason why some of my clients are using catch-all addresses that they
redirect to /dev/null).

2) That a spammer can create a DDOS using SAV.

You'll get a connection per server to which those were sent (postfix
caches the request, so it will only validate an email adress once)

you are confused. they send junk to N different servers. these different
servers have nothing to cache. they will then connect to my server to
validate the address. That's N smtp connections to my server.
OK, that's assuming 1 address per server. And yes, there's nothing to avoid that first probe. The page Charles indicated mentioned a 30 million address DDoS, so I assumed (perhaps wrongly) that it wouldn't mean only one message per server.
SAV actually helps reduce the effect of the DDOS attack. In the non-SAV
scenario, you get 30 million bounce messages.

why? I don't do SAV and I don't send bouncess
In the SAV cenario, each
server does one check per email adress (that costs you less bandwidth
and disk space than a Bounce message) and that single check will avoid
several bounce messages.
you are inventing bounces.
Sorry for that, you and Pawel are right.

The bounces only exist if the servers receiving the spam accept an email before validating the recipient address. I wrongly assumed that each email would generate a bounce. You're both right.

This means that there's no advantage in resources for the DDoS target for using SAV and that SAV can be used as an attack vector.
3) That SAV might create a loop.

The SAV check in postfix is done with the postmaster address by default.
If the target server does the same check back, then the SAV server
replies that postmaster is valid (assuming it's well-configured and
RFC-compliant).

Have I missed anything?
By using SAV, you want to filter _your_ spam using _my_ resources. If I
accept that, then it is a favour I am doing you. and I will only do this
favour if I think your are "nice":
- the minimum is to do enough checks before knocking my server.
- it must be easy to find who you are and how to contact you. This means
that if I see a probe in my logs, I must be able to find a web page to
know who you are and what you do, and you also must have a fully working
abuse address.
OK, I'll take that into consideration if I re-enable SAV.

Thanks for your input,
João Miguel Neves

--
Intraneia
http://www.intraneia.com/

Suporte a Software Livre
Tradução/Localização de software e sítios web
Desenvolvimento de software

Ao seu serviço...

Reply via email to