What does it do "Force Sender" ?

[Arta]

Hi !
I presume that Return-Path = "Email" which is defined at "Bounce Server".
I am unclear what does "Force Sender" which is optional at "Delivery Server". There I can't see a form field "Sender Email" similarly as "From Email" or "From name" which are present.
So, what really do "Force Sender" in that form?

I have a couple of sending domains which has its own SMTP server.
I need to use them simultaneously.
I know that I can create a separate Bounce Server for each of them.
But since I can Forward internally all bounces in a single IMAP server, I am trying to figure how to get rid from the creation and using of different Bonce Servers" and how to override under "Delivery Server" that "Sender Email" which is defined under "Bounce Server" .

Any idea?

Thanks in advance.

 

[frm.mwz]

unclear what does "Force Sender" which is optional at "Delivery Server"

If memory serves me well, it forces the x-header 'sender' and that is normally the FROM address as set in the DS, not campaign.

trying to figure how to get rid from the creation and using of different Bonce Servers

If you prefer only one BS, then this will work as long as you don't forget to give that BS all bounces, since mwz looks for sub id and list id when it parses relevant emails.

 

[Arta]

If memory serves me well, it forces the x-header 'sender' and that is normally the FROM address as set in the DS, not campaign.

Meanwhile I did some tests and it force the x-header 'sender' to be as it is set in Bounce Server.

If you prefer only one BS, then this will work as long as you don't forget to give that BS all bounces, since mwz looks for sub id and list id when it parses relevant emails.

Ok, but the situation is a little different.
I think that is important to match at domain level:
"From Email", "Sender Email", Tracking Domain and PTR record.
contact@domain1.com, bounce@domain1.com, domain1.com, server.domain1.com

Assuming that PTR record is fixed, in 'Delivery Server' I can force to match with PTR only "From Email" and "Tracking Domain".
Of course I can match the "Sender Email" assigning the appropriate BS.
But if I have 'n' sending servers, to achieve the perfect matching I'm forced to create 'n' Bounce Servers.
contact@domain1.com, bounce@domain1.com, domain1.com, server.domain1.com
contact@domain2.com, bounce@domain2.com, domain2.com, server.domain2.com
...........
contact@domain'n'.com, bounce@domain'n'.com, domain'n'.com, server.domain'n'.com

Perhaps this thread may also serve as a suggestion to add the "Sender email" field in 'Delivery Servers" form.





If I have 2 servers

 

[frm.mwz]

Meanwhile I did some tests and it force the x-header 'sender' to be as it is set in Bounce Server.

That's probably because your FROM and BOUNCE differ. Ideally they are the same, so that the receiving server has 'no choice' and also the filters don't start 'thinking'

I think that is important to match at domain level:
"From Email", "Sender Email", Tracking Domain and PTR record.
contact@domain1.com, bounce@domain1.com, domain1.com, server.domain1.com

Yes, such consistency is useful.

Assuming that PTR record is fixed, in 'Delivery Server' I can force to match with PTR only "From Email" and "Tracking Domain".
Of course I can match the "Sender Email" assigning the appropriate BS.
But if I have 'n' sending servers, to achieve the perfect matching I'm forced to create 'n' Bounce Servers.
contact@domain1.com, bounce@domain1.com, domain1.com, server.domain1.com
contact@domain2.com, bounce@domain2.com, domain2.com, server.domain2.com
...........
contact@domain'n'.com, bounce@domain'n'.com, domain'n'.com, server.domain'n'.com

If it is for various businesses, then it might not be a big investment to set this up once.
If it is for various customers, then they can do it themselves, saving you time.

Perhaps this thread may also serve as a suggestion to add the "Sender email" field in 'Delivery Servers" form.

This is a good idea. It might be a problem if there is no BS (or forwarder) yet and would need to be created for the sender address to match, and this might be the reason it is not there in the first place. I think something like this was suggested before, for good reasons, but it might create risks and complexity.

 

[Arta]

Considering these alternatives:
a) Matching "From" and "Sender" (no use "Force Sender")
b) Matching "Sender Email", "Tracking Domain" and "PTR record"
Which of them is the best practice to follow ?

 

[frm.mwz]

Considering these alternatives:
a) Matching "From" and "Sender" (no use "Force Sender")
b) Matching "Sender Email", "Tracking Domain" and "PTR record"
Which of them is the best practice to follow ?

Short answer:
-------------
neither


Long answer:
------------
If you are looking for best inboxing, then maybe the question is about how to least upset spamfilters, which would oft check for correct
rDNS/PTR (on greeting mail servers)
SPF (if the IP is authorized to send)
DKIM (if the domain of the sender address is designated)
DMARC (how firm and interested you are re the validity of your SPF and DKIM)
ham/spam (spam assassin's results re message content)

If there is no match between
sender email domain
tracking domain
rDNS/PTR
will not matter, as many times you have a valid sending domain, very safe tracking domain, and correct rDNS/PTR, all three not matching, and it might inbox, or not, depending on the citeria mentioned one paragraph above this one.
Same goes for FROM = sender, not being a guarantee.

But it is much better to have all clear from the 1st paragraph, and use the same for
FROM/ReplyTo/ReturnPath/Sender.

 

[Arta]

Updated to 1.5
Now I'm not seeing any difference between forcing sender "Yes" or "No".
All times the Return-Path is the same as it is fixed at "Bounce server". (@domain1)
Of course, to be not confused, I have used a different "From". (@domain2)

Any help or suggestion would be precious.

 

[frm.mwz]

Updated to 1.5
Now I'm not seeing any difference between forcing sender "Yes" or "No".
All times the Return-Path is the same as it is fixed at "Bounce server". (@domain1)
Of course, to be not confused, I have used a different "From". (@domain2)

Any help or suggestion would be precious.

You don't have to assign a bounce server.