DevHeads.net

Spamcop's position on backscatter

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>

Is there anything more I can be doing?

Does anyone feel Spamcop's position on backscatter too simplistic?

--Donald

Comments

Re: Spamcop's position on backscatter

By mouss at 11/13/2008 - 12:05

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)?

no evidence, no conclusion.

Re: Spamcop's position on backscatter

By D G Teed at 11/13/2008 - 12:51

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.

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 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
<a href="mailto: ... at mydomain dot ca"> ... at mydomain dot ca</a>, 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.

Here is what they say...

<a href="http://www.spamcop.net/fom-serve/cache/329.html#bounces" title="http://www.spamcop.net/fom-serve/cache/329.html#bounces">http://www.spamcop.net/fom-serve/cache/329.html#bounces</a>

--Donald

Re: Spamcop's position on backscatter

By mouss at 11/13/2008 - 14:14

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.

never ever. should I?

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.

if these are "user does not exist" or "filter thinks this is spam/virus"
and the like, then you are a backscatter source.

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).

many people agree with that document. see the BACKSCATTER README.

Re: Spamcop's position on backscatter

By D G Teed at 11/13/2008 - 16:09

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.

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.

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.

<a href="mailto: ... at mydomain dot ca"> ... at mydomain dot ca</a> <a href="mailto: ... at exchange dot mydomain.ca"> ... at exchange dot mydomain.ca</a>

Does this not achieve the same result as using relay_recipient_maps ?

--Donald

Re: Spamcop's position on backscatter

By mouss at 11/14/2008 - 03:42

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.

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

By D G Teed at 11/14/2008 - 12:17

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 <a href="mailto: ... at myhomecableisp dot ca"> ... at myhomecableisp dot ca</a> Thu Nov 13 15:08:33 2008

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

Message-id: <Pine.LNX.4.64.0811131508070. ... at blackbox dot localdomain.domain>

Your message cannot be delivered to the following recipients:

Recipient address: <a href="mailto: ... at myworkdomain dot ca"> ... at myworkdomain dot ca</a>
Reason: Remote SMTP server has rejected address
Diagnostic code: smtp;550 5.1.1 < ... at myworkdomain dot ca>: 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:
rfc822; ... at myworkdomain dot ca<rfc822% ... at myworkdomain dot ca>
Final-recipient:
rfc822; ... at myworkdomain dot ca<rfc822% ... at myworkdomain dot ca>
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 < ... at myworkdomain dot ca>: Recipient
address
rejected: User unknown in virtual alias table

[ Part 3: "Included Message" ]

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

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

Re: Spamcop's position on backscatter

By mouss at 11/14/2008 - 15:03

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.

Re: Spamcop's position on backscatter

By Brian Evans - P... at 11/13/2008 - 16:22

client restrictions are checked on connect.
reject_unlisted_recipient is not known until the recipient restrictions.

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

By mouss at 11/14/2008 - 03:44

In the default setup (smtpd_delay_reject=yes), client, helo, sender and
recipient restrictions are performed at RCPT TO stage. so it is ok.

Re: Spamcop's position on backscatter

By Jim Berwick at 11/13/2008 - 13:04

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

By Charles Marcus at 11/13/2008 - 11:58

postconf -n output is preferred... all of it...

Re: Spamcop's position on backscatter

By D G Teed at 11/13/2008 - 13:06

On Thu, Nov 13, 2008 at 11:58 AM, Charles Marcus
<CMarcus@media-brokers.com>wrote:

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