Mixing
![false statements made about me to HR [closed]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjbpfN9tAutmK93bJRC3ZoROZzi2TJDms5n8_qJuhgE0a9b52OOHayv3NGT8igAdFL7byXNst-_1DZK5SjrIJ28_6RQPUpBROqMs5s6jo-ZsjX8kjDwfxJufIitH3TaQRXWaGSQKRQib-f/s72-c/1.jpg)
Forged FROM: header despite reject_authenticated_sender_login_mismatch
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
structural description
- Server A runs postfix and acts as smarthost for server B (also running postfix), reject_authenticated_sender_login_mismatch is set and works (almost) as expected, see below
- Client C's MUA sends mails via Server A
- B and C both connect via submission port and authentificate with STARTTLS
what happens when trying to forge sender
- Setting an arbitrary FROM: header by changing the sender address in thunderbird or adding a new identity in roundcube leads to the expected result: the mail is declined
- doing the same using
mail -s "This is a Subject" -a "From: forged_address@example.net"on Server B using A as Smarthost results in successfully sending the mail
observed differences
The following was observed by increasing the verbosity of postfix' smtpd
- thunderbird and roundcube login and then directly set the
FROM:to an accepted value Server B starts in the same way but somehow manages to change the
FROM:header afterwards. This cannot be seen in postfix smtpd logfile but in the mail which is finally sent:Return-Path: <valid_address@example.com>
Delivered-To: herrhannes@example.com
Received: from mail.example.com
by mail.example.com (Dovecot) with LMTP id UuV2IVaP3lvdKAAAEby5rg
for <herrhannes@example.com>; Sun, 04 Nov 2018 07:19:02 +0100
To: herrhannes@example.com
Subject: This is a Subject
From: forged_address@example.com
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Message-Id: <20181104061902.15A9F4A9@debian.example.com>
Date: Sun, 4 Nov 2018 07:19:02 +0100 (CET)
Authentication-Results: ORIGINATING;
auth=pass smtp.auth=valid_address@example.com
smtp.mailfrom=valid_address@example.com
body of your email- at least it is not (as opposed to valid mails) DKIM signed
- This is not spam, I just do not want that "everybody" is able to forge sender addresses
questions
- Why does this happen?
- More important: What can I do to prevent it happening?
postfix smarthost
asked 5 hours ago
herrhannes
132
New contributor
herrhannes is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
2
down vote
favorite
structural description
- Server A runs postfix and acts as smarthost for server B (also running postfix), reject_authenticated_sender_login_mismatch is set and works (almost) as expected, see below
- Client C's MUA sends mails via Server A
- B and C both connect via submission port and authentificate with STARTTLS
what happens when trying to forge sender
- Setting an arbitrary FROM: header by changing the sender address in thunderbird or adding a new identity in roundcube leads to the expected result: the mail is declined
- doing the same using
mail -s "This is a Subject" -a "From: forged_address@example.net"on Server B using A as Smarthost results in successfully sending the mail
observed differences
The following was observed by increasing the verbosity of postfix' smtpd
- thunderbird and roundcube login and then directly set the
FROM:to an accepted value Server B starts in the same way but somehow manages to change the
FROM:header afterwards. This cannot be seen in postfix smtpd logfile but in the mail which is finally sent:Return-Path: <valid_address@example.com>
Delivered-To: herrhannes@example.com
Received: from mail.example.com
by mail.example.com (Dovecot) with LMTP id UuV2IVaP3lvdKAAAEby5rg
for <herrhannes@example.com>; Sun, 04 Nov 2018 07:19:02 +0100
To: herrhannes@example.com
Subject: This is a Subject
From: forged_address@example.com
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Message-Id: <20181104061902.15A9F4A9@debian.example.com>
Date: Sun, 4 Nov 2018 07:19:02 +0100 (CET)
Authentication-Results: ORIGINATING;
auth=pass smtp.auth=valid_address@example.com
smtp.mailfrom=valid_address@example.com
body of your email- at least it is not (as opposed to valid mails) DKIM signed
- This is not spam, I just do not want that "everybody" is able to forge sender addresses
questions
- Why does this happen?
- More important: What can I do to prevent it happening?
postfix smarthost
asked 5 hours ago
herrhannes
132
New contributor
herrhannes is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
structural description
- Server A runs postfix and acts as smarthost for server B (also running postfix), reject_authenticated_sender_login_mismatch is set and works (almost) as expected, see below
- Client C's MUA sends mails via Server A
- B and C both connect via submission port and authentificate with STARTTLS
what happens when trying to forge sender
- Setting an arbitrary FROM: header by changing the sender address in thunderbird or adding a new identity in roundcube leads to the expected result: the mail is declined
- doing the same using
mail -s "This is a Subject" -a "From: forged_address@example.net"on Server B using A as Smarthost results in successfully sending the mail
observed differences
The following was observed by increasing the verbosity of postfix' smtpd
- thunderbird and roundcube login and then directly set the
FROM:to an accepted value Server B starts in the same way but somehow manages to change the
FROM:header afterwards. This cannot be seen in postfix smtpd logfile but in the mail which is finally sent:Return-Path: <valid_address@example.com>
Delivered-To: herrhannes@example.com
Received: from mail.example.com
by mail.example.com (Dovecot) with LMTP id UuV2IVaP3lvdKAAAEby5rg
for <herrhannes@example.com>; Sun, 04 Nov 2018 07:19:02 +0100
To: herrhannes@example.com
Subject: This is a Subject
From: forged_address@example.com
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Message-Id: <20181104061902.15A9F4A9@debian.example.com>
Date: Sun, 4 Nov 2018 07:19:02 +0100 (CET)
Authentication-Results: ORIGINATING;
auth=pass smtp.auth=valid_address@example.com
smtp.mailfrom=valid_address@example.com
body of your email- at least it is not (as opposed to valid mails) DKIM signed
- This is not spam, I just do not want that "everybody" is able to forge sender addresses
questions
- Why does this happen?
- More important: What can I do to prevent it happening?
postfix smarthost
asked 5 hours ago
herrhannes
132
New contributor
herrhannes is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
structural description
- Server A runs postfix and acts as smarthost for server B (also running postfix), reject_authenticated_sender_login_mismatch is set and works (almost) as expected, see below
- Client C's MUA sends mails via Server A
- B and C both connect via submission port and authentificate with STARTTLS
what happens when trying to forge sender
- Setting an arbitrary FROM: header by changing the sender address in thunderbird or adding a new identity in roundcube leads to the expected result: the mail is declined
- doing the same using
mail -s "This is a Subject" -a "From: forged_address@example.net"on Server B using A as Smarthost results in successfully sending the mail
observed differences
The following was observed by increasing the verbosity of postfix' smtpd
- thunderbird and roundcube login and then directly set the
FROM:to an accepted value Server B starts in the same way but somehow manages to change the
FROM:header afterwards. This cannot be seen in postfix smtpd logfile but in the mail which is finally sent:Return-Path: <valid_address@example.com>
Delivered-To: herrhannes@example.com
Received: from mail.example.com
by mail.example.com (Dovecot) with LMTP id UuV2IVaP3lvdKAAAEby5rg
for <herrhannes@example.com>; Sun, 04 Nov 2018 07:19:02 +0100
To: herrhannes@example.com
Subject: This is a Subject
From: forged_address@example.com
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Message-Id: <20181104061902.15A9F4A9@debian.example.com>
Date: Sun, 4 Nov 2018 07:19:02 +0100 (CET)
Authentication-Results: ORIGINATING;
auth=pass smtp.auth=valid_address@example.com
smtp.mailfrom=valid_address@example.com
body of your email- at least it is not (as opposed to valid mails) DKIM signed
- This is not spam, I just do not want that "everybody" is able to forge sender addresses
questions
- Why does this happen?
- More important: What can I do to prevent it happening?
postfix smarthost
postfix smarthost
asked 5 hours ago
herrhannes
132
New contributor
herrhannes is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 5 hours ago
herrhannes
132
New contributor
herrhannes is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 5 hours ago
herrhannes
132
New contributor
herrhannes is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 5 hours ago
herrhannes
132
asked 5 hours ago
herrhannes
132
132
New contributor
herrhannes is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
herrhannes is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
herrhannes is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
This is expected behavior, as the SMTP envelope sender and From: header are separate things. The reject_sender_login_mismatch (and the version limited to authenticated users only) prevents using an address in SMTP MAIL FROM command unless it matches an SASL authenticated owner. It doesn't care what's inside the message – that's including its headers. That's how email was designed, and there are also many legitimate reasons for this mismatch.
When using mail -a you modify the headers, alone. It's not changed afterwards, as you suggest. The only reason you can't do this with Thunderbird is that it uses the same address in both envelope and header. It's not limited by your server.
answered 3 hours ago
Esa Jokinen
21.6k23157
Thunderbird does not always use the same address in both envelope and header. Afaik mismatches are always caused by bugs, but since those have not been resolved for years, one should not depend on Thunderbird behaving one way or another.
– anx
3 hours ago
Aaah.That explains it a lot. Although it is not what I would have wanted to hear. Thank you very much! I would have thought this was somehow related.
– herrhannes
3 hours ago
This is not really a problem as the envelope sender is recorded toReturn-Pathand to the logs. If you suspect someone using this feature illegitimately (e.g. you receive abuse reports), you can always suspend their accounts.
– Esa Jokinen
3 hours ago
Yes that is correct. And abuse is really improbable, as it is my private mail server. It's just sort of a cosmetic issue.
– herrhannes
2 hours ago
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
This is expected behavior, as the SMTP envelope sender and From: header are separate things. The reject_sender_login_mismatch (and the version limited to authenticated users only) prevents using an address in SMTP MAIL FROM command unless it matches an SASL authenticated owner. It doesn't care what's inside the message – that's including its headers. That's how email was designed, and there are also many legitimate reasons for this mismatch.
When using mail -a you modify the headers, alone. It's not changed afterwards, as you suggest. The only reason you can't do this with Thunderbird is that it uses the same address in both envelope and header. It's not limited by your server.
answered 3 hours ago
Esa Jokinen
21.6k23157
Thunderbird does not always use the same address in both envelope and header. Afaik mismatches are always caused by bugs, but since those have not been resolved for years, one should not depend on Thunderbird behaving one way or another.
– anx
3 hours ago
Aaah.That explains it a lot. Although it is not what I would have wanted to hear. Thank you very much! I would have thought this was somehow related.
– herrhannes
3 hours ago
This is not really a problem as the envelope sender is recorded toReturn-Pathand to the logs. If you suspect someone using this feature illegitimately (e.g. you receive abuse reports), you can always suspend their accounts.
– Esa Jokinen
3 hours ago
Yes that is correct. And abuse is really improbable, as it is my private mail server. It's just sort of a cosmetic issue.
– herrhannes
2 hours ago
add a comment |Â
up vote
2
down vote
accepted
This is expected behavior, as the SMTP envelope sender and From: header are separate things. The reject_sender_login_mismatch (and the version limited to authenticated users only) prevents using an address in SMTP MAIL FROM command unless it matches an SASL authenticated owner. It doesn't care what's inside the message – that's including its headers. That's how email was designed, and there are also many legitimate reasons for this mismatch.
When using mail -a you modify the headers, alone. It's not changed afterwards, as you suggest. The only reason you can't do this with Thunderbird is that it uses the same address in both envelope and header. It's not limited by your server.
answered 3 hours ago
Esa Jokinen
21.6k23157
Thunderbird does not always use the same address in both envelope and header. Afaik mismatches are always caused by bugs, but since those have not been resolved for years, one should not depend on Thunderbird behaving one way or another.
– anx
3 hours ago
Aaah.That explains it a lot. Although it is not what I would have wanted to hear. Thank you very much! I would have thought this was somehow related.
– herrhannes
3 hours ago
This is not really a problem as the envelope sender is recorded toReturn-Pathand to the logs. If you suspect someone using this feature illegitimately (e.g. you receive abuse reports), you can always suspend their accounts.
– Esa Jokinen
3 hours ago
Yes that is correct. And abuse is really improbable, as it is my private mail server. It's just sort of a cosmetic issue.
– herrhannes
2 hours ago
add a comment |Â
up vote
2
down vote
accepted
up vote
2
down vote
accepted
This is expected behavior, as the SMTP envelope sender and From: header are separate things. The reject_sender_login_mismatch (and the version limited to authenticated users only) prevents using an address in SMTP MAIL FROM command unless it matches an SASL authenticated owner. It doesn't care what's inside the message – that's including its headers. That's how email was designed, and there are also many legitimate reasons for this mismatch.
When using mail -a you modify the headers, alone. It's not changed afterwards, as you suggest. The only reason you can't do this with Thunderbird is that it uses the same address in both envelope and header. It's not limited by your server.
answered 3 hours ago
Esa Jokinen
21.6k23157
This is expected behavior, as the SMTP envelope sender and From: header are separate things. The reject_sender_login_mismatch (and the version limited to authenticated users only) prevents using an address in SMTP MAIL FROM command unless it matches an SASL authenticated owner. It doesn't care what's inside the message – that's including its headers. That's how email was designed, and there are also many legitimate reasons for this mismatch.
When using mail -a you modify the headers, alone. It's not changed afterwards, as you suggest. The only reason you can't do this with Thunderbird is that it uses the same address in both envelope and header. It's not limited by your server.
answered 3 hours ago
Esa Jokinen
21.6k23157
answered 3 hours ago
Esa Jokinen
21.6k23157
answered 3 hours ago
Esa Jokinen
21.6k23157
answered 3 hours ago
Esa Jokinen
21.6k23157
21.6k23157
Thunderbird does not always use the same address in both envelope and header. Afaik mismatches are always caused by bugs, but since those have not been resolved for years, one should not depend on Thunderbird behaving one way or another.
– anx
3 hours ago
Aaah.That explains it a lot. Although it is not what I would have wanted to hear. Thank you very much! I would have thought this was somehow related.
– herrhannes
3 hours ago
This is not really a problem as the envelope sender is recorded toReturn-Pathand to the logs. If you suspect someone using this feature illegitimately (e.g. you receive abuse reports), you can always suspend their accounts.
– Esa Jokinen
3 hours ago
Yes that is correct. And abuse is really improbable, as it is my private mail server. It's just sort of a cosmetic issue.
– herrhannes
2 hours ago
add a comment |Â
Thunderbird does not always use the same address in both envelope and header. Afaik mismatches are always caused by bugs, but since those have not been resolved for years, one should not depend on Thunderbird behaving one way or another.
– anx
3 hours ago
Aaah.That explains it a lot. Although it is not what I would have wanted to hear. Thank you very much! I would have thought this was somehow related.
– herrhannes
3 hours ago
This is not really a problem as the envelope sender is recorded toReturn-Pathand to the logs. If you suspect someone using this feature illegitimately (e.g. you receive abuse reports), you can always suspend their accounts.
– Esa Jokinen
3 hours ago
Yes that is correct. And abuse is really improbable, as it is my private mail server. It's just sort of a cosmetic issue.
– herrhannes
2 hours ago
Thunderbird does not always use the same address in both envelope and header. Afaik mismatches are always caused by bugs, but since those have not been resolved for years, one should not depend on Thunderbird behaving one way or another.
– anx
3 hours ago
Thunderbird does not always use the same address in both envelope and header. Afaik mismatches are always caused by bugs, but since those have not been resolved for years, one should not depend on Thunderbird behaving one way or another.
– anx
3 hours ago
Aaah.That explains it a lot. Although it is not what I would have wanted to hear. Thank you very much! I would have thought this was somehow related.
– herrhannes
3 hours ago
Aaah.That explains it a lot. Although it is not what I would have wanted to hear. Thank you very much! I would have thought this was somehow related.
– herrhannes
3 hours ago
This is not really a problem as the envelope sender is recorded to
Return-Path and to the logs. If you suspect someone using this feature illegitimately (e.g. you receive abuse reports), you can always suspend their accounts.– Esa Jokinen
3 hours ago
This is not really a problem as the envelope sender is recorded to
Return-Path and to the logs. If you suspect someone using this feature illegitimately (e.g. you receive abuse reports), you can always suspend their accounts.– Esa Jokinen
3 hours ago
Yes that is correct. And abuse is really improbable, as it is my private mail server. It's just sort of a cosmetic issue.
– herrhannes
2 hours ago
Yes that is correct. And abuse is really improbable, as it is my private mail server. It's just sort of a cosmetic issue.
– herrhannes
2 hours ago
add a comment |Â
herrhannes is a new contributor. Be nice, and check out our Code of Conduct.
herrhannes is a new contributor. Be nice, and check out our Code of Conduct.
herrhannes is a new contributor. Be nice, and check out our Code of Conduct.
herrhannes is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f938548%2fforged-from-header-despite-reject-authenticated-sender-login-mismatch%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
