email address in 'Errors' appears as being also the email address in 'From'

[georgeangelos]

If I specify some email address in the field 'Errors' then this same email address appears as being the one from which the posting was sent, i.e. the email address in 'From' is not used. For example, if the email address in 'From' is [email protected] and the email address in 'Errors' is [email protected], then when the message is sent, it appears that the sender (i.e. what is in 'From') is [email protected] and not [email protected]. The Reply-To is what is expected to be ([email protected]). This is confirmed by the logs where in 'MAIL FROM' I see [email protected].

My admin people say this is a problem, as such messages are considered spam.

I use version 8.7.5.

 

[stanbusk]

The 'Errors' field only modifies the 'MAIL FROM' command, all the other headers remain untouched. If your server doesn't accept that just stop using the 'Errors' field. You will then received the bounces to your regular FROM address.

 

[georgeangelos]

The 'Errors' field only modifies the 'MAIL FROM' command, all the other headers remain untouched. If your server doesn't accept that just stop using the 'Errors' field. You will then received the bounces to your regular FROM address.

That's what I also said. That the 'MAIL FROM' field shows the email address specified in 'Errors'. The problem is not that *our* server doesn't like it. My admin people showed me the logs that apparently show that servers out there don't like it and refuse to accept the emails. I could forward to you these logs in private. So, maybe the 'MAIL FROM' field should show the real sender address and not the one specified in 'Errors'.

 

[stanbusk]

If you ut nothing in the Errors field then the MAIL FROM command will use the real sender address, the same sender as in the message headers.

 

[georgeangelos]

Indeed, this will happen. The point that I am trying to make here, is that the feature of having an additional field for "Errors" is implemented in a problematic way, in the sense that many servers out there interpret the behaviour of the implementation in question as a "spam pattern". So, my very humble suggestion is to either: a) remove this feature, b) implement it in a different way that is not considered spam behaviour, c) at least, inform in the documentation the user that this feature may be considered as spam behaviour by some servers. Just my 2 cents.

 

[stanbusk]

There is no other way to implement this feature actually. That feature alters the Return-Path header as explained here: https://www.mailjet.com/blog/news/return-path-customization-explained/ however a server is free to override that header or reject the message.