Restricting the scope of "success" notifications

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Restricting the scope of "success" notifications

Tomas Macek-2
Hello, our system is sometimes under attack of spammers using
"NOTIFY=SUCCESS" param in "rcpt to: " header. And because of a random From
address, the DSN message obviously goes to an nonexistent server
or user.

I've read the "Restricting the scope of "success" notifications" topic at
http://www.postfix.org/DSN_README.html#scope and I'd like to ask you about
some details:

1) if I turn off the DSN for the networks outside of $mynetwork, do I
understand it well, that we will not send them (to the outside world) any
more DSNs with "user over quota" or "access denied"?
We won't be sending anything probably in that case, just asking to be
sure.

2) how much is it normal to turn off the DSN for outside world? What is
your settings?

Regards
Tomas
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restricting the scope of "success" notifications

Matus UHLAR - fantomas
On 31.07.17 09:16, Tomas Macek wrote:

>Hello, our system is sometimes under attack of spammers using
>"NOTIFY=SUCCESS" param in "rcpt to: " header. And because of a random
>From address, the DSN message obviously goes to an nonexistent server
>or user.
>
>I've read the "Restricting the scope of "success" notifications"
>topic at http://www.postfix.org/DSN_README.html#scope and I'd like to
>ask you about some details:
>
>1) if I turn off the DSN for the networks outside of $mynetwork, do I
>understand it well, that we will not send them (to the outside world)
>any more DSNs with "user over quota" or "access denied"?
>We won't be sending anything probably in that case, just asking to be
>sure.

Correct. DSN at SMTP level means that you take care of sending DSNs, missing
DSN will cause sender to issue DSNs by themselves.
Therefore your server will only send DSNs the old way - if it fails to
deliver message (or if the delay crosses delay_warning_time)

>2) how much is it normal to turn off the DSN for outside world? What
>is your settings?

seems it will become much more common now, since many servers receive spam
of that kind.

I am trying to prevent notifications to messages considered spam but that

needs support from spam filter.  You can send NOTIFY= to filter over LMTP,
where filter would pass it back to postfix (over LMTP again).

If filter was able to strip NOTIFY=, we'd have fine control over when to
send notifications...

1. I don't know how effective would this be. Maybe we'd need to disable
     notifies at all.

2. seems that postfix 2.9 doesn't send NOTIFY=SUCCESS to LMTP filter, but
    sends notify imediately. 2.11 does not have this problem.
    see http://marc.info/?l=postfix-users&m=150107262526121&w=2 

--
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.
If Barbie is so popular, why do you have to buy her friends?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restricting the scope of "success" notifications

Wietse Venema
In reply to this post by Tomas Macek-2
Tomas Macek:

> Hello, our system is sometimes under attack of spammers using
> "NOTIFY=SUCCESS" param in "rcpt to: " header. And because of a random From
> address, the DSN message obviously goes to an nonexistent server
> or user.
>
> I've read the "Restricting the scope of "success" notifications" topic at
> http://www.postfix.org/DSN_README.html#scope and I'd like to ask you about
> some details:
>
> 1) if I turn off the DSN for the networks outside of $mynetwork, do I
> understand it well, that we will not send them (to the outside world) any
> more DSNs with "user over quota" or "access denied"?
> We won't be sending anything probably in that case, just asking to be
> sure.

DSN is an optional extension of SMTP. With DSN turned off, the SMTP
protocol requires that the sender gets a non-delivery notification.

> 2) how much is it normal to turn off the DSN for outside world? What is
> your settings?

There are still MTAs that don't implement DSN, such as exim and
qmail.

        Wietse
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restricting the scope of "success" notifications

Wietse Venema
In reply to this post by Matus UHLAR - fantomas
Matus UHLAR - fantomas:
> If filter was able to strip NOTIFY=, we'd have fine control over when to
> send notifications...

There is an example that modifies DSN commands in
http://www.postfix.org/postconf.5.html#smtpd_command_filter

        Wietse
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restricting the scope of "success" notifications

Tomas Macek-2
In reply to this post by Matus UHLAR - fantomas


On Mon, 31 Jul 2017, Matus UHLAR - fantomas wrote:

> On 31.07.17 09:16, Tomas Macek wrote:
>> Hello, our system is sometimes under attack of spammers using
>> "NOTIFY=SUCCESS" param in "rcpt to: " header. And because of a random
>> From address, the DSN message obviously goes to an nonexistent server
>> or user.
>>
>> I've read the "Restricting the scope of "success" notifications" topic at
>> http://www.postfix.org/DSN_README.html#scope and I'd like to ask you about
>> some details:
>>
>> 1) if I turn off the DSN for the networks outside of $mynetwork, do I
>> understand it well, that we will not send them (to the outside world) any
>> more DSNs with "user over quota" or "access denied"?
>> We won't be sending anything probably in that case, just asking to be sure.
>
> Correct. DSN at SMTP level means that you take care of sending DSNs, missing
> DSN will cause sender to issue DSNs by themselves.
> Therefore your server will only send DSNs the old way - if it fails to
> deliver message (or if the delay crosses delay_warning_time)
>
>> 2) how much is it normal to turn off the DSN for outside world? What is
>> your settings?
>
> seems it will become much more common now, since many servers receive spam
> of that kind.
>
> I am trying to prevent notifications to messages considered spam but that
>
> needs support from spam filter.  You can send NOTIFY= to filter over LMTP,
> where filter would pass it back to postfix (over LMTP again).
>
> If filter was able to strip NOTIFY=, we'd have fine control over when to
> send notifications...
>
> 1. I don't know how effective would this be. Maybe we'd need to disable
>     notifies at all.
>
> 2. seems that postfix 2.9 doesn't send NOTIFY=SUCCESS to LMTP filter, but
>    sends notify imediately. 2.11 does not have this problem.
>    see http://marc.info/?l=postfix-users&m=150107262526121&w=2

Thanks!
And what about to use a before-queue Milter? May it be helpful?
According to doc http://www.postfix.org/MILTER_README.html#limitations 
there is supposed to be a limitation if we use before-queue filters
only and I don't have any.

The doc says:
---
When you use the before-queue content filter for incoming SMTP mail (see
SMTPD_PROXY_README), Milter applications have access only to the SMTP
command information; they have no access to the message header or body,
and cannot make modifications to the message or to the envelope.
---

Is Milter able in that case modify headers?

Tomas

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restricting the scope of "success" notifications

Matus UHLAR - fantomas
>Matus UHLAR - fantomas:
>> If filter was able to strip NOTIFY=, we'd have fine control over when to
>> send notifications...

On 31.07.17 07:14, Wietse Venema wrote:
>There is an example that modifies DSN commands in
>http://www.postfix.org/postconf.5.html#smtpd_command_filter

That means we could use smtpd_command_filter to replace NOTIFY=(.*) by
NOTIFY=NONE if smtp/milter header contains e.g.  "X-Spam-Flag: Yes,"

possibly doable, although I currently can't imagine, how.

>>On 31.07.17 09:16, Tomas Macek wrote:
>>>2) how much is it normal to turn off the DSN for outside world?

I guess that while this is not very common, but with this king of spam
spreading it may get applied on more servers, thus effectively lowering
usefullness of DSN extenaion.

That's also why I search for better solutions...

>On Mon, 31 Jul 2017, Matus UHLAR - fantomas wrote:
>>I am trying to prevent notifications to messages considered spam but that
>>needs support from spam filter.  You can send NOTIFY= to filter over LMTP,
>>where filter would pass it back to postfix (over LMTP again).
>>
>>If filter was able to strip NOTIFY=, we'd have fine control over when to
>>send notifications...
>>
>>1. I don't know how effective would this be. Maybe we'd need to disable
>>    notifies at all.
>>
>>2. seems that postfix 2.9 doesn't send NOTIFY=SUCCESS to LMTP filter, but
>>   sends notify imediately. 2.11 does not have this problem.
>>   see http://marc.info/?l=postfix-users&m=150107262526121&w=2

On 31.07.17 14:54, Tomas Macek wrote:
>And what about to use a before-queue Milter? May it be helpful?

I like before-queue filters (and milters) because they prevent spam from
being received and handled, and in case of problems we have clean hands (the
mail was not accepted, it's up to the sending MUA to handle the DSN).

on another (not-yet mentioned) machine, I use milter. Many of those
(NOTIFY=SUCCESS) spams got rejected.  Still, some DSNs were generated.

So I still serch for solution (if there's any).

looking at milter API, seems that milter could replace recipients got by
xxfi_envrcpt by calling smfi_delrcpt and smfi_addrcpt_par...

>According to doc
>http://www.postfix.org/MILTER_README.html#limitations there is
>supposed to be a limitation if we use before-queue filters only and I
>don't have any.
>
>The doc says:
>---
>When you use the before-queue content filter for incoming SMTP mail
>(see SMTPD_PROXY_README), Milter applications have access only to the
>SMTP command information; they have no access to the message header
>or body, and cannot make modifications to the message or to the
>envelope.
>---
>
>Is Milter able in that case modify headers?

"modify headers" is subset of "motifications to the message", thus the
answer is NO.

However, this only happens when someone has both smtp proxy (before-queue
filter) AND the milter, which I don't think happens at all.

You don't have smtp proxy, so why care?

--
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.
Emacs is a complicated operating system without good text editor.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restricting the scope of "success" notifications

Viktor Dukhovni
In reply to this post by Tomas Macek-2
On Mon, Jul 31, 2017 at 09:16:46AM +0200, Tomas Macek wrote:

> Hello, our system is sometimes under attack of spammers using
> "NOTIFY=SUCCESS" param in "rcpt to: " header. And because of a random From
> address, the DSN message obviously goes to an nonexistent server or user.
>
> I've read the "Restricting the scope of "success" notifications" topic at
> http://www.postfix.org/DSN_README.html#scope and I'd like to ask you about
> some details:
>
> 1) if I turn off the DSN for the networks outside of $mynetwork, do I
> understand it well, that we will not send them (to the outside world) any
> more DSNs with "user over quota" or "access denied"?

Turning off "DSN" in the server EHLO response will disable
*non-failure* DSN notices.  Bounces will continue to be sent as is
normal and expected.

I strongly recommend turning off DSN at the edge of your network,
exposing DSN support only to your internal clients, and ignoring
any DSN support by external servers.  

That way your MTA sends DNS success only to your users, and success
notices for remote inbound mail are sent by the remote MTA to its
own users.  Your users are notified of success once mail is accepted
by the remote system.  Further delegation of notification responsibility
is not IMHO a good idea.

--
        Viktor.
Loading...