Product enhancement idea

[PVerberne]

Hi,

I don't know if this is the right spot to post a thread regarding a product enhancement idea, but hey ... you readers will let me know, I guess.

The challenge:
To be able to shut down all on-premises exchange servers and still be in control (even more than before) I figured I need to get rid of smtp mail. That might sound easy until you actually do some research, only to find out that this kind of "messaging" is essential to a lot of internal processes.

My solution for now:
To be able to eliminate the need for any on-premises exchange servers I installed a small linux server with postfix that (through the use of /etc/aliases) converts all incoming smtp mail into xml (node,js example code attached, and no, I'm not a programmer as you might tell by looking at the code) and forwards those xml's to our API-gateway which injects the messages in our M365 exchange environment using Microsoft Graph. This works like a charm! Oh ... and before I forget ... to eliminate the need of a node.js environment on that server I compiled the node.js code with nexe so I only have one executable to worry about.

Idea:
Since proxmox already is an enterprise grade postfix solution, wouldn't it be cool to implement similar smtp2xml-functionality? I'm sure a lot of other M365 exchange users would benefit from this. I know I would.

What do you think? Let me know.

Best regards.

 

[dcsapak]

hi,

i don't think we'll implement such a thing, mostly because it's a relatively special and niche use case. Most users simply want to forward to their own mail server and not ingest the mail via some api
also, doesn't the mail lose much of it's structure that way (i.e. multipart messages, text/html alternative parts, attached mails as mimeparts etc...)

 

[PVerberne]

Hi Dominik,

I'm not sure if we're talking about a niche case here. M365 is used a lot and while Microsoft offers the possibility to shut down all local Exchange servers, that means that existing local receive connectors have to be migrated to something else before being able to do that. Granted ... Microsoft offers some possibilities to do smtp for local network based devices such as printers, servers, etc. etc., but when reading the guidelines (and restrictions that they come with) I can tell you that I was disappointed (rate limits, direct connections from company network devices to the internet needed, ...). That's why I came up with my solution.

As far as loss of structure is concerned, I can tell you that the complete mail (read: everything) is converted into XML. The only optimization I did is to convert existing attachments into base64 because that makes life a lot easier for me.

 

[dcsapak]

Microsoft offers some possibilities to do smtp for local network based devices such as printers, servers, etc. etc., but when reading the guidelines (and restrictions that they come with) I can tell you that I was disappointed (rate limits, direct connections from company network devices to the internet needed, ...).

even if you use an api, i guess similar restrictions for rate limit, access control will be there
and couldn't you simply send the emails directly to microsoft after adding the pmg as an mx record?

it seems to me that it's much more complicated to do it this way than simply leveraging existing smtp mechanisms

it may work for you, but i did not see/hear any other customers/users that would need this (thus my wording of a 'niche use case')

 

[PVerberne]

even if you use an api, i guess similar restrictions for rate limit, access control will be there
and couldn't you simply send the emails directly to microsoft after adding the pmg as an mx record?

In this case, API-restrictions, as far as I can tell, are far less restricting than SMTP-restrictions. Apart from that, SMTP-traffic (and other traffic) can not leave our network without help from some kind of proxy/forwarder. Furthermore, most SMTP traffic coming from "dumb" devices is not encrypted and we want to be able to be "in control" when it comes to what is sent to whom. All in all this made us decide going API is the way to go.
Simply using pmg does not solve our problem(s).

it seems to me that it's much more complicated to do it this way than simply leveraging existing smtp mechanisms

it may work for you, but i did not see/hear any other customers/users that would need this (thus my wording of a 'niche use case')

When having to solve all challenges I mentioned earlier, the only way to go for us is SMTP2XML. Perhaps we are niche in that respect, but I kind of hoped we were not .

Anyway ... the solution I will be proposing to my co-workers is to use pmg as a replacement for the SMTP receive connector and use a smarthost mechanism to forward mail to the SMTP2XML solution to inject the XML-messages in our M365-exchange system.

Thanks for telling me your thoughts! Much appreciated.

Best regards.