Re: Spamcop's position on backscatter
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 attempts delivery to one of the MX servers at work. The user doesn't exist, so the Cable ISP must send a NDR to the sender - my home email account. If my email client at home used the Cable ISP's SMTP then I could see how it would reject rather than bounce, but because there is a relay early in the hops, that does not happen. I'm sure spammers can make the same thing happen. Then it's the home ISP problem. How the ISP deals with this problem may vary. some ISPs do nothing. others will discard undeliverable mail if the original sender isn't in their domain(s) (some extend this to a list of domains that the subscriber must declare), ... etc. Note that this problem is different from the general backscatter problem. Here, backscatter is caused by a submitted mail, not by mail sent to an MX that fails to validate recipients. In short, only subscriber machines can cause this backscatter. [snip]
Re: Spamcop's position on backscatter
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
D G Teed wrote: [snip] Is there anything more I can be doing? what is your problem exactly? are you listed on spamcop? if so, what IP are you talking about? what makes you believe you are listed because of backscatter? and why do you send backscatter (and what kind of bs)? Does anyone feel Spamcop's position on backscatter too simplistic? no evidence, no conclusion.
Re: Spamcop's position on backscatter
On Thu, Nov 13, 2008 at 12:05 PM, mouss [EMAIL PROTECTED] wrote: D G Teed wrote: [snip] Is there anything more I can be doing? what is your problem exactly? are you listed on spamcop? We are not listed on spam cop. There have been a couple of external reports I've seen in the last year. When I respond, I like to know I'm working with the best set up available. if so, what IP are you talking about? You need to know my IP as much as you need my address or phone number. It is irrelevant. We are not in block lists. I know how to check, and we have enough volume here that I'd learn pretty quickly if there was a problem. what makes you believe you are listed because of backscatter? What makes you believe I'm listed? I got a single report of a complaint. Have you not used the spamcop web interface before? and why do you send backscatter (and what kind of bs)? Why do you take a combative stance? We send non-delivery responses. If someone emailed [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. 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/cache/329.html#bounces --Donald
Re: Spamcop's position on backscatter
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. If you reject the invalid users during SMTP, you are not sending NDRs. It is the responsibility of the last server that accepted the message to send a NDR. If your server is actually sending the NDRs, you have something configured wrong as you are accepting and then later rejecting the emails.
Re: Spamcop's position on backscatter
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, and Trend's RBL license are obscured but otherwise contextually accurate ... alias_database = hash:/etc/postfix/aliases alias_maps = hash:/etc/postfix/aliases alternate_config_directories = /etc/postfix-alumni anvil_rate_time_unit = 60s anvil_status_update_time = 600s biff = no bounce_queue_lifetime = 2d bounce_size_limit = 2000 bounce_template_file = /etc/postfix/bounce.cf canonical_maps = pcre:/etc/postfix/lowercase,hash:/etc/postfix/genericstable command_directory = /usr/sbin config_directory = /etc/postfix content_filter = lmtp-amavis:[127.0.0.1]:10024 daemon_directory = /usr/libexec/postfix debug_peer_level = 2 disable_vrfy_command = yes fast_flush_domains = x1.mydomain.ca, x2.mydomain.ca, x3.mydomain.ca, x4.mydomain.ca html_directory = no in_flow_delay = 5s inet_interfaces = localhost,x5.mydomain.ca initial_destination_concurrency = 200 invalid_hostname_reject_code = 556 lmtp_sasl_auth_enable = no lmtp_sasl_security_options = local_recipient_maps = mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man masquerade_domains = !x6.mydomain.ca mydomain.ca maximal_backoff_time = 21600s message_size_limit = 1000 minimal_backoff_time = 10800s mydestination = mydomain = mydomain.ca myhostname = mydomain.ca mynetworks = 555.555.0.0/16, 127.0.0.0/8 mynetworks_style = class newaliases_path = /usr/bin/newaliases.postfix qmgr_message_active_limit = 2 queue_directory = /var/spool/postfix queue_run_delay = 500s rbl_reply_maps = hash:/etc/postfix/rbl_reply readme_directory = no recipient_delimiter = + relay_domains = relay_recipient_maps = relocated_maps = sample_directory = /etc/postfix sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtpd_authorized_xclient_hosts = 127.0.0.1,555.555.201.19 smtpd_client_connection_count_limit = 20 smtpd_client_connection_rate_limit = 60 smtpd_client_event_limit_exceptions = $mynetworks smtpd_client_message_rate_limit = 60 smtpd_client_restrictions = reject_unlisted_recipient, check_client_access cidr:/etc/postfix/client.cidr, check_sender_access hash:/etc/postfix/whitelist, check_recipient_access hash:/etc/postfix/recipient_access, check_client_access hash:/etc/postfix/access, reject_invalid_hostname, reject_unknown_client smtpd_data_restrictions = reject_unauth_pipelining smtpd_error_sleep_time = 10s smtpd_helo_required = yes smtpd_helo_restrictions = check_helo_access hash:/etc/postfix/helo_access, reject_invalid_hostname smtpd_recipient_restrictions = reject_unknown_recipient_domain, reject_unauth_destination, check_recipient_access hash:/etc/postfix/campus_overquota, check_recipient_access hash:/etc/postfix/recipient_access, check_sender_access hash:/etc/postfix/whitelist, check_client_access hash:/etc/postfix/access, reject_non_fqdn_recipient, reject_rbl_client LICENSEKEYOBSCURED.r.mail-abuse.com, permit smtpd_sasl_auth_enable = no smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/blacklist, check_sender_access hash:/etc/postfix/whitelist, check_client_access hash:/etc/postfix/access, reject_unknown_sender_domain, reject_non_fqdn_sender smtpd_timeout = 60s transport_maps = hash:/etc/postfix/transport unknown_address_reject_code = 550 unknown_client_reject_code = 555 unknown_local_recipient_reject_code = 550 virtual_alias_domains = $virtual_alias_maps, mydomain.ca virtual_alias_maps = hash:/etc/postfix/relocated hash:/etc/postfix/class_lists hash:/etc/postfix/virtual
Re: Spamcop's position on backscatter
D G Teed wrote: On Thu, Nov 13, 2008 at 12:05 PM, mouss [EMAIL PROTECTED] wrote: D G Teed wrote: [snip] Is there anything more I can be doing? what is your problem exactly? are you listed on spamcop? We are not listed on spam cop. There have been a couple of external reports I've seen in the last year. When I respond, I like to know I'm working with the best set up available. if so, what IP are you talking about? You need to know my IP as much as you need my address or phone number. It is irrelevant. We are not in block lists. I know how to check, and we have enough volume here that I'd learn pretty quickly if there was a problem. notice that I said: If so, which means if you are listed on spamcop, then which IP is listed. not that I want to know your IP, but simply to check that the IP is really listed. some people sometimes report the wrong problems, and we like to check. what makes you believe you are listed because of backscatter? 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? and why do you send backscatter (and what kind of bs)? Why do you take a combative stance? I did not. I was simply trying to understand what your problem is. I thought you were listed on spamcop because of BS and you didn't like it. so I asked for details. 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. If someone emailed [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. if address is typoeduser, then reject it during the smtp transaction while the untrusted client is still connected. once you accept mail, you should no more send bounces, except in few controlled situations. sure, losing mail is bad. but you should reject mail during the smtp transaction. if your postfix 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/cache/329.html#bounces many people agree with that document. see the BACKSCATTER README.
Re: Spamcop's position on backscatter
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 and I'd like to check. I guess if your mail server eats all email and you have no users whose accounts get compromised by phishing then you'd never need to see the spamcop report, even occasionally. 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 we reject emails. Maybe you can tell me. I test emailed a bogus address at work from home. My home ISP's SMTP server sent back a NDR, not my work's MX server. Inside the NDR from my home ISP's SMTP, I see reference to the name of one of the workplace MX servers, but the Reporting-MTA is that of the home ISP, not work's MX. If someone emailed [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. if address is typoeduser, then reject it during the smtp transaction while the untrusted client is still connected. once you accept mail, you should no more send bounces, except in few controlled situations. sure, losing mail is bad. but you should reject mail during the smtp transaction. if your postfix is a lreay server and you can't get the relay_recipient_maps, then you can use reject_unverified_recipient (only for selected domains). In this thread I've posted my postconf -n output. We user virtual_alias_maps and smtpd_client_restrictions = reject_unlisted_recipient is at the beginning of our list of restrictions. This causes email to be rejected for non-delivery. We do not relay to our Exchange or Cyrus server only to find out at that stage the email address does not exist. Our mapping file (virtual_alias_maps) is the complete list of all addresses and what final server they go to. [EMAIL PROTECTED][EMAIL PROTECTED] Does this not achieve the same result as using relay_recipient_maps ? --Donald
Re: Spamcop's position on backscatter
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. If we told them bad addresses will cause email to be lost without notification, they would not be happy. if address is typoeduser, then reject it during the smtp transaction while the untrusted client is still connected. once you accept mail, you should no more send bounces, except in few controlled situations. sure, losing mail is bad. but you should reject mail during the smtp transaction. if your postfix is a lreay server and you can't get the relay_recipient_maps, then you can use reject_unverified_recipient (only for selected domains). In this thread I've posted my postconf -n output. 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. reject_unlisted_recipient is not known until the recipient restrictions. This causes email to be rejected for non-delivery. We do not relay to our Exchange or Cyrus server only to find out at that stage the email address does not exist. Our mapping file (virtual_alias_maps) is the complete list of all addresses and what final server they go to. [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Does this not achieve the same result as using relay_recipient_maps ? virtual_alias_maps is a map that can rewrite an address across any address class. relay_recipient_maps is a verification map for relay_domains class. You basically will allow a catch all on the MX if a spammer knew the back end domain(s) with no relay_recipient_maps present. This may cause Backscatter. Your experience may vary of course. Brian
Re: Spamcop's position on backscatter
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 we reject emails. Maybe you can tell me. I test emailed a bogus address at work from home. My home ISP's SMTP server sent back a NDR, not my work's MX server. Inside the NDR from my home ISP's SMTP, I see reference to the name of one of the workplace MX servers, but the Reporting-MTA is that of the home ISP, not work's MX. That's still backscatter even if it is your ISP that generates it. if you ISP can't get the list of valid email addresses, it is better not to use it as an MX (and use your server instead). some providers now discard such mail (do not generate NDRs) because of backscatter. not ideal, but backscatter is a real problem (you know that when you get hit by a backscatter storm). PS. In this case, it is the ISP server that may be listed, not yours. In this thread I've posted my postconf -n output. We user virtual_alias_maps and smtpd_client_restrictions = reject_unlisted_recipient is at the beginning of our list of restrictions. This causes email to be rejected for non-delivery. We do not relay to our Exchange or Cyrus server only to find out at that stage the email address does not exist. Our mapping file (virtual_alias_maps) is the complete list of all addresses and what final server they go to. [EMAIL PROTECTED][EMAIL PROTECTED] Does this not achieve the same result as using relay_recipient_maps ? it's ok on your server. but the problem is on your ISP server. it is relaying mail without knowing the list of your valid recipients.
Re: Spamcop's position on backscatter
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, sender and recipient restrictions are performed at RCPT TO stage. so it is ok. [snip]
