Mailwizz SMTP Credentials for Outlook

Ramanathan

New Member
i need to create smtp in mailwizz and give the credentials to outlook.
Outlook will send emails, where log of the emails can be seen in mailwizz ?

1, Create SMTP in mailwizz
2, Configure the SMTP in mailwizz
3, Send emails using outlook
4, Track emails using mailwizz. Is that possible ?

Or

I have amazon ses account, i configure ses in outlook, can i get the report of ses in mailwizz ?

Or

Do you have alternative solution to see amazon ses report in mailwizz
 
1, Create SMTP in mailwizz
2, Configure the SMTP in mailwizz
mwz does not by itself 'create' smtp delivery servers, you only configure them in there, to be used by mwz

give the credentials to outlook.
Outlook will send emails
mwz uses smtp credentials to send email, but not the other way around

3, Send emails using outlook
4, Track emails using mailwizz
if you have an outlook/live/hotmail smtp account, you could, but this is not recommendable, better use one of the many third party smtp delivery servers that have free monthly volume

amazon ses account, i configure ses in outlook, can i get the report of ses in mailwizz
since outlook (as a standalone program) would send via smtp and without tracking, you would not get amazon ses reports in mwz

Do you have alternative solution to see amazon ses report in mailwizz
just use the amazon ses web api directly from within mwz, that's what it is there for

:)
 
Hi,

I dont think you understand what MailWizz is or even how to use it properly. What your suggesting to do with Outlook makes no sense what so ever. MailWizz doesnt create SMTP details, you need to create SMTP details from your server/hosting and then tell MailWizz the details in the Delivery Server settings in the Backend.
 
Where do i get amazon ses web api - can use that in outlook ?

My Problem is : I am sending emails from outlook through amazon ses, how do i track delivery,bounces of each email.
Do you have paid application to see the amazon ses report ?


mwz does not by itself 'create' smtp delivery servers, you only configure them in there, to be used by mwz


mwz uses smtp credentials to send email, but not the other way around


if you have an outlook/live/hotmail smtp account, you could, but this is not recommendable, better use one of the many third party smtp delivery servers that have free monthly volume


since outlook (as a standalone program) would send via smtp and without tracking, you would not get amazon ses reports in mwz


just use the amazon ses web api directly from within mwz, that's what it is there for

:)
 
Where do i get amazon ses web api
at amazon ses
but if you meant 'how to set it up w/i mwz', then that is under 'delivery servers' then choose to 'create a new' one, then use 'amazon web api'

can use that in outlook
no, as said above, only smtp would work in outlook (the standalone program)

I am sending emails from outlook through amazon ses, how do i track delivery,bounces of each email
re delivery/bounces: you would have to use the feedback you get from them
re tracking/clicks: you have to use another link tracker (many shorteners have also stats)
 
@twisted1919 :) I actually liked @Ramanathan idea for having facility to accommodate SMTP within for usage with external application and deduct credits based on user's usage like any other proper ESP - SendGrid, SparkPost, etc. I know you're woking on releasing a new version but request you to consider this and what are your thoughts on this?

@frm.mwz your thoughts also... Thanks :D
 
having facility to accommodate SMTP within for usage with external application
Trying to understand what is meant. If you mean an smtp server within mwz (a new mwz internal DS of type smtp similar to exim/sendmail/postfix or like some mailers include EasyMailSmtpExpress or similar), then this could work as long as all authentications are in place, particularly for dynamic IP ranges (since that would harm deliverability). It might add complexity (more points of failure) and exposure (sending directly from mailer IP), but also add flexibility and independence (especially for those corporate emailers who contact previous/paying customers). Done well, it would make mwz more powerful.
If something else was meant, please provide more specifics.
 
Last edited:
@frm.mwz I know it's bit confusing :D For example you signup on SendGrid, SparkPost or ElasticEmail there is a way called SMTP, giving facility to their users if want to use their portal with SMTP credentials. Practically this can be implemented in MailWizz ;)

This way the MailWizz users will be be able to use Application + SMTP Generated Credentials which can be used with third party applications and the credits will be deducted automatically as used with API :)
 
I know it's bit confusing
Because it is not clearly described.

For example you signup on SendGrid, SparkPost or ElasticEmail there is a way called SMTP, giving facility to their users if want to use their portal with SMTP credentials.
This has been there all the time, just use the 'smtp' DS.

use Application + SMTP Generated Credentials
What exactly is meant by 'Application + SMTP Generated Credentials'?

credits will be deducted automatically as used with API
MWZ deducts usage from quota already, it is not clear to me what you mean or what would be new?
 
Hey @frm.mwz / @twisted1919 :) So lets say I want to become next SendGrid or SparkPost and I want to have facility like SMTP relay, for reference: https://sendgrid.com/docs/Classroom/Basics/Email_Infrastructure/recommended_smtp_settings.html https://www.sparkpost.com/blog/setup-sparkpost-smtp-relay/

This gives an ability to application users to also mail using Outlook, Sendblaster, etc. but the credits will be used from their account. This is something available in every ESP.

Looking for your thoughts! :D
 
Hey @frm.mwz / @twisted1919 :) So lets say I want to become next SendGrid or SparkPost and I want to have facility like SMTP relay, for reference: https://sendgrid.com/docs/Classroom/Basics/Email_Infrastructure/recommended_smtp_settings.html https://www.sparkpost.com/blog/setup-sparkpost-smtp-relay/

This gives an ability to application users to also mail using Outlook, Sendblaster, etc. but the credits will be used from their account. This is something available in every ESP.

Looking for your thoughts! :D
This could be achieved with an extension interfacing with whatever smtp engine is being used (exim, sendmail, postfix, postal, green arrow, pmta, mailerq, etc), and would probly need the necessary access rights to create such accounts. The downside would be, that mwz being a mailer, suddenly has to handle that too, although that is not a high load, but more importantly, that access to mwz admin would allow further access elsewhere and that does pose quite a security risk (and woudl require constant monitoring and submitting mwz to a serious security check each update). But in terms of automation, this would certainly be welcome ;)
 
This could be achieved with an extension interfacing with whatever smtp engine is being used (exim, sendmail, postfix, postal, green arrow, pmta, mailerq, etc), and would probly need the necessary access rights to create such accounts. The downside would be, that mwz being a mailer, suddenly has to handle that too, although that is not a high load, but more importantly, that access to mwz admin would allow further access elsewhere and that does pose quite a security risk (and woudl require constant monitoring and submitting mwz to a serious security check each update). But in terms of automation, this would certainly be welcome ;)
Thanks for your thoughts :) Being from datacenter industry and I've talked to few application architects and they have confirmed that this can be easy achievable with some development within main application and it will not effect security of application because SMTP relay works with API like any other ESP's application SparkPost or SendGrid or you integrate MailWizz API for transactional emails on your own website.

Example Workflow: User Generate API Key => Use SMTP Relay details like SparkPost/SendGrid/Etc. => SMTP Relay + API Configure in Email Client (Outlook/SendBlaster/Etc.) => Send Email via Outlook/SendBlaster/Etc. => SMTP Relay => Account Credits Check/Blacklist/Etc. => Send Email or Reject

@twisted1919, what are your thoughts? :D Thanks
 
it will not effect security of application
It is not that this part makes the app insecure necessarily, but it is that any insecure part could allow someone to get in and create smtp accounts and send, and hence suddenly you need to watch that part too, which can be subject to heavy abuse.

Send Email via Outlook/SendBlaster/Etc
That is where dynamic IP ranges may become visible and that can yield quick blocks. So mwz or the smtp would have to strip those headers out, which is another extra feature and possible point of failure that would need to be taken care.

Hopefully there will be a simpler way ;)
 
That is where dynamic IP ranges may become visible and that can yield quick blocks. So mwz or the smtp would have to strip those headers out, which is another extra feature and possible point of failure that would need to be taken care.;)
Thanks for your reply :) But why "dynamic IP ranges may become visible" because when the user will send email from Email Application (Outlook/SendBlaster/Etc.) then the email will be sent from the Assigned Servers to the Group where User belongs to. This feature is commonly available with all ESPs like SendGrid, SparkPost, etc. :D

It will be like sending transactional email from MailWizz API via your Website Actions.

Thanks
 
user will send email from Email Application (Outlook/SendBlaster/Etc
If you use any such application and send email via (even authenticated) smtp, then it will have the IP with mentioned classification in the header and as such be subject to restrictions related to this IP range (not only because these oft cannot have rDNS). If the headers were removed, and no other detection was used (even by the smtp) then it might work, but that would not be possible to guarantee for each user. :oops:

It will be like sending transactional email from MailWizz API via your Website Actions.
Outlook/OutlookExpress/SendBlaster/ThunderBird/GroupMail/AtomicMail/etc do not have a facility to use web api, so it would be an (authenticated) smtp connection, hence the above. :rolleyes:

Maybe there is a better way?
Thx :)
 
If you use any such application and send email via (even authenticated) smtp, then it will have the IP with mentioned classification in the header and as such be subject to restrictions related to this IP range (not only because these oft cannot have rDNS). If the headers were removed, and no other detection was used (even by the smtp) then it might work, but that would not be possible to guarantee for each user. :oops:

Maybe you're right... But I'm unsure that if it will effect the reputation because in the end Sending Server will be assigned within MailWizz with proper authentication :)

Outlook/OutlookExpress/SendBlaster/ThunderBird/GroupMail/AtomicMail/etc do not have a facility to use web api, so it would be an (authenticated) smtp connection, hence the above. :rolleyes:

Yes, in Outlook/OutlookExpress/SendBlaster/, etc. they use SMTP Relay which I gave you reference of SendGrid & SparkPost https://sendgrid.com/docs/Classroom/Basics/Email_Infrastructure/recommended_smtp_settings.html https://www.sparkpost.com/blog/setup-sparkpost-smtp-relay/ :D Have you tried using one of them? They are pretty easy just use, API key is just authentication for email!

Example Workflow:
User Generate API Key => Use SMTP Relay details like SparkPost/SendGrid/Etc. => SMTP Relay + API Configure in Email Client (Outlook/SendBlaster/Etc.) => Send Email via Outlook/SendBlaster/Etc. => SMTP Relay => Account Credits Check/Blacklist/Etc. => Send Email or Reject
 
Maybe you're right... But I'm unsure that if it will effect the reputation because in the end Sending Server will be assigned within MailWizz with proper authentication
If sending happens with those apps (Outlook/OutlookExpress/SendBlaster/ThunderBird/GroupMail/AtomicMail/etc) then the IPs would be in there (unless removed).
If sending happens without those apps, but with mwz, then there would be nothing new, hence no reason for this thread.

in Outlook/OutlookExpress/SendBlaster/, etc. they use SMTP Relay
That 'relay' is why those IPs ranges will be in the header, hence the problems as mentioned above.
Does not matter if SendGrid or SparkPost or ElasticEmail or any of those that allow (authenticated) smtp relay.

Have you tried using one of them?
Many, many (have many dozens on file, but after trial, only few remain in the close selection).
Same thing for all of them, see above.

Example Workflow: User Generate API Key => Use SMTP Relay details like SparkPost/SendGrid/Etc. => SMTP Relay + API Configure in Email Client (Outlook/SendBlaster/Etc.) => Send Email via Outlook/SendBlaster/Etc. => SMTP Relay => Account Credits Check/Blacklist/Etc. => Send Email or Reject
See above, the moment you send via those apps (Outlook/OutlookExpress/SendBlaster/ThunderBird/GroupMail/AtomicMail/etc) by (authenticated) smtp (relay), yes, even with the api key being only the password, then the above mentioned problems arise.
 
If sending happens with those apps (Outlook/OutlookExpress/SendBlaster/ThunderBird/GroupMail/AtomicMail/etc) then the IPs would be in there (unless removed).
If sending happens without those apps, but with mwz, then there would be nothing new, hence no reason for this thread.


That 'relay' is why those IPs ranges will be in the header, hence the problems as mentioned above.
Does not matter if SendGrid or SparkPost or ElasticEmail or any of those that allow (authenticated) smtp relay.


Many, many (have many dozens on file, but after trial, only few remain in the close selection).
Same thing for all of them, see above.


See above, the moment you send via those apps (Outlook/OutlookExpress/SendBlaster/ThunderBird/GroupMail/AtomicMail/etc) by (authenticated) smtp (relay), yes, even with the api key being only the password, then the above mentioned problems arise.
Maybe you're right! But this is a very basic functionality that every ESP (Email Service Provider) like SparkPost, SendGrid, MailGun, etc. are providing to customers :D and I'm sure it won't affect anything because this is very basic in industry. Even till now I've received number of such requests by people.

@twisted1919, looking your thoughts ;) Thanks
 
Last edited:
this is a very basic functionality that every ESP (Email Service Provider) like SparkPost, SendGrid, MailGun, etc. are providing to customers
MWZ = mailer = Email Marketing Application = EMA
(and of course you can add many features and run into unnecessary problems, e.g. backdoor access to mwz, and suddenly each mwz could become a spam bot).
But the point is not if creating smtp accounts is a basic function of an ESP.
It was about using those third party apps (Outlook/OutlookExpress/SendBlaster/ThunderBird/GroupMail/AtomicMail/etc) to send via accounts that do not need to be created in mwz, but are normally created at the admin level of each MTA (for good reason). Mailers usually don't do that, for good reason, but an ESP admin portal can. Some install scripts can do, but that is something entirely different, as they are used at admin level for setup.
In effect you would use mwz to create smtp accounts to be used by other mail apps, while mwz is not an ESP admin portal (yet?!).
Sure those third party smtp providers oft offer a mailer and an MTA (but are you also asking for mwz to include an MTA as well)?
Then the whole thread would perhaps make some more sense?
;)
 
Back
Top