Re: Spamcop's position on backscatter

2008-11-14 Thread mouss
D G Teed wrote: [snip] I'm afraid this is misunderstood, or I didn't explain it carefully enough. The ISP sending the bounce notification is my home ISP, not the ISP for my work. At home I run a small postfix which relays all outbound to my home's Cable ISP's SMTP. The Cable ISP's SMTP

Spamcop's position on backscatter

2008-11-13 Thread D G Teed
]) by acadiau.ca (Postfix) with ESMTP id D54454E4E1 for x; Mon, 10 Nov 2008 07:02:22 -0400 (AST) Message-ID: [EMAIL PROTECTED] From: ingelbert joachim x To: x Subject: ID MSG:81531 I am Julia, 27 y.o. Russia (dating) Is there anything more I can be doing? Does anyone feel Spamcop's position

Re: Spamcop's position on backscatter

2008-11-13 Thread Charles Marcus
On 11/13/2008, D G Teed ([EMAIL PROTECTED]) wrote: I'll report the smtpd related details here so those who want to know how it is set up can see. postconf -n output is preferred... all of it... -- Best regards, Charles

Re: Spamcop's position on backscatter

2008-11-13 Thread mouss
feel Spamcop's position on backscatter too simplistic? no evidence, no conclusion.

Re: Spamcop's position on backscatter

2008-11-13 Thread D G Teed
anyone feel Spamcop's position on backscatter too simplistic? no evidence, no conclusion. Here is what they say... http://www.spamcop.net/fom-serve/cache/329.html#bounces --Donald

Re: Spamcop's position on backscatter

2008-11-13 Thread Jim Berwick
D G Teed wrote: We send non-delivery responses. If someone emailed [EMAIL PROTECTED] mailto:[EMAIL PROTECTED], it will reject, saying that user doesn't exist. Our users expect this feature. If we told them bad addresses will cause email to be lost without notification, they would not be happy.

Re: Spamcop's position on backscatter

2008-11-13 Thread D G Teed
On Thu, Nov 13, 2008 at 11:58 AM, Charles Marcus [EMAIL PROTECTED]wrote: On 11/13/2008, D G Teed ([EMAIL PROTECTED]) wrote: I'll report the smtpd related details here so those who want to know how it is set up can see. postconf -n output is preferred... all of it... OK - IP, domain,

Re: Spamcop's position on backscatter

2008-11-13 Thread mouss
is a lreay server and you can't get the relay_recipient_maps, then you can use reject_unverified_recipient (only for selected domains). Does anyone feel Spamcop's position on backscatter too simplistic? no evidence, no conclusion. Here is what they say... http://www.spamcop.net/fom-serve

Re: Spamcop's position on backscatter

2008-11-13 Thread D G Teed
On Thu, Nov 13, 2008 at 2:14 PM, mouss [EMAIL PROTECTED] wrote: D G Teed wrote: What makes you believe I'm listed? I got a single report of a complaint. Have you not used the spamcop web interface before? never ever. should I? No, but as you said, some people report the wrong problem

Re: Spamcop's position on backscatter

2008-11-13 Thread Brian Evans - Postfix List
D G Teed wrote: On Thu, Nov 13, 2008 at 2:14 PM, mouss [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: If someone emailed [EMAIL PROTECTED] mailto:[EMAIL PROTECTED], it will reject, saying that user doesn't exist. Our users expect this feature.

Re: Spamcop's position on backscatter

2008-11-13 Thread mouss
D G Teed wrote: On Thu, Nov 13, 2008 at 2:14 PM, mouss [EMAIL PROTECTED] wrote: We send non-delivery responses. if these are user does not exist or filter thinks this is spam/virus and the like, then you are a backscatter source. I don't think we send NDRs as emails originating here. I think

Re: Spamcop's position on backscatter

2008-11-13 Thread mouss
Brian Evans - Postfix List wrote: D G Teed wrote: We user virtual_alias_maps and smtpd_client_restrictions = reject_unlisted_recipient is at the beginning of our list of restrictions. client restrictions are checked on connect. In the default setup (smtpd_delay_reject=yes), client, helo,