Beside selecting a bounce server, allow adding a return path in delivery servers.

twisted1919

twisted1919

Administrator
Staff member
Right now, mailwizz knows what return path to set in emails based on the bounce server you assign to the delivery server.
We force adding a bounce server and associate it with the delivery servers because this way we can make sure your bounces will be processed since there will be a bounce server waiting to process them.

Now, @AHK suggests that we should also allow adding the return path address directly, without the need of adding a bounce server and selecting it, so the two options would coexist. The problem with this is that you might add the return path here and forget to add a bounce server and all the bounces won't be processed anymore and this is why i am sceptic to implementing it, plus, it worked very well as is for years.

I think it would also add some confusion to the table, because you'd see two ways to select the return path, one by adding it manually and the other by selecting a bounce server.
Obviously we can't remove the bounce servers select from the delivery server form.

What do you say ?
 
Hello @twisted1919
I think this is vary important feature and it should be part of mailwizz such a nice application for following reasons

1. Now we have to add bounce server for each sending server if we are going to assign that each sending server to one customer, like if some one have 100 customers and assign 100 sending servers then he also need to create 100 bounce servers and yes 100 email INBOX (each for every customer), the way i suggest is we will have one common bounce server for all Application and we can assign that return path to every customer.
this will reduce work of creating 100 bounce servers and 100 INBOX, instead we will create one Bounce server.
this will also reduce so much load on application while processing 100 bounce servers or only 1 bounce server for all application.

now the question is if we want different return address for each customer, yes we will create forward return address to actual bounce address.

but at same time if some one want to have different bounce server, he will have same option as of now.

2. I am sure every one here using MailWizz knows how it works and most of us do lot of custom changes also i don't think we will be confuse.

3. When i check every other application like Interspire, mumara and many other they all have option of adding simple return path.

4. Like other email services which get bounces on IP address like MailChimp, Sparkpost etc, how can we do that in MailWizz ? no way but with return path, we will just create one forward address and we can have bounces on each IP.

5. Also when we edit any delivery server and in same time bounce server attach to that delivery server cron job is running is gone missing from delivery sever and if we save the delivery server, we will lost the bounce server and it happen to me many times, so now i only edit delivery server when cron job is not running.

6. May of us here having problem with bounce not showing cause some time bounce server get removed from delivery server (point 5) or if one bounce server STUCK, all other bounces can't process

7. Also I have to monitor many bounce inbox and address.

This is really vary important feature & I hope this will be done in this release.

Thanks
 
if we were to implement the above, it still bothers me to keep the dropdown for the bounce servers and also have another field to insert the return path.
If i find a way to populate the return_path field with the email address used in the bounce server, should we then remove the bounce server dropdown from the delivery server settings? I'd say yes...
 
If im understanding this correctly, we create the bounce servers the same way, and then just use a dropdown per customer for bounce server settings? The concept and idea of a few bounce servers as opposed to 1 per customer makes a ton of sense ... if there will be no negative impact on deliverability (for some reason I was reading/dreaming/nightmare that when the bounce server address domain didnt match the sender domain that there could be some potential issues with DKIM/SPF)
 
@dodgedesigns - your understanding is correct :) Also, this won't affect the way delivery is made. This change is only on the surface of things, under the hood things don't really change at all ;)
 
twisted1919 said:
If i find a way to populate the return_path field with the email address used in the bounce server, should we then remove the bounce server dropdown from the delivery server settings? I'd say yes...
Click to expand...

Yes and we can test it our self

@dodgedesigns
yes we are only removing lot of work for creating 100s of bounce servers to one.
 
@AHK - While working on this stuff, i found a little gem in the app. It seems that you can set whatever return-Path value by setting a custom header in the delivery server, so you can do this:
Screenshot 2017-04-13 18.37.06.png

So the "X-Force-Return-Path" will do exactly what you're after.

Can you check this and confirm?
 
@twisted1919 oh great, then i just don't select any bounce server and add this X-Force-Return-Path header.

i will check & it worked.
:)
 
Last edited:
Hello @twisted1919,
I find out one thing and want to share with you, that if we use
X-Force-Return-Path
Its working but have some issue
1. If I use Swift Mailer it work but in email boy have two return-path: (i check in gmail)
2. if I use PHPMailer it not working, got only one return path in email boy but X-Force-Return-Path value not set.


could you please check and advise me how to fix that and got it working with PHPMailer or Swift Mailer?
 
AHK said:
1. If I use Swift Mailer it work but in email boy have two return-path: (i check in gmail)
Click to expand...
This is because most likely your smtp server adds one too.

AHK said:
2. if I use PHPMailer it not working, got only one return path in email boy but X-Force-Return-Path value not set.
Click to expand...
True, looking inside phpmailer, i can see this comment:
Code: 
/**
* The Return-Path of the message.
* If empty, it will be set to either From or Sender.
* @var string
* @deprecated Email senders should never set a return-path header;
* it's the receiver's job (RFC5321 section 4.4), so this no longer does anything.
* @link https://tools.ietf.org/html/rfc5321#section-4.4 RFC5321 reference
*/
So they don't set it anymore.
 
twisted1919 said:
This is because most likely your smtp server adds one too.
Click to expand...
That means one could end up with three alone for the ReturnPath, one from the mailer, one from the 3rd party, one from the x-force...better keep it simple :D

twisted1919 said:
So they don't set it anymore.
Click to expand...
Then it's good the x-force is there ;)

Keep in mind that while some recipient servers will respect/blindly follow
your set Return Path, others will ignore it and only use the FROM address.

This is why it is best (even for inboxing) to just use FROM = ReturnPath = ReplyTo.
Though it might not be easy (or even possible to do this in all environments) :rolleyes:
 
frm.mwz said:
How do you 'force' for sure
one, and only one, return path?
Click to expand...
You can't. The smtp server you handle the email to is the one that in the end has the power to use whatever it sees fit to use.
What mailwizz does, is it makes sure it sets the return-path as it should, but after the email leaves mailwizz, there's nothing else we can do.
 
twisted1919 said:
You can't. The smtp server you handle the email to is the one that in the end has the power to use whatever it sees fit to use.
What mailwizz does, is it makes sure it sets the return-path as it should, but after the email leaves mailwizz, there's nothing else we can do.
Click to expand...
Exactly! :cool: So in consequence, only if FROM = ReturnPath = ReplyTo = Sender can the outcome be pre-determined :D
 
You must log in or register to reply here.
Back
Top