Knowledge Partner Knowledge Partner
Knowledge Partner
473 views

Connection Drop Services processing?

How does processing differ when configured as shown here in the SMTP Interface and when configured using filters in the SMTP Policy?

Connection Drop Services.PNG

I have reviewed TID 7023565 Best Practices for Spam Control but it doesn't explain the interaction between the two configuration options.

I want to create an RBL filter exception based on sender's email address in the incoming SMTP Policy to allow specific sender's email through even when their IP address may be blacklisted but I would like to drop the connection for other blacklisted IP addresses, if that's possible.

_____
Kevin Boyle - Knowledge Partner - Calgary, Alberta, Canada
Who are the Knowledge Partners?
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
7 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

Hi Kevin,

maybe I am wrong but I see it in this way. If you drop a connection then you cannot use exceptions. Therefore you have to check RBL via your policy. In this case you can set activities (block and so on) and define exceptions.

Diethmar

Diethmar Rimser
This community is more powerful if you use Likes and Solutions
Knowledge Partner Knowledge Partner
Knowledge Partner

Diethmar is correct, you don't have the exception option.  The advantage of defining connection drop services here is that it is a little more efficient.  It happens sooner in the process of receiving email so SMG doesn't do all the filter checks you have defined in your incoming policy.  It just checks on the initial connection and drops if needed.  The incoming filter policy isn't used until after the email is received, so it takes a little more processing time.

--
Ken
Knowledge Partner

Create and vote for enhancements in the Idea Exchange forums!
Don't forget to Like helpful posts and mark Solutions!
Knowledge Partner Knowledge Partner
Knowledge Partner

@Rimser @ketter 

You are both suggesting Connection Drop Services takes precedence over filter processing. That makes sense. I only wish that was made clear in the documentation.

I assume if the message never is processed by the filter it will never appear in the Message Tracker and no statistics will be recorded. That is neither good nor bad. It is just something about which we should be aware.

The RBL hit action implies that SMG can send a response to the sender saying the message has been delayed rather than rejected. Presumably, on subsequent attempts, the connection would not be dropped and normal filter processing would take place.

  1. Does it work?
  2. How many times or how long must the message be delayed before it isn't?
  3. Is this delay processing impacted by the change to BitDefender?

With IP reputation sensitivity  the change to BitDefender currently does impact processing as discussed in the IP Reputation Temp Fail Re-Try times thread,

While your responses are definitely helpful, the documentation really needs to be improved.

 

_____
Kevin Boyle - Knowledge Partner - Calgary, Alberta, Canada
Who are the Knowledge Partners?
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

So many questions and so many remarks ...

First of all - yes, you're right. Documentation is incomplete and needs work. A lot of work!

RBL means (usually) blocked - not delayed. So if I am on a blocked list I have to try to get off. There is no delay, it is block. Btw if you reply to all RBL senders you have a lot to do!

I'm coming back to message tracker (which is not really my friend). You have several opportunities to track messages even they have not touched any policy. Check your SMTP interface, Message Tracking Services!

Diethmar Rimser
This community is more powerful if you use Likes and Solutions
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner


@Rimser wrote:

RBL means (usually) blocked - not delayed. So if I am on a blocked list I have to try to get off. There is no delay, it is block. Btw if you reply to all RBL senders you have a lot to do!


I completely agree with both these statements.

This is the first time I've seen a option to  temporally delay the processing of a message from a blacklisted IP address and feel it deserves some explanation.

Perhaps someone from Micro Focus would like to comment?

_____
Kevin Boyle - Knowledge Partner - Calgary, Alberta, Canada
Who are the Knowledge Partners?
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
Commodore
Commodore

@KBOYLE


This is the first time I've seen a option to  temporally delay the processing of a message from a blacklisted IP address and feel it deserves some explanation.

Perhaps someone from Micro Focus would like to comment?


The setting is completely up to the admin user on whether they want it set to be blocked or delayed if it fires on RBL. If you prefer these get blocked, then set it to 'Reject connection'.

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner


@suziew wrote:

The setting is completely up to the admin user on whether they want it set to be blocked or delayed if it fires on RBL. If you prefer these get blocked, then set it to 'Reject connection'.


I realize that 'Reject connection' is an option, and perhaps even the better one. 😉

Are you able to answer the questions I asked in one of my responses?

The RBL hit action implies that SMG can send a response to the sender saying the message has been delayed rather than rejected. Presumably, on subsequent attempts, the connection would not be dropped and normal filter processing would take place.

  1. Does it work?
  2. How many times or how long must the message be delayed before it isn't?
  3. Is this delay processing impacted by the change to BitDefender?
_____
Kevin Boyle - Knowledge Partner - Calgary, Alberta, Canada
Who are the Knowledge Partners?
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.