exim4 reveals a mail alias when remote server rejects spam

itemprop="text">

I'm running exim4 (4.76) on Ubuntu
12.0.4.4.

exim4 is set up to handle mail for
mydomain.com. I have aliases set up that forward a@mydomain.com to b@gmail.com. I have
SpamAssassin set up to work in conjunction with exim4 (via
sa-exim.conf).

Sometimes spam is sent to
a@mydomain.com and SpamAssassin assigns it a low enough score that it forwards it to
b@gmail.com. GMail rejects the message as spam, so my exim4 server attempts to send a
message back to the spam address
saying:

This message was created
            automatically by mail delivery software.


A message that
            you sent could not be delivered to one or more of its
recipients. This is a
            permanent error. The following address(es) failed:


            b@gmail.com
 (generated from a@mydomain.com)
 SMTP error from remote
            mail server after end of data:
 host gmail-smtp-in.l.google.com
            [2607:f8b0:4003:c02::1a]:
 550-5.7.1 [xxxx:yyyy::zzzz:aaaa:bbbb:ccccc 12] Our
            system has detected that
 550-5.7.1 this message is likely unsolicited mail.
            To reduce the amount of spam

 550-5.7.1 sent to Gmail, this message
            has been blocked. Please visit
 550-5.7.1
            http://support.google.com/mail/bin/answer.py?hl=en&answer=188131 for
 550
            5.7.1 more information. c15si25934770obf.31 -
            gsmtp

I don't want
this email sent back to the spam address because it reveals "b@gmail.com", the
destination of an alias.

How can I either remove
"b@gmail.com" from the reject email, or suppress that reject email
altogether?

itemprop="text">

class="normal">Answer

I would
not recommend trying to hide your e-mail structure. If it breaks, you will likely be
missing the appropriate information to fix the problem.

It is Google is blocking the
message, so the problem may be with your server. If your email structure is not well
done (fixed IP address, valid rDNS, SPF, DKIM, and optionnally DMARC records), then
Google may be bouncing the messages because they come from your server.

If your server is well configured and you are
getting high volumes of such bounces, then your spam filtering may not be very
effective. Improve your spam filtering. Three spam blocking techniques I have found
highly effective
are:

• Using the
  zen.spamhaus.org
  blocklist.


• Using spamassassin to
  filter email before acceptance. The sa-exim works well with the
  heavy build of Exim.


• Adding a
  delay of about 10 to 20 seconds to each step (connect, helo, mail, recipient) for any
  connecting host which fails rDNS validation. This requires a couple of extra ACLs, and
  modification to the existing ACLs. This is the ACL section I use before the accept. Add
  these after accepting local and authorized mail. The pipelining control is only used in
  the connect ACL.
  

            # Verify reverse DNS lookup of the sender's host.
 # Delay and disable
            pipelining on failure.
 warn
 !verify =
            reverse_host_lookup
 delay = 20s
 control =
            no_pipelining

If you want to verify that the
destination is valid, you can use callouts. However, Gmail may end up blocking you if
you do so. The following code from the standard configuration does recipient callouts.

 # Verify recipients
            listed in local_rcpt_callout with a callout.
 # This is especially handy for
            forwarding MX hosts (secondary MX or
 # mail hubs) of domains that receive a
            lot of spam to non-existent
 # addresses. The only way to check local parts
            for remote relay
 # domains is to use a callout (add /callout), but please
            read the
 # documentation about callouts before doing this.

            deny
 !acl = acl_local_deny_exceptions

 recipients = ${if
            exists{CONFDIR/local_rcpt_callout}\
 {CONFDIR/local_rcpt_callout}\

            {}}
 !verify = recipient/callout