Mail forwarding to external domains is a pain and should be erradicated. It would be better to pull the messages from the destination mailbox.

That being said, you should use SRS and be sure that the forward doesn't occur if it's SPAM. Of course it need to be detected at spam first.

If I'm not wrong though, for the spam checks to occur you need to do the forward by using the forward function of a mailbox. I'm not convinced spam check occurs if the forward is done via an alias.

My solution, almost satisfying, and as we are using incoming and outgoing gateways (not SmarterMail):

- On our incoming gateway, when flagging the message as SPAM, I add a specific header to the mail.

- On our outgoing gateway, I added a rule based on this header, so that if a mail came in first from our gateway and has been detected as SPAM, then it won't allow it to be relayed outside.

Not the easiest setup but it works.

Kind regards

I agree with you.

I'm trying to eliminate aliases as much as possible but unfortunately it's not always possible.

But some routing rules would help.

Anti-spam checks are also carried out with the alias, but too many spam still pass through.

Having a routing rule that allows you to set a specific gateway or a specific outbound address would greatly mitigate the problem. Preventing users from creating aliases or setting forwards doesn't seem like a viable option to me. But using a gateway or a specific outbound IP would greatly protect the reputation of the mailserver.

It also doesn't seem like such a complex option to manage.

Delivery knows if it is an alias, so much so that it writes it in the logs

xxxs@xxxx.tld is an alias. Expanding recipient list.

so what would be the problem of telling it use this gateway and/or use this outbound binding?

The same for forwards

Actually what I would like is the possibility to put the routing rules on the delivery. It would be a turning point and a significant increase in functionality.

Imagine that a series of rules can be inserted into the delivery queue and applied in order of priority such as:

1) if the recipient is @hotmail.com use smtp2go gateway - continue with other rules

2) if the recipient is gmail.com use outbound ipv4 xxx.xxx.xxx - continue with other rules

3) if the recipient originates from a forward or an alias use smtp2go gateway - stop further rules

4) if the email is intended for more than 2 recipients use outbound ipv4 xxx.x..x.x - continue with other rules.

I repeat, in my opinion sm would make a significant leap in quality and would greatly reduce the need to use an exit gateway such as postfix on which to then apply the rules. That is, it would make sm independent. Furthermore, only SM could apply rules like 3

I hope to generate discussion and consideration of what has been said.

I understand it's in beta now and now is not the time. But once the beta is over I think this could be a great evolution.

edit...

add that the routing rules are present, with various levels of functionality, in

postfix

icewarp ( https://docs.icewarp.com/Content/IceWarp-Server/Administration-Nodes/Mail%20Service/General/Routing.htm )  - on icewarp it also acts on the input queue, I have used it several times in particular situations

exchange

And these are just the ones I'm sure of.

Great ideas guys! I burning IP or gateway. 

I have a client that does this, :( @companydomain.com forward to @att.net forward to @hotmail.com

@lee

HI.

I've been asking for routing rules for a long time that could solve many problems.

We should be hooked up to delivery.

SM, however, you have never taken a position on this matter and I don't understand why.

To have the routing rules we should use an outbound gateway as a postfix, but it still wouldn't solve the problem I presented in this thread.

Then by introducing the routing rules SM would become an independent product.

I would really like to know what SM thinks about it and what are the reasons why it is not implemented.

bump 

Hi guys. I hope we can start talking about new features again, as it seems that the new version is now fairly stable.