reject_unverified_sender vs greylisting
Locked
12
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... |
Re: reject_unverified_sender vs greylisting
|
|
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 . > 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... |
Re: reject_unverified_sender vs greylisting
|
|
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 |
|
|
In reply to this post by jneves
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?). |
RE: reject_unverified_sender vs greylisting
|
|
> -----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. |
Re: reject_unverified_sender vs greylisting
|
|
In reply to this post by jneves
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. |
Re: reject_unverified_sender vs greylisting
|
|
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. |
|
|
In reply to this post by mouss-4
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). > 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?). > 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... |
|
|
In reply to this post by Juergen P. Meier
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... |
Re: reject_unverified_sender vs greylisting
|
|
In reply to this post by jneves
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. > 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... |
Re: reject_unverified_sender vs greylisting
|
|
In reply to this post by Juergen P. Meier
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 |
|
|
In reply to this post by Charles Marcus
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). 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... |
Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)
|
|
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). > > Have I missed anything? > Yes; your domain so that I can block it. |
Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)
|
|
In reply to this post by jneves
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_sender Using $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 |
Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)
|
|
In reply to this post by jneves
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). 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. > 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 |
|
|
In reply to this post by jneves
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. |
|
|
In reply to this post by Paweł Leśniak
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. >> 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). 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. 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... |
|
|
In reply to this post by Paweł Leśniak
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. |
«
Return to Postfix Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |