Best way to handle a Delivered-To exploit??

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

Best way to handle a Delivered-To exploit??

Brian Schang
Hello:

I have been using Postfix for many years. I'm a hobbiest and have
learned a lot by reading this newsgroup. Based on the advice shared
here, I have been able to avoid bouncing emails by rejecting them before
messages are queued. Until recently...

In the past week, my server has accepted dozens of emails that were not
deliverable. In all cases the issue has been a mail forwarding loop
which resulted in the email bouncing. Given that my configuration has
not changed in many months, I was puzzled. However, a little research
led me to look into a Delivered-To exploit. I looked at a few of the
messages in the queue (postcat), and sure enough those messages had a
Delivered-To header line.

Now I'm trying to learn how to handle this. I understand that the
Delivered-To headers are there for a reason and don't want to defeat
their value. But I also don't want to bounce bogus emails either. I'm
not sure how to best balance these two.

What is the best way to handle a problem like this? Right now I'm
soft_bouncing until I find a more permanent solution. The best I've
found on the net is to set up a header_check. Is this a good solution?
If so, are there any tricks in setting this up correctly?

I'd appreciate any advice.

Thank you.

--
Brian
Reply | Threaded
Open this post in threaded view
|

Re: Best way to handle a Delivered-To exploit??

Reindl Harald-2


Am 05.11.2012 03:45, schrieb Brian Schang:
> What is the best way to handle a problem like this? Right now I'm
> soft_bouncing until I find a more permanent solution. The best I've
> found on the net is to set up a header_check. Is this a good solution?
> If so, are there any tricks in setting this up correctly?

we need the log lines from one example message and output
of "postconf -n" to see what happens


signature.asc (267 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Best way to handle a Delivered-To exploit??

Brian Schang
Hello:

On 11/5/2012 5:18 AM, Reindl Harald wrote:
> Am 05.11.2012 03:45, schrieb Brian Schang:
>> What is the best way to handle a problem like this? Right now I'm
>> soft_bouncing until I find a more permanent solution. The best I've
>> found on the net is to set up a header_check. Is this a good solution?
>> If so, are there any tricks in setting this up correctly?
>
> we need the log lines from one example message and output
> of "postconf -n" to see what happens

Sure.

Here is an example from the log file. Note that my email gets sent to
amavis and is then re-injected into postfix:

Oct 31 06:32:02 server2 postfix/smtpd[4615]: connect from
crunhmailsapps.info[176.126.168.1]
Oct 31 06:32:03 server2 postfix/smtpd[4615]: 8671D963AF:
client=crunhmailsapps.info[176.126.168.1]
Oct 31 06:32:03 server2 postfix/cleanup[4611]: 8671D963AF:
message-id=<[hidden email]>
Oct 31 06:32:04 server2 postfix/qmgr[23776]: 8671D963AF:
from=<[hidden email]>, size=6438, nrcpt=1 (queue active)
Oct 31 06:32:04 server2 postfix/smtpd[4615]: disconnect from
crunhmailsapps.info[176.126.168.1]
Oct 31 06:32:05 server2 postfix/smtpd[4629]: connect from
localhost[127.0.0.1]
Oct 31 06:32:05 server2 postfix/smtpd[4629]: 9AF30963F8:
client=crunhmailsapps.info[176.126.168.1]
Oct 31 06:32:05 server2 postfix/cleanup[4611]: 9AF30963F8:
message-id=<[hidden email]>
Oct 31 06:32:05 server2 postfix/smtpd[4629]: disconnect from
localhost[127.0.0.1]
Oct 31 06:32:05 server2 postfix/qmgr[23776]: 9AF30963F8:
from=<[hidden email]>, size=7045, nrcpt=1 (queue active)
Oct 31 06:32:05 server2 postfix/smtp[4623]: 8671D963AF:
to=<[hidden email]>, relay=127.0.0.1[127.0.0.1]:10024, delay=2.5,
delays=0.86/0/0/1.7, dsn=2.0.0, status=sent (250 2.0.
0 Ok, id=04180-04, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as
9AF30963F8)
Oct 31 06:32:05 server2 postfix/qmgr[23776]: 8671D963AF: removed
Oct 31 06:32:05 server2 postfix/local[5208]: 9AF30963F8:
to=<[hidden email]>, relay=local, delay=0.16, delays=0.09/0/0/0.07,
dsn=5.4.6, status=bounced (mail forwarding loop fo
r [hidden email])
Oct 31 06:32:05 server2 postfix/cleanup[4611]: C2F6896401:
message-id=<[hidden email]>
Oct 31 06:32:05 server2 postfix/bounce[5423]: 9AF30963F8: sender
non-delivery notification: C2F6896401
Oct 31 06:32:05 server2 postfix/qmgr[23776]: C2F6896401: from=<>,
size=8924, nrcpt=1 (queue active)
Oct 31 06:32:05 server2 postfix/qmgr[23776]: 9AF30963F8: removed

Here is my postconf -n output:

address_verify_map = btree:/var/lib/postfix/verify
address_verify_negative_cache = yes
address_verify_negative_expire_time = 6d
address_verify_negative_refresh_time = 1d
address_verify_positive_expire_time = 6d
address_verify_positive_refresh_time = 1d
alias_database = $alias_maps
alias_maps = hash:/etc/aliases, hash:/etc/postfix/aliases,
ldap:/etc/postfix/ldap_aliases.cf
biff = no
canonical_maps = hash:/etc/postfix/canonical
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/lib/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
defer_transports =
delay_warning_time = 4h
disable_dns_lookups = no
disable_mime_output_conversion = no
html_directory = /usr/share/doc/packages/postfix-doc/html
inet_interfaces = all
inet_protocols = all
mail_owner = postfix
mail_spool_directory = /var/mail
mailbox_command = /usr/bin/procmail
mailbox_size_limit = 0
mailbox_transport =
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
masquerade_classes = envelope_sender, header_sender, header_recipient
masquerade_domains =
!facebook.schang.net,!football.schang.net,!linux.schang.net,!lists.schang.net,!wixom.schang.net,schang.net
masquerade_exceptions = root
message_size_limit = 20480000
mydestination =
$myhostname,localhost.$mydomain,localhost,$mydomain,server2.schang.net
mydomain = schang.net
myhostname = s2.schang.net
mynetworks_style = subnet
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases
notify_classes = resource,software,2bounce
parent_domain_matches_subdomains = smtpd_access_maps
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/packages/postfix-doc/README_FILES
relay_domains = hash:/etc/postfix/relay_domains
relay_recipient_maps =
relayhost =
relocated_maps = hash:/etc/postfix/relocated
sample_directory = /usr/share/doc/packages/postfix-doc/samples
sender_canonical_maps = hash:/etc/postfix/sender_canonical
sendmail_path = /usr/sbin/sendmail
setgid_group = maildrop
smtp_sasl_auth_enable = no
smtp_tls_security_level = none
smtpd_client_restrictions =
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_helo_required = no
smtpd_helo_restrictions =
smtpd_recipient_restrictions = hash:/etc/postfix/access
reject_unknown_reverse_client_hostname  reject_non_fqdn_sender
reject_non_fqdn_recipient       reject_unlisted_recipient
reject_unknown_sender_domain     reject_unknown_recipient_domain
permit_mynetworks       reject_unlisted_sender
reject_non_fqdn_helo_hostname   reject_invalid_helo_hostname
reject_unauth_destination   check_recipient_access
hash:/etc/postfix/recipient_checks       reject_rbl_client
zen.spamhaus.org      reject_rbl_client bl.spamcop.net
smtpd_sasl_auth_enable = no
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_sender_restrictions =
smtpd_tls_CAfile = /etc/postfix/ca.crt
smtpd_tls_cert_file = /etc/postfix/postfix-crt.pem
smtpd_tls_fingerprint_digest = sha1
smtpd_tls_key_file = /etc/postfix/postfix-key.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = none
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
soft_bounce = yes
strict_8bitmime = no
strict_rfc821_envelopes = no
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 550
unverified_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/virtual_alias_maps,
ldap:/etc/postfix/ldap_virtual_alias.cf
virtual_gid_maps = hash:/etc/postfix/virtual_gid_maps,
ldap:/etc/postfix/ldap_virtual_gid.cf
virtual_mailbox_base = /var/spool/mail
virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox_maps,
ldap:/etc/postfix/ldap_virtual_mailbox.cf
virtual_uid_maps = hash:/etc/postfix/virtual_uid_maps,
ldap:/etc/postfix/ldap_virtual_uid.cf

I'd appreciate any insight you can share.

BTW, if you see anything else in my configuration that looks wrong or
could be done better, I'd love to learn more.

Thanks again.

--
Brian
Reply | Threaded
Open this post in threaded view
|

Re: Best way to handle a Delivered-To exploit??

David Rees
In reply to this post by Brian Schang
On Sun, Nov 4, 2012 at 6:45 PM, Brian Schang <[hidden email]> wrote:
> In the past week, my server has accepted dozens of emails that were not
> deliverable. In all cases the issue has been a mail forwarding loop
> which resulted in the email bouncing. Given that my configuration has
> not changed in many months, I was puzzled. However, a little research
> led me to look into a Delivered-To exploit. I looked at a few of the
> messages in the queue (postcat), and sure enough those messages had a
> Delivered-To header line.

FWIW, I've been seeing the same thing here. First one I saw was on Oct
23, but seems to be increasing in frequency.

-Dave
Reply | Threaded
Open this post in threaded view
|

Re: Best way to handle a Delivered-To exploit??

Thomas Harold-3
On 11/6/2012 12:08 AM, David Rees wrote:

> On Sun, Nov 4, 2012 at 6:45 PM, Brian Schang <[hidden email]> wrote:
>> In the past week, my server has accepted dozens of emails that were not
>> deliverable. In all cases the issue has been a mail forwarding loop
>> which resulted in the email bouncing. Given that my configuration has
>> not changed in many months, I was puzzled. However, a little research
>> led me to look into a Delivered-To exploit. I looked at a few of the
>> messages in the queue (postcat), and sure enough those messages had a
>> Delivered-To header line.
>
> FWIW, I've been seeing the same thing here. First one I saw was on Oct
> 23, but seems to be increasing in frequency.
>

Any suggestions on how to handle this in postfix?  We're starting to see
this with some frequency as well.

The only solution that I've stumbled across in my web searches is
documented at:

http://forum.spamcop.net/forums/index.php?showtopic=10734

They suggest a "header_checks" of type "pcre" with the following content
in the file:

/^Delivered-To: .*/
       REJECT Header Exploit

But this apparently will also break "forward as attachment" mails unless
you change something else (and it's not exactly clear, just that
"nested_header_checks" is involved).
Reply | Threaded
Open this post in threaded view
|

Re: Best way to handle a Delivered-To exploit??

Wietse Venema
Thomas Harold:
[ Charset ISO-8859-1 unsupported, converting... ]

> On 11/6/2012 12:08 AM, David Rees wrote:
> > On Sun, Nov 4, 2012 at 6:45 PM, Brian Schang <[hidden email]> wrote:
> >> In the past week, my server has accepted dozens of emails that were not
> >> deliverable. In all cases the issue has been a mail forwarding loop
> >> which resulted in the email bouncing. Given that my configuration has
> >> not changed in many months, I was puzzled. However, a little research
> >> led me to look into a Delivered-To exploit. I looked at a few of the
> >> messages in the queue (postcat), and sure enough those messages had a
> >> Delivered-To header line.
> >
> > FWIW, I've been seeing the same thing here. First one I saw was on Oct
> > 23, but seems to be increasing in frequency.
> >
>
> Any suggestions on how to handle this in postfix?  We're starting to see
> this with some frequency as well.
>
> The only solution that I've stumbled across in my web searches is
> documented at:
>
> http://forum.spamcop.net/forums/index.php?showtopic=10734
>
> They suggest a "header_checks" of type "pcre" with the following content
> in the file:
>
> /^Delivered-To: .*/
>        REJECT Header Exploit

First, there is no need block Delivered-To: addresses with remote
domain names.

Second, blocking local Delivered-To: addresses this way would suffer
from false positive when multiple users have the same email domain.

To avoid those false positives one would have to compare each
envelope recipient address against each Delivered-To: address in
the message header.

        Wietse