Backscatter questions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Backscatter questions

J Doe
Hello,

I recently configured Postfix 3.1.0 on a low-volume, Internet facing server.  Mail operations are normal, but I had two questions regarding backscatter.

1. From what I understand, “backscatter” refers to e-mails such as non-delivery reports being sent back to the originator of a spam message.  As the originator is often a forged address, the non-delivery reports is essentially junk data.  Would this be a correct definition for the term ?

2. Is it possible to white-list the generation of non-delivery reports for some hosts and prevent generation for all others ?  For instance, if a Gmail user attempts to e-mail me but specifies a non-existent address, I want the non-delivery report to go them (and any other senders from @gmail.com), but all other reports should be stopped from being sent.

Thanks for your help,

- J

Reply | Threaded
Open this post in threaded view
|

Re: Backscatter questions

Benny Pedersen-2
J Doe skrev den 2017-09-27 19:49:

> I recently configured Postfix 3.1.0 on a low-volume, Internet facing
> server.  Mail operations are normal, but I had two questions regarding
> backscatter.

...

> 1. From what I understand, “backscatter” refers to e-mails such as
> non-delivery reports being sent back to the originator of a spam
> message.  As the originator is often a forged address, the
> non-delivery reports is essentially junk data.  Would this be a
> correct definition for the term ?

non delivery is not correct, if you have a local sender that try to send
email outside your own local domains it would create a bounce if it
could not be delivered, this is not spam btw

> 2. Is it possible to white-list the generation of non-delivery reports
> for some hosts and prevent generation for all others ?  For instance,
> if a Gmail user attempts to e-mail me but specifies a non-existent
> address, I want the non-delivery report to go them (and any other
> senders from @gmail.com), but all other reports should be stopped from
> being sent.

keep away from whitelists, since there is nothing to whitelist, but make
sure your postfix does not accept and later bounce same mail since that
could be with forged sender addresses

its always safe to reject

all the best
Reply | Threaded
Open this post in threaded view
|

Re: Backscatter questions

J Doe

> On Sep 27, 2017, at 2:08 PM, Benny Pedersen <[hidden email]> wrote:
>
> J Doe skrev den 2017-09-27 19:49:
>
>> I recently configured Postfix 3.1.0 on a low-volume, Internet facing
>> server.  Mail operations are normal, but I had two questions regarding
>> backscatter.
>
> ...
>
>> 1. From what I understand, “backscatter” refers to e-mails such as
>> non-delivery reports being sent back to the originator of a spam
>> message.  As the originator is often a forged address, the
>> non-delivery reports is essentially junk data.  Would this be a
>> correct definition for the term ?
>
> non delivery is not correct, if you have a local sender that try to send email outside your own local domains it would create a bounce if it could not be delivered, this is not spam btw
>
>> 2. Is it possible to white-list the generation of non-delivery reports
>> for some hosts and prevent generation for all others ?  For instance,
>> if a Gmail user attempts to e-mail me but specifies a non-existent
>> address, I want the non-delivery report to go them (and any other
>> senders from @gmail.com), but all other reports should be stopped from
>> being sent.
>
> keep away from whitelists, since there is nothing to whitelist, but make sure your postfix does not accept and later bounce same mail since that could be with forged sender addresses
>
> its always safe to reject
>
> all the best

Hi Benny,

Thank you for your reply.

My current setup is for virtual domain hosting.  I have a domain (say example.org), that I forward e-mail to Gmail.  So if there was [hidden email] Postfix forwards to [hidden email].  As a result, the only local users I have are the service accounts on the e-mail server itself.

What happens is I will get a spam message for a user @example.org.  If the user is non-existent, a non-delivery report gets generated by mail server and goes back to the sender of the spam . . . whose address is likely forged.  That means the report is generating traffic to a possibly legitimate e-mail server.

I do want legitimate non delivery reports to go to real people e-mailing recipients @example.org.  Almost all of the legitimate e-mail coming through is from people using Gmail, Outlook and so forth which is why I thought whitelisting those domaines for non delivery reports would be useful, whereas other servers are most likely forged and should be silently dropped.

Is there a way to achieve this or as you noted, are whitelists to be avoided ?  If whitelists are to be avoided what is the best practice for handling this scenario ?

Thanks,

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

Re: Backscatter questions

Benny Pedersen-2
J Doe skrev den 2017-09-27 22:20:

[snip]
> Is there a way to achieve this or as you noted, are whitelists to be
> avoided ?  If whitelists are to be avoided what is the best practice
> for handling this scenario ?

why not add example.org on google apps mx ? :=)

if useers not wanting your mailserver anyway, why even think about imap
then ?

still serious ?, then setyp postfix client sasl auth to gmail pr user

if not want all that problems drop forwards
Reply | Threaded
Open this post in threaded view
|

Re: Backscatter questions

J Doe

> On Sep 27, 2017, at 4:30 PM, Benny Pedersen <[hidden email]> wrote:
>
> J Doe skrev den 2017-09-27 22:20:
>
> [snip]
>> Is there a way to achieve this or as you noted, are whitelists to be
>> avoided ?  If whitelists are to be avoided what is the best practice
>> for handling this scenario ?
>
> why not add example.org on google apps mx ? :=)
>
> if useers not wanting your mailserver anyway, why even think about imap then ?
>
> still serious ?, then setyp postfix client sasl auth to gmail pr user
>
> if not want all that problems drop forwards

Hi,

Thanks for your reply Benny.  Does anyone else have any advice regarding backscatter on a virtual domain Postfix setup ?

Thanks,

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

Re: Backscatter questions

Wietse Venema
J Doe:

>
> > On Sep 27, 2017, at 4:30 PM, Benny Pedersen <[hidden email]> wrote:
> >
> > J Doe skrev den 2017-09-27 22:20:
> >
> > [snip]
> >> Is there a way to achieve this or as you noted, are whitelists to be
> >> avoided ?  If whitelists are to be avoided what is the best practice
> >> for handling this scenario ?
> >
> > why not add example.org on google apps mx ? :=)
> >
> > if useers not wanting your mailserver anyway, why even think about imap then ?
> >
> > still serious ?, then setyp postfix client sasl auth to gmail pr user
> >
> > if not want all that problems drop forwards
>
> Hi,
>
> Thanks for your reply Benny.  Does anyone else have any advice
> regarding backscatter on a virtual domain Postfix setup ?

Yes. Just do not forward spam.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Backscatter questions

Matus UHLAR - fantomas
In reply to this post by J Doe
On 27.09.17 13:49, J Doe wrote:
>1. From what I understand, “backscatter” refers to e-mails such as
> non-delivery reports being sent back to the originator of a spam message.
> As the originator is often a forged address, the non-delivery reports is
> essentially junk data.  Would this be a correct definition for the term ?

yes.

>2. Is it possible to white-list the generation of non-delivery reports for
> some hosts and prevent generation for all others ?  For instance, if a
> Gmail user attempts to e-mail me but specifies a non-existent address, I
> want the non-delivery report to go them (and any other senders from
> @gmail.com), but all other reports should be stopped from being sent.

at your mail server, the easiest way to avoid this problem is to reject mail
at SMTP level, either to unknown recipients (see local_recipient_maps and
smtpd_reject_unlisted_recipient), or spam (use milter or
smtpd_proxy_filter).

This way, you will not be source of backscatter - you will reject unwanted
mail immediately.

Note that local senders' mail should not be sent through milter/proxy, they
should be handled differently:
1. send through ports 587 or 465, with required authentication and ssl/tls
2. their sender addresses should be validated with smtpd_reject_unlisted_sender
or you may create list of allowed sender addresses for use check_sender_access
- apply this on ports 465 and 587

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
10 GOTO 10 : REM (C) Bill Gates 1998, All Rights Reserved!
Reply | Threaded
Open this post in threaded view
|

Re: Backscatter questions

@lbutlr
On 01 Oct 2017, at 08:50, Matus UHLAR - fantomas <[hidden email]> wrote:
> 2. their sender addresses should be validated with smtpd_reject_unlisted_sender

Do Address delimiters have an issue with this? I thought they did.

That is, [hidden email] sends and email "from" [hidden email] and smtpd_reject_unlisted_sender rejects the email?

smtpd_reject_unlisted_sender (default: no)
Request that the Postfix SMTP server rejects mail from unknown sender
addresses, even when no explicit reject_unlisted_sender access
restriction is specified. This can slow down an explosion of forged
mail from worms or viruses.

An address is always considered "known" when it matches a virtual(5) alias or a canonical(5) mapping.

        • The sender domain matches $mydestination, $inet_interfaces
          or $proxy_interfaces, but the sender is not listed in
          $local_recipient_maps, and $local_recipient_maps is not null.
        • The sender domain matches $virtual_alias_domains but the
          sender is not listed in $virtual_alias_maps.
        • The sender domain matches $virtual_mailbox_domains but the
          sender is not listed in $virtual_mailbox_maps, and
          $virtual_mailbox_maps is not null.
        • The sender domain matches $relay_domains but the sender is
          not listed in $relay_recipient_maps, and
          $relay_recipient_maps is not null.

I interpreted that to mean that in all the bulleted cases, the mail would be rejected by smtpd_reject_unlisted_sender.


--
Apple broke AppleScripting signatures in Mail.app, so no random signatures.

Reply | Threaded
Open this post in threaded view
|

Re: Backscatter questions

Matus UHLAR - fantomas
>On 01 Oct 2017, at 08:50, Matus UHLAR - fantomas <[hidden email]> wrote:
>> 2. their sender addresses should be validated with smtpd_reject_unlisted_sender

On 01.10.17 09:22, @lbutlr wrote:
>Do Address delimiters have an issue with this? I thought they did.

I thought that's exactly what address delimiters are for - to avoid problems
with this...

https://www.mail-archive.com/postfix-users@.../msg25973.html
>That is, [hidden email] sends and email "from" [hidden email]
> and smtpd_reject_unlisted_sender rejects the email?

I expect smtpd_reject_unlisted_recipient and
smtpd_reject_unlisted_sender to consider exactly the same set of rules
and would consider it a bug if behaving differently.

a little searching says it's correct:

https://www.mail-archive.com/postfix-users@.../msg25973.html

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0...
Reply | Threaded
Open this post in threaded view
|

Re: Backscatter questions

@lbutlr
On 01 Oct 2017, at 09:59, Matus UHLAR - fantomas <[hidden email]> wrote:
> a little searching says it's correct:
>
> https://www.mail-archive.com/postfix-users@.../msg25973.html

Excellent! Thanks for researching that.

--
Apple broke AppleScripting signatures in Mail.app, so no random signatures.