[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix outbound.bounce_message To: header (and add Auto-Submitted) #2782

Merged
merged 3 commits into from
Apr 13, 2020

Conversation

sriccio
Copy link
Contributor
@sriccio sriccio commented Apr 8, 2020

While dealing with an infinite bounce loop, I've noticed that the To: header in the example template for outbound.bounce_message is {from}.

I guess this should be {to} (or am I wrong?)

I've added Auto-Submitted header also to indicate this is an automated reply.

Checklist:

  • docs updated
  • tests updated
  • Changes updated

sriccio added 2 commits April 8, 2020 06:34
While dealing with an infinite bounce loop, I've noticed that the To: header in the example template for outbound.bounce_message is {from}.

I guess this should be {to} (or am I wrong?)

I've added Auto-Submitted header also to indicate this is an automated reply.
@msimerson
Copy link
Member

I guess this should be {to} (or am I wrong?)

The bounce is a new message that we're creating, and we're sending it back to the sender. Right? Therefore, the {to} address should be {from}. I think.

@sriccio
Copy link
Contributor Author
sriccio commented Apr 10, 2020

Hi,

Well, I'm not really sure, that's why I ask.

But in our case haraka was setting <> as the To: header field because the MAIL FROM (sender enveloppe) from was <> (a mailer daemon).

Setting it to {to} instead of {from} resolved the issue because then the To: header was set to the correct recipient instead of <>.

Not sure i'm really clear in explaining here :)

EDIT:
So in the mail client of the account receiving the bounce it displayed:
Sender: mailer-daemon@harakabox.tld
Recipient: "unknownadress@unknowndomain" (because of To: header set to <>)
So it means to me that the bounce used the correct return path but populated the To header with the MAIL FROM received by haraka (<>)
That's what triggered me to try {to} instead of {from}

EDIT2: this started to happen when I used the outbound.bounce_message* from the example config dir on the git. Before this it was using the "correct" To: header when boucing.

EDIT3: This seems to happen when the bouncing mail is originally from an autoresponder or mailer-daemon (which uses <> as enveloppe-sender)

@sriccio
Copy link
Contributor Author
sriccio commented Apr 12, 2020

Hello,

To be sure I wasn't completly out of my mind, I did a new simple test:

Scenario:

I'm sending a mail from a mailbox on a mailserver that uses haraka as outgoing gateway to relay the mail, this to an invalid recipient (the target user doesn't exists on target mail system).

Here are the bounce messages I receive:

  1. When using To: {from} in the outbound.bounce_message file:
    mailer_daemon_with_from
    Headers found in returned bounce message:
Return-Path: <>
[cut]
From: MAILER-DAEMON@mta-gw.swisscenter.net
To: <>
[cut]
  1. When using To: {to} in the outbound.bounce_message file:
    mailer_daemon_with_to

Headers found in returned bounce message:

Return-Path: <>
[cut]
From: MAILER-DAEMON@mta-gw.swisscenter.net
To: <originalsender@mailserver.ch>
[cut]

So it looks that actually {from} {to} variables actually resolves to the values from the outgoing bounce message, not the from original message.
Therefore using To: {from} resolves to <> which is the MAIL FROM of the generated bounce (and not the actual recipient of the bounce)
Using To: {to} here resolves to the recipient of the bounce (the original sender that triggered the bounce).

Does it makes sense ? It's a bit difficult for me to explain. English is not my mothertongue.

Thank you for reading :)
Kind regards

@baudehlo baudehlo merged commit 86963fc into haraka:master Apr 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants