1
delivery rules
Idea shared by Sabatino - Today at 2:28 AM
Proposed
I continue to be a little disappointed by the lack of functionality of delivery rules
I've asked several times, but SM has never officially commented, even to make me understand why I'm being ignored or why it's a bad idea

I would really like to have delivery rules

Here are some examples

1) if the recipient is + @hotmail.com, use the xxxxx gateway
2) if it is a bounce, use the gateway xxxxx
3) if it is a forward use the gateway xxxxx
4) if it is a forward from an alias, use the gateway xxxxx

and of course, coupled with rules

I am absolutely certain that this would allow us to quickly solve blocking problems by the usual big players and reduce the chance that we lose reputation, especially thanks to rules 3 and 4

Sabatino Traini
      Chief Information Officer
Genial s.r.l. 
Martinsicuro - Italy

4 Replies

Reply to Thread
0
I expect someone knows how to build that solution using Postfix as an outbound gateway.   It will cost you some consulting dollars, but it would solve your problem sooner.   Then you and your consultant might be able to package it for sale to others 
0
It's not like that @Douglas Foster

Let me explain better. I already have a secondary gateway (actually more than one) to forward all traffic to and then make the rules there, but there are 2 problems:

1) I don't understand why SM can't do it on its own without having to configure a secondary gateway. I have worked with many mail servers and I have always found the routing rules. 
Undoubtedly, I decided to use SM because I consider it the best choice as a whole, but it doesn't mean it can't improve. And then in a small installation I would prefer to be as independent as possible without having to use a second server.
You'll say, but you're forwarding it to another server. But the idea is to have an account on smtp2go and forward only the "dirty" traffic or what is rejected by the microsoft madness during the warmaup of an ip
And then to be honest I could also use the rules to simply determine which IP to exit with

2) Even using a secondary gateway, rules 3 and 4 are not possible. Only SM can know if it's an alias or a forward (and this type of rule would also be new because I haven't found it anywhere)

I'll give you another example that I had to solve by forwarding to another gateway because SM didn't have the functionality
A customer wanted to assign each user an email operatorexx@domain.tld
But all operators must be able to send only to @domain.tld
Instead, it has other emails info@domain.tld, sales@domain.tld that I can send to anyone

It's a request that doesn't seem so out of place to me from the customer. In order to satisfy it, I had to forward all the outgoing @domain.tld traffic to another gateway



Moreover there is always the same question to which I have not had an answer for some time.
Assuming it's a bad idea. Why?

Sabatino Traini Chief Information Officer Genial s.r.l. Martinsicuro - Italy
1
Not a bad idea, and I can see its potential value.   But I also see that they have their hands full trying to get other capabilities implemented and (more importantly) stablized.  
0
I agree with you.
First of all, stability. But I really hope it will be considered as soon as possible.


I often face reputation issues because users have activated forwarding and/or aliases and I would like these messages to follow a different path.
The reputation of the IP would remain much higher. 
Then during the wormup of the IPs to Microsoft there is always the bright idea to block the IP, just because it is new. You have to open a ticket, wait for them to respond with the usual standard response, and respond again so that it is handled by a second-level technician.
Meanwhile, you have to divert all the server traffic to another gateway and/or IP. Instead, if we had delivery rules, only that traffic would be diverted. Clearly, if you use smtp2go to divert, you have to pay
Sabatino Traini Chief Information Officer Genial s.r.l. Martinsicuro - Italy

Reply to Thread

Enter the verification text