We would like to make sure that users need to authenticate with their credentials in order to be able to send an email FROM their email address, so that noone else can send an email using their email address.
Are you sharing this email node in a component and letting others use it, sharing the full workflow, or running this on a server?
Ideally each user does not have access to send emails on behalf of everyone and can only use the SMTP connection for themselves - using the authentication fields for their own credentials… but I understand this is not always possible.
Hi @MarcEM first of all, back in the days (some 25 years ago) most SMTP servers did not require authentication, and as such, they did not enforce much, and you could send on behalf of anyone (basically you could add an email address as From).
Today, most SMTP servers require authentication, and automatically fill the From information based on the profile you authenticated with.
Secondly, that being said, a user must authenticate in order to use the STMP server. Like anything that “saves” a password (browser, software (email clients, ftp clients, etc)), if you save the password, then anyone who uses the browser or software will be using them as the saved credentials.
This applies to Knime too - hence the questions from @wkhan “Are you sharing this email node in a component and letting others use it, sharing the full workflow, or running this on a server?”
So, it depends on what you are doing and how you are set up. If we can get some answers to these questions, they will allow us to advise and help you.
When I have automated emails via KNIME or Alteryx, I typically create function specific email address to handle it (like reports@domain.com or billing@domain.com) and then include all appropriate internal and external addresses via send & cc.
This avoids a lot of organizational issues vs automating emails through employee / individual accounts, and it gives you a few clean master accounts to test and verify email traffic when issues / questions arise on the delivery side.
This may not be applicable to your situation if you are trying to automate personalized marketing emails or something, but I wanted to throw the concept out there in case it was helpful…
We had this exact same problem and it was flagged as a risk. IT in charge of Microsoft has to set the system to prevent this from occurring. If it is not explicitly set, it could lead to the issues you describe - of anyone sending an email ‘from’ any email address within that domain.
Further, if you’re using the KNIME Server you can leverage the Credentials Configuration nodes to pick up the KNIME username and password (assuming you have LDAP in place). These credentials can be passed through to the Send Email node, so only the person logging into the Server can send an email from their own email address.
We have Office365 and we use Azure AD, so we should be using as SMTP host: smtp.office365.com. However, as explained in Send Email with Microsoft Outlook it is only possible to set-up a password for the application and user that has this password, will be able to use any email in the “FROM (your email)” field.
Is it possible to use the Microsoft Authentication node to authenticate users and to allow them to use the Send Email node just with their email address in the FROM field?
Or is there another way to do that?
PS: just to clarify I want to share with the users the possibility for them to use this node in order to build some workflows locally and then once completed we can move to the server, but before that I have to make sure they cannot use this node to send emails in behalf of anyone.
“have to make sure they cannot use this node to send emails in behalf of anyone.” - this needs to be set up on the Microsoft Admin side, not within KNIME. This eliminates the need to introduce Microsoft nodes at all. To be clear, sending emails from someone else’s account is not within KNIME’s control. I’d recommend to speak with your internal IT, it is likely a security risk in their setup.
If still needed, possibly use Microsoft Authentication followed by the Credentials Extractor node, which may extract the Microsoft username and password (hidden) and make it available as a flow variable. I’ve not tried this personally but it may work…
