|
|
12
|
|
Good evening,
I recently enabled reject_unverified_sender in my postfix configuration,
but it seems like it fails when the server against which the sender is
verified uses greylisting. I've been getting log entries like (@ were
replaced by _AT_):
Feb 8 07:56:49 atlas postfix/smtpd[25949]: NOQUEUE: reject: RCPT from
cpe-71-66-121-221.neo.res.rr.com[71.66.121.221]: 450 4.1.7 <kefxavediz
_AT_ xave.org>: Sender address rejected: unverified address: host
mail.odwulf.net[88.191.13.232] said: 450 4.2.0 <kefxavediz _AT_
xave.org>: Recipient address rejected: Greylisted, see
http://postgrey.schweikert.ch/help/xave.org.html (in reply to RCPT TO
command); from=<kefxavediz _AT_ xave.org> to=<jianlonghargett _AT_
agr848.org> proto=ESMTP helo=<ALS49DRAGONS.neo.rr.com>
Is that the expected behaviour? I'd expect that if
reject_unverified_sender encounters a soft bounce like this, that the
message should be queued for later testing. Is it possible to implement
this somehow?
Thanks in advance,
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...
|
|
|
On 2/8/2009, João Miguel Neves ( [hidden email]) wrote:
> I recently enabled reject_unverified_sender in my postfix configuration,
> but it seems like it fails when the server against which the sender is
> verified uses greylisting. I've been getting log entries like (@ were
> replaced by _AT_):
You're not trying to verify ALL senders are you? This ia a really bad
idea, and will get you blacklisted by a lot of providers, especially if
you have high traffic .
You should only perform SAV against servers that YOU control, or at
least have an agreement ahead of time with them.
--
Best regards,
Charles
|
|
|
Charles Marcus escreveu:
> On 2/8/2009, João Miguel Neves ( [hidden email]) wrote:
>
>> I recently enabled reject_unverified_sender in my postfix configuration,
>> but it seems like it fails when the server against which the sender is
>> verified uses greylisting. I've been getting log entries like (@ were
>> replaced by _AT_):
>>
>
> You're not trying to verify ALL senders are you? This ia a really bad
> idea, and will get you blacklisted by a lot of providers, especially if
> you have high traffic .
>
Yes, I was. Thanks for the heads up. I don't have high traffic, but I'm
limiting the effect of SAV.
> You should only perform SAV against servers that YOU control, or at
> least have an agreement ahead of time with them.
>
That would mean that the most useful use of SAV is negated. Or is there
some prior arrangement that would allow me to do that to hotmail.com,
gmail.com, yahoo.com*?
I'm going to reduce the target domains, but is there a known agreement
with MS, Google or Yahoo to use SAV against their servers?
Thanks in advance,
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...
|
|
|
On 2/9/2009 9:36 AM, João Miguel Neves wrote:
> That would mean that the most useful use of SAV is negated. Or is there
> some prior arrangement that would allow me to do that to hotmail.com,
> gmail.com, yahoo.com*?
>
> I'm going to reduce the target domains, but is there a known agreement
> with MS, Google or Yahoo to use SAV against their servers?
No...
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--
Best regards,
Charles
|
|
|
João Miguel Neves a écrit :
> Charles Marcus escreveu:
>> On 2/8/2009, João Miguel Neves ( [hidden email]) wrote:
>>
>>> I recently enabled reject_unverified_sender in my postfix configuration,
>>> but it seems like it fails when the server against which the sender is
>>> verified uses greylisting. I've been getting log entries like (@ were
>>> replaced by _AT_):
>>>
>> You're not trying to verify ALL senders are you? This ia a really bad
>> idea, and will get you blacklisted by a lot of providers, especially if
>> you have high traffic .
>>
> Yes, I was. Thanks for the heads up. I don't have high traffic, but I'm
> limiting the effect of SAV.
and how do you limit it? 71.66.121.221 is listed on zen.spamhaus.org
(via cbl) and spamcop (as well as Barracuda BRBL, SORBS, ... etc). it is
also a residential IP as can be seen from the rDNS (.res.rr.com).
>> You should only perform SAV against servers that YOU control, or at
>> least have an agreement ahead of time with them.
>>
> That would mean that the most useful use of SAV is negated. Or is there
> some prior arrangement that would allow me to do that to hotmail.com,
> gmail.com, yahoo.com*?
>
> I'm going to reduce the target domains, but is there a known agreement
> with MS, Google or Yahoo to use SAV against their servers?
>
No, and it won't help you anyway. spammers can easily use a valid
address. and these domains have too many users that most addresses
you'll test are valid! (did you never see the "sorry, this account is
not available" when trying to open an account?).
|
|
|
> -----Original Message-----
> From: [hidden email]
> [mailto: [hidden email]] On Behalf Of mouss
> Sent: Tuesday, 10 February 2009 8:39 AM
> To: [hidden email]
> Subject: Re: reject_unverified_sender vs greylisting
>
> João Miguel Neves a écrit :
>
> > Yes, I was. Thanks for the heads up. I don't have high traffic, but
> > I'm limiting the effect of SAV.
>
> and how do you limit it? 71.66.121.221 is listed on
> zen.spamhaus.org (via cbl) and spamcop (as well as Barracuda
> BRBL, SORBS, ... etc). it is also a residential IP as can be
> seen from the rDNS (.res.rr.com).
>
My simple solution to this is have a line in a client_access map of "res.rr.com REJECT Please relay mail via your ISP". I've more recently added biz.rr.com as well (and plenty of others). There is just a set of (mainly consumer) domains I'm not going to accept mail from. Also, Spamhaus Zen catches these.
|
|
|
On Mon, Feb 09, 2009 at 02:36:25PM +0000, João Miguel Neves wrote:
> That would mean that the most useful use of SAV is negated. Or is there
> some prior arrangement that would allow me to do that to hotmail.com,
> gmail.com, yahoo.com*?
Some Mailproviders explicitly forbid the use of SAV against their Mailsystems.
Some others provide false information depending on the SPAM-Filtersettings
of their users, others are just plain broken.
And the Information that < [hidden email]> is deliverable
has virtually no meaning regarding the SPAM-likelyhood of the incoming
e-Mail. SAV does not verify the authenticity of the sender address.
SAV is a nice idea if run against a limited set of trusted domains (who's
postmasters expclitly allow you to perform these Lookups), but it's not
such a good idea in general.
If everyone would use SAV, the ammount of SMTP traffic in the Internet
would *double*. I bet most heavy duty mailssystems don't scale double.
> I'm going to reduce the target domains, but is there a known agreement
> with MS, Google or Yahoo to use SAV against their servers?
Ask their Postmasters/Admins. If they say it's ok, do it.
|
|
|
On Tue, Feb 10, 2009 at 07:15:06AM +0100, Juergen P. Meier wrote:
> If everyone would use SAV, the ammount of SMTP traffic in the Internet
> would *double*. I bet most heavy duty mailssystems don't scale double.
An address probe is MUCH cheaper to process than a message. Address
probe results are cached. This estimate is likely substantially in error.
The main issue with SAV is that it can be abused to launch indirect
dictionary attacks, the target system sees connections from legitimate
MTAs doing SAV that are in turn address harvesting oracles for botnet
nodes forging sender addresses.
Another issue is that small domains that are victims of joe-job attacks
can temporarily see very high traffic loads if SAV is used by a high
volume provider (e.g. Verizon in the past).
Finally, some legitimate mail will be lost, as many developers tasked
with automating business-to-consumer email communications don't really
understand email, and just think of it as a "which API do I call to
send" problem. Questions of valid sender addresses, bounce processing,
... are foreign to them, and they are often tasking with sending messages
that could be important or time-sensitive for the recipients. SAV raises
the bar on poorly conceived/executed non-spam to a level where not all
important non-spam will continue to arrive.
These are good reasons to not use SAV or use it with caution:
- Your site should be small to very small, so that the probe
volume you emit is negligible.
- You should carefully choose which domains to SAV or exclude
from SAV.
--
Viktor.
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.
To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto: [hidden email]?body=unsubscribe%20postfix-users>
If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
|
|
|
mouss escreveu:
> João Miguel Neves a écrit :
>
>> Charles Marcus escreveu:
>>
>>> On 2/8/2009, João Miguel Neves ( [hidden email]) wrote:
>>>
>>>
>>>> I recently enabled reject_unverified_sender in my postfix configuration,
>>>> but it seems like it fails when the server against which the sender is
>>>> verified uses greylisting. I've been getting log entries like (@ were
>>>> replaced by _AT_):
>>>>
>>>>
>>> You're not trying to verify ALL senders are you? This ia a really bad
>>> idea, and will get you blacklisted by a lot of providers, especially if
>>> you have high traffic .
>>>
>>>
>> Yes, I was. Thanks for the heads up. I don't have high traffic, but I'm
>> limiting the effect of SAV.
>>
>
> and how do you limit it? 71.66.121.221 is listed on zen.spamhaus.org
> (via cbl) and spamcop (as well as Barracuda BRBL, SORBS, ... etc). it is
> also a residential IP as can be seen from the rDNS (.res.rr.com).
>
Right now, I'm preparing my top 10 domains used in spam and enabling SAV
for those.
>>> You should only perform SAV against servers that YOU control, or at
>>> least have an agreement ahead of time with them.
>>>
>>>
>> That would mean that the most useful use of SAV is negated. Or is there
>> some prior arrangement that would allow me to do that to hotmail.com,
>> gmail.com, yahoo.com*?
>>
>> I'm going to reduce the target domains, but is there a known agreement
>> with MS, Google or Yahoo to use SAV against their servers?
>>
>
> No, and it won't help you anyway. spammers can easily use a valid
> address. and these domains have too many users that most addresses
> you'll test are valid! (did you never see the "sorry, this account is
> not available" when trying to open an account?).
>
Picking up some data from 4h when SAV was enabled from all users I get:
426 delivered emails
1742 rejected emails
985 rejects from sender checks from which:
302 were queued at the sender for SAV unverified results (*)
671 were queued at the sender for SAV undeliverable results
Maybe is SHOULDN'T help, but seems like a LOT of spam is still coming
from non-existing addresses (about 31% of the total email).
(*) this is the number that scares me a bit - it can be thanks to
greylisting, or possibly a loop caused by other server using SAV. I'm
checking into that.
Best regards,
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...
|
|
|
Juergen P. Meier escreveu:
> SAV is a nice idea if run against a limited set of trusted domains (who's
> postmasters expclitly allow you to perform these Lookups), but it's not
> such a good idea in general.
> If everyone would use SAV, the ammount of SMTP traffic in the Internet
> would *double*. I bet most heavy duty mailssystems don't scale double.
>
I've seen this argument before, so I'd just like to notice that, IF that
traffic avoids a bounce message, the number of mail on the Internet
doubles only in the worst case, staying the same IF the filtering avoids
bounce messages.
I'm still analyzing SAV and it has some serious potential issues
(potential as in, I haven't studied it thoroughly).
>
>
>> I'm going to reduce the target domains, but is there a known agreement
>> with MS, Google or Yahoo to use SAV against their servers?
>>
>
> Ask their Postmasters/Admins. If they say it's ok, do it.
>
I'll try. Maybe I'll get an answer for the first time from them.
Thanks and best regards,
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...
|
|
|
On 2/10/2009, João Miguel Neves ( [hidden email]) wrote:
> Right now, I'm preparing my top 10 domains used in spam and enabling SAV
> for those.
Do you have their PERMISSION? If not, then DON'T... otherwise you risk
getting BLACKLISTED. I know that *I* will blackilist you for doing this,
and so will many, many others.
Did you read the info at the link I provided?
Using SAV just 'passes the buck' - please STOP passing YOUR problem on
to other INNOCENTS.
Besides, there are many other far more effective ways of minimizing spam.
--
Best regards,
Charles
|
|
|
Charles Marcus escreveu:
> On 2/10/2009, João Miguel Neves ( [hidden email]) wrote:
>
>> Right now, I'm preparing my top 10 domains used in spam and enabling SAV
>> for those.
>>
>
> Do you have their PERMISSION? If not, then DON'T... otherwise you risk
> getting BLACKLISTED. I know that *I* will blackilist you for doing this,
> and so will many, many others.
>
> Did you read the info at the link I provided?
>
> Using SAV just 'passes the buck' - please STOP passing YOUR problem on
> to other INNOCENTS.
>
> Besides, there are many other far more effective ways of minimizing spam.
>
Just a notice: I have SAV disabled, I'm studying in detail the link you
gave me and other information and trying to teach myself about SAV
before I touch it again. I'll come back to this list with my
conclusions, as it might be useful for someone else.
Thanks,
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...
|
|
|
Juergen P. Meier:
> If everyone would use SAV, the ammount of SMTP traffic in the Internet
> would *double*. I bet most heavy duty mailssystems don't scale double.
Go ahead and make my day. What is the basis for this claim?
Wietse
|
|
|
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=sendercalloutsOK, 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. 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).
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.
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?
--
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...
|
|
|
On Tue, 10 Feb 2009 18:49:05 +0000
Jo__o Miguel Neves < [hidden email]> 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.
>
> 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).
>
[snip]
> Have I missed anything?
>
Yes; your domain so that I can block it.
|
|
|
João Miguel Neves wrote:
> The SAV check in postfix is done with the postmaster address by default.
Recent postfix (2.5 and newer) use $double_bounce_sender as
the default for address_verify_sender. This recipient is
always valid, never delivered.
http://www.postfix.org/postconf.5.html#address_verify_senderUsing $double_bounce_sender has been found to cause fewer
compatibility problems than " [hidden email]" or "<>",
which some sites don't like as a sender.
--
Noel Jones
|
|
|
João Miguel Neves pisze:
> 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. 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).
Well, if you discard any message which can be "real" message (not
containing viruses etc.) just with typos, you just have no users to
complain they didn't get important emails. That's it. In that case
(private SMTP with few addressess and small traffic) you won't probably
get blacklisted. The other scenario (many users, big traffic) ends up
with your server blacklisted.
Anyways - those clients which you mention, are in first scenario (few
emails), or they don't use business cards and commercials in
non-electronic forms, or there was no one to tell them what they are
missing.
> 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.
>
That's not true. In some cases if you are checking envelope sender, you
can see <>. How do you think you can deal with it? While you can get few
thousands emails with forged return-path emails (existing or not - not a
problem). Now imagine that your server is not the only one which
received this amount of mails with same sender. Then you are performing
DDoS. Anyways - you should not bounce messages for non-existent users.
You should rather reject them (and that's efficient).
And what's the point of having catch-all address when you discard those
emails? Have on mind that you are still open to dictionary attacks. And
in most cases spammers don't care if your email is correct or not. Still
your emails are cool to be used for backscatter.
> 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?
Well, to be honest, I believe you did. If you will do many checks to the
same server (have on mind large ISPs with many domains) with different
emails, then probably your server will get blacklisted to send email
from postmaster@ (at least). If you want explanation why, here it is:
SMTP session to do SAV check is naither an email from individual to
individual, nor message from receiver's system to sender. Of course it's
also not wanted by sender, so in any case - it's spam and your server
should be treated like any other spamming server. You hopefully
understand my point of view. You don't have to agree - it doesn't matter.
Maybe this thread is a good reason to create BL containing servers doing
large amounts of SAV checks? I'd be very happy if I could use such BL to
reject emails from postmaster at those domains (and probably <> also).
Pawel Lesniak
|
|
|
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.
> 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.
> 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 bounces.
> 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.
> 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.
|
|
|
Paweł Leśniak escreveu:
> João Miguel Neves pisze:
>> 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. 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).
> Well, if you discard any message which can be "real" message (not
> containing viruses etc.) just with typos, you just have no users to
> complain they didn't get important emails. That's it. In that case
> (private SMTP with few addressess and small traffic) you won't
> probably get blacklisted. The other scenario (many users, big traffic)
> ends up with your server blacklisted.
> Anyways - those clients which you mention, are in first scenario (few
> emails), or they don't use business cards and commercials in
> non-electronic forms, or there was no one to tell them what they are
> missing.
Yes, the couple of clients that do that are aware of the cost.
>> 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.
>>
> That's not true. In some cases if you are checking envelope sender,
> you can see <>. How do you think you can deal with it? While you can
> get few thousands emails with forged return-path emails (existing or
> not - not a problem). Now imagine that your server is not the only one
> which received this amount of mails with same sender. Then you are
> performing DDoS. Anyways - you should not bounce messages for
> non-existent users. You should rather reject them (and that's efficient).
<> won't generate a sender check. So what would be the problem generated
by SAV here?
> And what's the point of having catch-all address when you discard
> those emails? Have on mind that you are still open to dictionary
> attacks. And in most cases spammers don't care if your email is
> correct or not. Still your emails are cool to be used for backscatter.
The catch-all doesn't apply here. Was just an example on how to avoid
dictionary attacks for probing addresses.
>> 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?
> Well, to be honest, I believe you did. If you will do many checks to
> the same server (have on mind large ISPs with many domains) with
> different emails, then probably your server will get blacklisted to
> send email from postmaster@ (at least). If you want explanation why,
> here it is: SMTP session to do SAV check is naither an email from
> individual to individual, nor message from receiver's system to
> sender. Of course it's also not wanted by sender, so in any case -
> it's spam and your server should be treated like any other spamming
> server. You hopefully understand my point of view. You don't have to
> agree - it doesn't matter.
Yes, I understand the point of view. I'm just trying to understand if it
is really worst or better in terms of resource consumption.
> Maybe this thread is a good reason to create BL containing servers
> doing large amounts of SAV checks? I'd be very happy if I could use
> such BL to reject emails from postmaster at those domains (and
> probably <> also).
It wouldn't be useful for you, as Noel Jones pointed out, postfix isn't
using postmaster for SAV since 2.5.
Best regards,
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...
|
|
|
Paweł Leśniak a écrit :
> [snip]
> Well, to be honest, I believe you did. If you will do many checks to the
> same server (have on mind large ISPs with many domains) with different
> emails, then probably your server will get blacklisted to send email
> from postmaster@ (at least). If you want explanation why, here it is:
> SMTP session to do SAV check is naither an email from individual to
> individual, nor message from receiver's system to sender. Of course it's
> also not wanted by sender, so in any case - it's spam and your server
> should be treated like any other spamming server. You hopefully
> understand my point of view. You don't have to agree - it doesn't matter.
>
> Maybe this thread is a good reason to create BL containing servers doing
> large amounts of SAV checks? I'd be very happy if I could use such BL to
> reject emails from postmaster at those domains (and probably <> also).
>
no reason to overreact. I am not seeing SAV abuse (but I am seeing
backscatter and spam).
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.
|
12
|
Locked
