reject_unverified_sender vs greylisting

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

jneves
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 | Threaded
Open this post in threaded view
|

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

Paweł Leśniak
In reply to this post by mouss-4
mouss pisze:
> no reason to overreact. I am not seeing SAV abuse (but I am seeing
> backscatter and spam).
>  
And I do under some circumstances. If I have SPF record, then I'm
helping the other side to check if mail with sender from my domain is
permitted or not. This means that sender already had to pass my tests
and was permitted by my server to send mail. Why in hell would I give
another resources to do checks which are *really* useless in such
configuration? I know that SPF is not the cure for everything, but in
war SPF vs SAV I prefer SPF which I can control rather than SAV which
can be abused with backscatter.

> let me fork a little: SAV on _header_ addresses is plain dumb:
>
> Dec 15 11:25:33 imlil postmx/smtpd[23878]: NOQUEUE: warn: RCPT from
> chlothar.bnv-bamberg.de[217.146.130.193]: Transaction logged:
> PTR=chlothar.bnv-bamberg.de; from=<[hidden email]>
> to=<[hidden email]> proto=ESMTP helo=<bnv-bamberg.de>
>
> if you post to the spamassassin-users list, and you log transactions,
> you'll see such probes.
>  
Have you any clue whether they do those probes if sender's domain has
SPF record? In case they do SAV if sender's domain is not using SPF/DKIM
I'd say it's acceptable for me.

Pawel Lesniak


Reply | Threaded
Open this post in threaded view
|

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

mouss-4
In reply to this post by jneves
João Miguel Neves a écrit :
> OK, I'll take that into consideration if I re-enable SAV.
>


if you re-enable SAV, do as much checks as you can. the minimum is
zen.spamhaus.org. but you can also use spamcop.

it would also be good to do it after greylisting, but this means your GL
server need to return a defer instead of defer_if_permit.

what you can also do is run a log parser that counts the SAV probes you
send, and disable the feature if some threshold is reached (rate limit
per client network, per sender domain, and global).  (an alternative is
a policy server that implements this, but a log parser is enough).

I was under the impression that you did it before zen check because the
log you posted has a client listed in zen. but I now realize it may have
been listed later.
Reply | Threaded
Open this post in threaded view
|

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

mouss-4
In reply to this post by Paweł Leśniak
Paweł Leśniak a écrit :

> [snip]
>> let me fork a little: SAV on _header_ addresses is plain dumb:
>>
>> Dec 15 11:25:33 imlil postmx/smtpd[23878]: NOQUEUE: warn: RCPT from
>> chlothar.bnv-bamberg.de[217.146.130.193]: Transaction logged:
>> PTR=chlothar.bnv-bamberg.de; from=<[hidden email]>
>> to=<[hidden email]> proto=ESMTP helo=<bnv-bamberg.de>
>>
>> if you post to the spamassassin-users list, and you log transactions,
>> you'll see such probes.
>>  
> Have you any clue whether they do those probes if sender's domain has
> SPF record? In case they do SAV if sender's domain is not using SPF/DKIM
> I'd say it's acceptable for me.
>

they do this on the From: header (not on the envelope sender address)
for mail resent by the spamassassin-users list. SPF will change nothing
here (I will obviously not put the apache servers in my SPF record,
should I add one). and yes, my mail is DKIM signed as you can see by
checking this message.

actually, another probes has ceased after I contacted his hoster's abuse
address. and it appears that some implementations based on exim do this
(SAV on the header address) by default. I am not sure if someone patched
exim to do this or if the "guy" was simply wrong.
Reply | Threaded
Open this post in threaded view
|

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

Charles Marcus
In reply to this post by jneves
On 2/10/2009 1:49 PM, João Miguel Neves wrote:
> 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.

Your conclusion is flawed.

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

Using catch-all for production mail servers is bad. It breaks recipient
validation - meaning, if Some Important Person sends an email to the
owner of one of the companies you are hosting, and typo's his email
address, the sender will NOT get an NDR, and will NOT know that his
important message was not delivered.

Security by obscurity simply does not work... it causes far more
problems than it solves, one of which is a FALSE sense of security.

> 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).
>
> SAV actually helps reduce the effect of the DDOS attack. In the non-SAV
> scenario, you get 30 million bounce messages. 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.

As I said, your conclusion is terribly flawed.

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

Every SAV your server performs is arguably an ABUSE of the server being
probed. For small sites, that abuse would be negligible and even
unnoticeable.

I agree with John. Please provide all IP addresses you are using so I
can block them all now.

--

Best regards,

Charles
Reply | Threaded
Open this post in threaded view
|

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

Paweł Leśniak
In reply to this post by mouss-4
mouss pisze:

> João Miguel Neves a écrit :
>  
>> OK, I'll take that into consideration if I re-enable SAV.
>>
>>    
>
>
> if you re-enable SAV, do as much checks as you can. the minimum is
> zen.spamhaus.org. but you can also use spamcop.
>
> it would also be good to do it after greylisting, but this means your GL
> server need to return a defer instead of defer_if_permit.
>
> what you can also do is run a log parser that counts the SAV probes you
> send, and disable the feature if some threshold is reached (rate limit
> per client network, per sender domain, and global).  (an alternative is
> a policy server that implements this, but a log parser is enough).
>
> I was under the impression that you did it before zen check because the
> log you posted has a client listed in zen. but I now realize it may have
> been listed later.
>  
And again my 5 cents. I think that people should take advantage of SPF
and/or DKIM records. If you'll check DKIM/SPF then you could for example
do SAV for clients/senders who are not allowed via SPF/DKIM or do not
provide those records. I believe this change is no cost for you, and is
saving some resources on both sides. Anyways whether you'll do SAV for
"bad" hosts or just reject emails from them is your choice. But no one
will blame you if you reject those emails, as you should be informed by
administrator (in terms of SPF/DKIM records) which hosts are permitted
to send (relay) - if you're given SPF record it should be correct, right?

Pawel

Reply | Threaded
Open this post in threaded view
|

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

jneves
In reply to this post by Charles Marcus
Charles Marcus escreveu:

> On 2/10/2009 1:49 PM, João Miguel Neves wrote:
>  
>> 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.
>>    
>
> Your conclusion is flawed.
>  
If the flaw is different from the one Pawel and mouss pointed out (I was
inventing bounces), could you please point it out?
> I agree with John. Please provide all IP addresses you are using so I
> can block them all now.
>  
I have no mail servers doing SAV at the moment. As I said before, I'm
studying this.

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 | Threaded
Open this post in threaded view
|

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

mouss-4
In reply to this post by Paweł Leśniak
Paweł Leśniak a écrit :

> mouss pisze:
>> João Miguel Neves a écrit :
>>  
>>> OK, I'll take that into consideration if I re-enable SAV.
>>>
>>>    
>>
>>
>> if you re-enable SAV, do as much checks as you can. the minimum is
>> zen.spamhaus.org. but you can also use spamcop.
>>
>> it would also be good to do it after greylisting, but this means your GL
>> server need to return a defer instead of defer_if_permit.
>>
>> what you can also do is run a log parser that counts the SAV probes you
>> send, and disable the feature if some threshold is reached (rate limit
>> per client network, per sender domain, and global).  (an alternative is
>> a policy server that implements this, but a log parser is enough).
>>
>> I was under the impression that you did it before zen check because the
>> log you posted has a client listed in zen. but I now realize it may have
>> been listed later.
>>  
> And again my 5 cents. I think that people should take advantage of SPF
> and/or DKIM records. If you'll check DKIM/SPF then you could for example
> do SAV for clients/senders who are not allowed via SPF/DKIM or do not
> provide those records. I believe this change is no cost for you, and is
> saving some resources on both sides. Anyways whether you'll do SAV for
> "bad" hosts or just reject emails from them is your choice. But no one
> will blame you if you reject those emails, as you should be informed by
> administrator (in terms of SPF/DKIM records) which hosts are permitted
> to send (relay) - if you're given SPF record it should be correct, right?
>


first, let's rule DKIM out of this. DKIM doesn't tell you "which hosts
are permitted". And DKIM verification requires getting the message DATA.
people want to reject a transaction before getting this data. In
addition, doing verification based on data requires a milter or a proxy
filter.

second, many of us ignore SPF at once. if you think it is good, go on.
but there will be no discussion on this list (it is taboo here. search
the archives).

12