Spamcop's position on backscatter

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Spamcop's position on backscatter

D G Teed-2
Occassionally I see a spamcop.net report on backscattered email.

Our MXes forward to three other servers, so we use virtual_alias_maps,
set up with a mapping for every email account, and
we set smtpd_client_restrictions = reject_unlisted_recipient
amongst other restrictions.

I'll report the smtpd related details here so those who
want to know how it is set up can see.

smtpd_recipient_restrictions = reject_unknown_recipient_domain, reject_unauth_destination, check_recipient_access hash:/etc/postfix/user_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 MYLICENSEKEYISHEREBYOBSCURED.r.mail-abuse.com, permit

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_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_helo_restrictions = check_helo_access hash:/etc/postfix/helo_access, reject_invalid_hostname

virtual_alias_domains = $virtual_alias_maps, mydomain.ca

virtual_alias_maps = hash:/etc/postfix/relocated hash:/etc/postfix/class_lists hash:/etc/postfix/virtual
/recipient

I believe we are doing the right thing to prevent backscatter email queuing.
If there is room for improvement, I'd like to learn anything missing/wrong
with the above.

Our users normally want others to learn of bounces for things like
typo'ed addresses.  So we are not going to turn off non-delivery messages.

Spamcop's FAQ on backscatter and prevention "Misdirected bounces" implies
there is something we can do to prevent this.  In my understanding, my
postfix set up does what spamcop is asking to be done:

"Configure your software to either reject messages during delivery or accept them permanently."

Yet there are occassionally users reporting our MX to spamcop (even though the originating
IP of the backscatter is listed in the header trace in the attached Delivery Report).

Received: from acadiau.ca ([127.0.0.1])
by localhost (x3.mydomain.ca [127.0.0.1]) (amavisd-new, port 10024)
with LMTP id Tfd1qCE4QYv1 for <x>;
Mon, 10 Nov 2008 07:02:24 -0400 (AST)
Received: from 212-34-112-114.domolink.elcom.ru (212-34-112-114.domolink.elcom.ru [212.34.112.114])
by acadiau.ca (Postfix) with ESMTP id D54454E4E1
for <x>; Mon, 10 Nov 2008 07:02:22 -0400 (AST)
Message-ID: <000a01c94323$021a53ee$f7d27a84@hokrfc>
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 on backscatter too simplistic?


--Donald

Reply | Threaded
Open this post in threaded view
|

Re: Spamcop's position on backscatter

Charles Marcus
On 11/13/2008, D G Teed ([hidden email]) 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
Reply | Threaded
Open this post in threaded view
|

Re: Spamcop's position on backscatter

mouss-2
In reply to this post by D G Teed-2
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.



Reply | Threaded
Open this post in threaded view
|

Re: Spamcop's position on backscatter

D G Teed-2
On Thu, Nov 13, 2008 at 12:05 PM, mouss <[hidden email]> 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
[hidden email], 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.
Reply | Threaded
Open this post in threaded view
|

Re: Spamcop's position on backscatter

Jimbo-3
D G Teed wrote:
> We send non-delivery responses.  If someone emailed
> [hidden email] <mailto:[hidden email]>, 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.
Reply | Threaded
Open this post in threaded view
|

Re: Spamcop's position on backscatter

D G Teed-2
In reply to this post by Charles Marcus


On Thu, Nov 13, 2008 at 11:58 AM, Charles Marcus <[hidden email]> wrote:
On 11/13/2008, D G Teed ([hidden email]) 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 = 10000000
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 = 20000
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


Reply | Threaded
Open this post in threaded view
|

Re: Spamcop's position on backscatter

mouss-2
In reply to this post by D G Teed-2
D G Teed wrote:

> On Thu, Nov 13, 2008 at 12:05 PM, mouss <[hidden email]> 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
> [hidden email], 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.

Reply | Threaded
Open this post in threaded view
|

Re: Spamcop's position on backscatter

D G Teed-2
On Thu, Nov 13, 2008 at 2:14 PM, mouss <[hidden email]> 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
[hidden email], 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.

[hidden email]            [hidden email]

Does this not achieve the same result as using relay_recipient_maps ?

--Donald

Reply | Threaded
Open this post in threaded view
|

Re: Spamcop's position on backscatter

Brian Evans - Postfix List
D G Teed wrote:

> On Thu, Nov 13, 2008 at 2:14 PM, mouss <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>         If someone emailed
>         [hidden email] <mailto:[hidden email]>, 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.
>
> [hidden email] <mailto:[hidden email]>          
> [hidden email] <mailto:[hidden email]>
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Spamcop's position on backscatter

mouss-2
In reply to this post by D G Teed-2
D G Teed wrote:

> On Thu, Nov 13, 2008 at 2:14 PM, mouss <[hidden email]> 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.
>
> [hidden email]            [hidden email]
>
> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Spamcop's position on backscatter

mouss-2
In reply to this post by Brian Evans - Postfix List
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]
Reply | Threaded
Open this post in threaded view
|

Re: Spamcop's position on backscatter

D G Teed-2
In reply to this post by mouss-2
On Fri, Nov 14, 2008 at 3:42 AM, mouss <[hidden email]> wrote:
D G Teed wrote:
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).

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.

I will include the bounce notification to make it
clear.  myworkdomain.ca is the domain at work,
mypersonaldomain.ca is where I'm sending the email
from, and myhomecableisp is the Cable company ISP
for home.  The test is sending an email to an
non-existant addres at work, from home.

=========================================

From [hidden email] Thu Nov 13 15:08:33 2008
Date: Thu, 13 Nov 2008 15:08:23 -0400 (AST)
From: Internet Mail Delivery <[hidden email]>
To: [hidden email]
Subject: Delivery Notification: Delivery has failed

This report relates to a message you sent with the following header fields:

  Message-id: <[hidden email]>
  Date: Thu, 13 Nov 2008 15:08:18 -0400 (AST)
  From: D Teed <[hidden email]>
  To: [hidden email]
  Subject: test

Your message cannot be delivered to the following recipients:

  Recipient address: [hidden email]
  Reason: Remote SMTP server has rejected address
  Diagnostic code: smtp;550 5.1.1 <[hidden email]>: Recipient address rejected: User unknown in virtual alias table
  Remote system: dns;mx1.myworkdomain.ca (TCP|10.10.10.82|24168|131.162.201.19|25)


    [ Part 2: "Delivery Status" ]

Reporting-MTA: dns;mta02.myhomecableisp.ca (tcp-daemon)

Original-recipient: [hidden email]
Final-recipient: [hidden email]
Action: failed
Status: 5.1.1 (Remote SMTP server has rejected address)
Remote-MTA: dns;mx1.myworkdomain.ca (TCP|10.10.10.82|24168|555.555.201.19|25)
Diagnostic-code: smtp;550 5.1.1 <[hidden email]>: Recipient address
 rejected: User unknown in virtual alias table


    [ Part 3: "Included Message" ]

Date: Thu, 13 Nov 2008 15:08:18 -0400 (AST)
From: D G Teed <[hidden email]>
To: [hidden email]
Subject: test

=========================================

I hope this detail will help in determining if there is room
for improvement.

In the meantime I will see if relay_recipient_maps
and relay_domains can be made to work on a dev box.

I have also learned there was at least
one message we did send out as a bounce from our MX
(related to the single spamcop report I had).
It was during a maintenance cycle where old accounts
were deleted from a mailbox server.  There would have
been a gap of a few minutes between that and our
virtual table being updated, and in that time postfix
didn't have an accurate list in virtual map.

--Donald

Reply | Threaded
Open this post in threaded view
|

Re: Spamcop's position on backscatter

mouss-2
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]