Re: [mailop] forwarding to gmail - problem

[Byung-Hee HWANG via mailop]

Byung-Hee HWANG via mailop  writes:

> ... snip ...
> Most emails arrive at INBOX (soyeo...@gmail.com), exactly.

There is only 0.1%'s email to spam folder.
99.9%'s emails settle down INBOX without error.

Another screenshot: (2022-05-03)


Sincerely, Linux fan Byung-Hee

-- 
^고맙습니다 _布德天下_ 감사합니다_^))//
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Outlook Sender Support Complaint Messages Broken With DMARC

[Tobias Fiebig via mailop]

Heho,
I signed up for the sender support (sendersupport.olc ) of Microsoft and 
activated forwarding of messages flagged by users as spam. Today I saw an email 
sent by microsoft to postmaster@ with a from of one of my domains rejected 
based on the domains DMARC policy  by my mailer.

Based on the data in my rspam log and the sendersupport site showing ~1 mail 
having been marked as spam by a user, I _suspect_ that this is the forward 
feature; However, this feature seems to break DKIM signatures and re-signs with 
hotmail.com, leading to the DMARC policy reject triggering, as neither SPF nor 
DKIM match;

Is there any good way to get into contact with them about this (as this is not 
really me having issues sending to them, but them to me ;-))/is anyone from MS 
reading on this list?

With best regards,
Tobias

 rspamd.log:2022-04-30 10:54:14 #27730(normal) <1736ea>; task; 
rspamd_task_write_log: id: <267a1c47b4bb64e17ab1633ea69b5...@engelsystem.de>, 
qid: , ip: 40.92.58.32, from: , (default: T 
(reject): [10.00/10.00] 
[NEURAL_HAM(-2.97){-0.991;},DMARC_POLICY_REJECT(2.00){engelsystem.de : SPF not 
aligned (relaxed), DKIM not aligned 
(relaxed);reject;},FORGED_RECIPIENTS(2.00){m:@outlook.de;s:postmas...@aperture-labs.org;},ARC_ALLOW(-1.00){microsoft.com:s=arcselector9901:i=1;},DATE_IN_PAST(1.00){38;},FORGED_SENDER(0.30){noreply-hamburg-hi...@engelsystem.de;st...@hotmail.com;},R_DKIM_ALLOW(-0.20){hotmail.com:s=selector1;},R_SPF_ALLOW(-0.20){+ip4:40.92.0.0/15;},MIME_GOOD(-0.10){text/plain;},MX_GOOD(-0.01){},BAYES_SPAM(0.00){39.71%;},ARC_SIGNED(0.00){aperture-labs.org:s=key01:i=2;},ASN(0.00){asn:8075,
 ipnet:40.80.0.0/12, 
country:US;},DKIM_MIXED(0.00){},DKIM_TRACE(0.00){hotmail.com:+;engelsystem.de:-;},DWL_DNSWL_NONE(0.00){hotmail.com:dkim;},FREEMAIL_ENVFROM(0.00){hotmail.com;},FREEMAIL_TO(0.00){outlook.de;},FROM_HAS_DN(0.00){},FROM_NEQ_ENVFROM(0.00){noreply-hamburg-hi...@engelsystem.de;st...@hotmail.com;},MID_RHS_MATCH_FROM(0.00){},MIME_TRACE(0.00){0:+;},RCPT_COUNT_ONE(0.00){1;},RCVD_COUNT_SEVEN(0.00){11;},RCVD_TLS_LAST(0.00){},RCVD_VIA_SMTP_AUTH(0.00){},R_DKIM_REJECT(0.00){engelsystem.de:s=es;},TO_DN_NONE(0.00){}]),
 len: 9927, time: 1357.5940132141113ms, dns req: 61, digest: 
<197fd69596e5326847617462eb097561>, rcpts: , 
mime_rcpts: <@outlook.de>, forced: reject "Action set by DMARC"; 
score=nan (set by dmarc)

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] What do these Gmail headers do?

[Brandon Long via mailop]

They're internal state passing and encrypted data.

iirc smtp-source is used for internal delivery latency metrics, and the
other is more esoteric.

Brandon

On Fri, Apr 29, 2022 at 5:53 PM Al Iverson via mailop 
wrote:

> Anybody familiar with the Gmail headers X-Gm-Message-State and
> X-Google-Smtp-Source? A coworker asked about them, but I am not really
> familiar. Figured I'd see here if anybody knows anything about them.
> Thanks in advance for your thoughts or feedback!
>
> Cheers,
> Al
>
> --
>
> Al Iverson / Deliverability blogging at www.spamresource.com
> Subscribe to the weekly newsletter at wombatmail.com/sr.cgi
> DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time)
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Understanding specific issue with from header field in google bounce reply

[Hans-Martin Mosner via mailop]

The base-64 encoding must only be done on the "comment" part of the From 
address, not on the "" part.


Cheers,
Hans-Martin

Am 2. Mai 2022 09:14:09 schrieb Alexander Neilson via mailop 
:

Hi Team

Please feel free to let me know this was not a suitable question for this 
list, apologies in advance if so.


At $dayjob one of my fairly new staff forwarded me a bounce message from 
gmail for an outbound email we were sending to a supplier.


Headers are down at the end of the email but the bounce message was:
554
5.0.0 

A test email sent from the same system to my own emails (hosted by gmail) 
didn't receive a bounce back so I am of the feeling there must be a From: 
header being included correctly in the message. So trying to investigate 
the header as to why it may not be a valid address and I was hoping for 
some assistance / guidance as to if I am interpreting the RFC correctly as 
to validity or am I barking up the wrong tree entirely.


The user whose email bounced has a last name with an accented character 
which is not a valid ASCII printable character and if I am reading RFC 6854 
S2.1 and RFC 5322 S2.2 correctly the header field must contain printable 
ASCII code points (and a couple of allowed other characters in the header 
field body.


I did note that the from header in the bounced email was shown as:
=?utf-8?b?IkZlcm5hbmRvIFNhbnRvcyBEZSBTw6EiIDxmZXJuYW5kby5zQGdsLmNvLm56?=
=?utf-8?b?Pg==?=
Converting this from Base64 encoded UTF-8 into plain UTF-8 I see the string:
"Fernando Santos De Sá" 
Which is correct for my user (however obviously not ASCII.

A few questions
Have I correctly identified the issue (or most likely issue) triggering 
this message from gmail?
Is there a good document for guidance on catching invalid values (including 
UTF-8 strings) and how they should be handled for headers in email (I see 
in RFC 5322 S3.2.4 there is an allowance for quoted strings that allow 
characters that are other than allowed in atoms but I guess if that was 
valid for what I was generating above the email wouldn't have bounced - 
possibly an issue because the whole string was Base64 encoded?) so I can 
look to catch situations that are problematic in future and provide a 
generalized system?
Does anyone have any guidance on other situations they have hit with email 
systems rejecting what is often accepted so I can try to generally test for 
known "fun interactions" and handle them?


(noting these emails are generated out of our in house developed operations 
management system so its my code that did the wrong thing originally here 
and what I need to get fixed)


Thank you for your time.

Headers from the bounce:

Notes:
email system isn't currently depositing emails into the sent box so user 
receives CC of emails sent on their behalf so they see what has gone out
antispamcloud is our spam filter provider who scans all inbound and 
outbound emails but error message was generated by gmail when trying to 
hand off the email. Providers web portal for checking message status 
decoded source email address and name string.


Original
message headers:
Return-Path: 
Received: from gl-ex02.gl.co.nz ([45.118.188.115])
   by mx262.antispamcloud.com with esmtps 
   (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128)

   (Exim 4.92)
   (envelope-from )
   id 1nlMq1-000A9Y-Mo
   for ; Mon, 02 May 2022 05:35:15 +0200
Received: from GL-EX02.internal.gl.co.nz (192.168.33.22) by
GL-EX02.internal.gl.co.nz (192.168.33.22) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.2.1118.7; Mon, 2 May 2022 15:35:02 +1200
Received: from gl-be04.internal.gl.co.nz (192.168.33.37) by
GL-EX02.internal.gl.co.nz (192.168.33.22) with Microsoft SMTP Server id
15.2.1118.7 via Frontend Transport; Mon, 2 May 2022 15:35:02 +1200
Content-Type: text/plain
MIME-Version: 1.0
From: =?utf-8?b?IkZlcm5hbmRvIFNhbnRvcyBEZSBTw6EiIDxmZXJuYW5kby5zQGdsLmNvLm56?=
=?utf-8?b?Pg==?=
To: 
CC: 
Subject: Global Jobsheet  - Fixing
Message-ID: <0368d464-ce75-4993-893a-6861eaebc...@gl-ex02.internal.gl.co.nz>
Date: Mon, 2 May 2022 15:35:02 +1200
X-Originating-IP: 45.118.188.115
X-MailAssure-Domain: gl.co.nz
X-MailAssure-Username: 45.118.188.115
Authentication-Results: antispamcloud.com; auth=pass 
smtp.auth=45.118.188@gl.co.nz

X-MailAssure-Outgoing-Class: ham
X-MailAssure-Outgoing-Evidence: Combined (0.09)
X-Recommended-Action: accept
X-Filter-ID: 
Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT/SWj98WPq4CtCgxem7mj3kPUtbdvnXkggZ

3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yFJoHAUTOjf1aFNKd7CnV+O+QzD67WU21zwtdtt9m3QQ/C
h5SE4jAyhe1COeASyU/5LRRHPJulhFeIJoq48nHN5WCy5VkstzhnxgTXqsdmp0LoMm7rojSS/Sxh
qDMvUmM1LQhYNBd1FP7U4OZT407FpuGXed8VjoeeEKguXydrkSH+3gVyyqW6++HqPXPhE0NcYe4a
MjKFhzJKmH0BGgJrQLk01CIbYZxgOAvibIM/Z6W7d1t4HzZ7ipKhj9PWSiyZOZh/196Uh/xDSW9g
kA3LEWgKIJ7Ay0RVJqlA03GHx5mIvc52cbna8kydvLENQgQtChAJ8MhPXbXvhZAyklffRAwX31WV
Y5lWjWxuGSRuxRfiiXKDnS3cS+VcIvEFMphhKzy27dJ+eI97x1+KvbnG5YE5enyccp7RH4WQio3u
Ga0qZK6eP2yJPYHuIR7M

Re: [mailop] Understanding specific issue with from header field in google bounce reply

[Paul Smith via mailop]

Read section five of RFC 2047 which explains where MIME encoded words can 
be used


https://datatracker.ietf.org/doc/html/rfc2047#section-5

They cannot be used in addr-specs, which is where you're using them

On 2 May 2022 09:07:22 Alexander Neilson via mailop  wrote:

Hi Team

Please feel free to let me know this was not a suitable question for this 
list, apologies in advance if so.


At $dayjob one of my fairly new staff forwarded me a bounce message from 
gmail for an outbound email we were sending to a supplier.


Headers are down at the end of the email but the bounce message was:
554
5.0.0 

A test email sent from the same system to my own emails (hosted by gmail) 
didn't receive a bounce back so I am of the feeling there must be a From: 
header being included correctly in the message. So trying to investigate 
the header as to why it may not be a valid address and I was hoping for 
some assistance / guidance as to if I am interpreting the RFC correctly as 
to validity or am I barking up the wrong tree entirely.


The user whose email bounced has a last name with an accented character 
which is not a valid ASCII printable character and if I am reading RFC 6854 
S2.1 and RFC 5322 S2.2 correctly the header field must contain printable 
ASCII code points (and a couple of allowed other characters in the header 
field body.


I did note that the from header in the bounced email was shown as:
=?utf-8?b?IkZlcm5hbmRvIFNhbnRvcyBEZSBTw6EiIDxmZXJuYW5kby5zQGdsLmNvLm56?=
=?utf-8?b?Pg==?=
Converting this from Base64 encoded UTF-8 into plain UTF-8 I see the string:
"Fernando Santos De Sá" 
Which is correct for my user (however obviously not ASCII.

A few questions
Have I correctly identified the issue (or most likely issue) triggering 
this message from gmail?
Is there a good document for guidance on catching invalid values (including 
UTF-8 strings) and how they should be handled for headers in email (I see 
in RFC 5322 S3.2.4 there is an allowance for quoted strings that allow 
characters that are other than allowed in atoms but I guess if that was 
valid for what I was generating above the email wouldn't have bounced - 
possibly an issue because the whole string was Base64 encoded?) so I can 
look to catch situations that are problematic in future and provide a 
generalized system?
Does anyone have any guidance on other situations they have hit with email 
systems rejecting what is often accepted so I can try to generally test for 
known "fun interactions" and handle them?


(noting these emails are generated out of our in house developed operations 
management system so its my code that did the wrong thing originally here 
and what I need to get fixed)


Thank you for your time.

Headers from the bounce:

Notes:
email system isn't currently depositing emails into the sent box so user 
receives CC of emails sent on their behalf so they see what has gone out
antispamcloud is our spam filter provider who scans all inbound and 
outbound emails but error message was generated by gmail when trying to 
hand off the email. Providers web portal for checking message status 
decoded source email address and name string.


Original
message headers:
Return-Path: 
Received: from gl-ex02.gl.co.nz ([45.118.188.115])
   by mx262.antispamcloud.com with esmtps 
   (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128)

   (Exim 4.92)
   (envelope-from )
   id 1nlMq1-000A9Y-Mo
   for ; Mon, 02 May 2022 05:35:15 +0200
Received: from GL-EX02.internal.gl.co.nz (192.168.33.22) by
GL-EX02.internal.gl.co.nz (192.168.33.22) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.2.1118.7; Mon, 2 May 2022 15:35:02 +1200
Received: from gl-be04.internal.gl.co.nz (192.168.33.37) by
GL-EX02.internal.gl.co.nz (192.168.33.22) with Microsoft SMTP Server id
15.2.1118.7 via Frontend Transport; Mon, 2 May 2022 15:35:02 +1200
Content-Type: text/plain
MIME-Version: 1.0
From: =?utf-8?b?IkZlcm5hbmRvIFNhbnRvcyBEZSBTw6EiIDxmZXJuYW5kby5zQGdsLmNvLm56?=
=?utf-8?b?Pg==?=
To: 
CC: 
Subject: Global Jobsheet  - Fixing
Message-ID: <0368d464-ce75-4993-893a-6861eaebc...@gl-ex02.internal.gl.co.nz>
Date: Mon, 2 May 2022 15:35:02 +1200
X-Originating-IP: 45.118.188.115
X-MailAssure-Domain: gl.co.nz
X-MailAssure-Username: 45.118.188.115
Authentication-Results: antispamcloud.com; auth=pass 
smtp.auth=45.118.188@gl.co.nz

X-MailAssure-Outgoing-Class: ham
X-MailAssure-Outgoing-Evidence: Combined (0.09)
X-Recommended-Action: accept
X-Filter-ID: 
Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT/SWj98WPq4CtCgxem7mj3kPUtbdvnXkggZ

3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yFJoHAUTOjf1aFNKd7CnV+O+QzD67WU21zwtdtt9m3QQ/C
h5SE4jAyhe1COeASyU/5LRRHPJulhFeIJoq48nHN5WCy5VkstzhnxgTXqsdmp0LoMm7rojSS/Sxh
qDMvUmM1LQhYNBd1FP7U4OZT407FpuGXed8VjoeeEKguXydrkSH+3gVyyqW6++HqPXPhE0NcYe4a
MjKFhzJKmH0BGgJrQLk01CIbYZxgOAvibIM/Z6W7d1t4HzZ7ipKhj9PWSiyZOZh/196Uh/xDSW9g
kA3LEWgKIJ7Ay0RVJqlA03GHx5mIvc52cbna8kydvLENQgQtChAJ8MhPXbXvhZAyklffRAwX31WV
Y5lWjWxuGSRuxRfi

[mailop] Understanding specific issue with from header field in google bounce reply

[Alexander Neilson via mailop]

Hi Team

Please feel free to let me know this was not a suitable question for this
list, apologies in advance if so.

At $dayjob one of my fairly new staff forwarded me a bounce message from
gmail for an outbound email we were sending to a supplier.

Headers are down at the end of the email but the bounce message was:
554 5.0.0 

A test email sent from the same system to my own emails (hosted by gmail)
didn't receive a bounce back so I am of the feeling there must be a From:
header being included correctly in the message. So trying to investigate
the header as to why it may not be a valid address and I was hoping for
some assistance / guidance as to if I am interpreting the RFC correctly as
to validity or am I barking up the wrong tree entirely.

The user whose email bounced has a last name with an accented character
which is not a valid ASCII printable character and if I am reading RFC 6854
S2.1 and RFC 5322 S2.2 correctly the header field must contain printable
ASCII code points (and a couple of allowed other characters in the header
field body.

I did note that the from header in the bounced email was shown as:

=?utf-8?b?IkZlcm5hbmRvIFNhbnRvcyBEZSBTw6EiIDxmZXJuYW5kby5zQGdsLmNvLm56?=

=?utf-8?b?Pg==?=
Converting this from Base64 encoded UTF-8 into plain UTF-8 I see the string:
"Fernando Santos De Sá" 
Which is correct for my user (however obviously not ASCII.

A few questions
Have I correctly identified the issue (or most likely issue) triggering
this message from gmail?
Is there a good document for guidance on catching invalid values (including
UTF-8 strings) and how they should be handled for headers in email (I see
in RFC 5322 S3.2.4 there is an allowance for quoted strings that allow
characters that are other than allowed in atoms but I guess if that was
valid for what I was generating above the email wouldn't have bounced -
possibly an issue because the whole string was Base64 encoded?) so I can
look to catch situations that are problematic in future and provide a
generalized system?
Does anyone have any guidance on other situations they have hit with email
systems rejecting what is often accepted so I can try to generally test for
known "fun interactions" and handle them?

(noting these emails are generated out of our in house developed operations
management system so its my code that did the wrong thing originally here
and what I need to get fixed)

Thank you for your time.

Headers from the bounce:

Notes:
email system isn't currently depositing emails into the sent box so user
receives CC of emails sent on their behalf so they see what has gone out
antispamcloud is our spam filter provider who scans all inbound and
outbound emails but error message was generated by gmail when trying to
hand off the email. Providers web portal for checking message status
decoded source email address and name string.

Original message headers:

Return-Path: 

Received: from gl-ex02.gl.co.nz ([45.118.188.115])

by mx262.antispamcloud.com with esmtps
(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128)

(Exim 4.92)

(envelope-from )

id 1nlMq1-000A9Y-Mo

for ; Mon, 02 May 2022 05:35:15 +0200

Received: from GL-EX02.internal.gl.co.nz (192.168.33.22) by

 GL-EX02.internal.gl.co.nz (192.168.33.22) with Microsoft SMTP Server

 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id

 15.2.1118.7; Mon, 2 May 2022 15:35:02 +1200

Received: from gl-be04.internal.gl.co.nz (192.168.33.37) by

 GL-EX02.internal.gl.co.nz (192.168.33.22) with Microsoft SMTP Server id

 15.2.1118.7 via Frontend Transport; Mon, 2 May 2022 15:35:02 +1200

Content-Type: text/plain

MIME-Version: 1.0

From: =?utf-8?b?IkZlcm5hbmRvIFNhbnRvcyBEZSBTw6EiIDxmZXJuYW5kby5zQGdsLmNvLm56?=

 =?utf-8?b?Pg==?=

To: 

CC: 

Subject: Global Jobsheet  - Fixing

Message-ID: <0368d464-ce75-4993-893a-6861eaebc...@gl-ex02.internal.gl.co.nz>

Date: Mon, 2 May 2022 15:35:02 +1200

X-Originating-IP: 45.118.188.115

X-MailAssure-Domain: gl.co.nz

X-MailAssure-Username: 45.118.188.115

Authentication-Results: antispamcloud.com; auth=pass
smtp.auth=45.118.188@gl.co.nz

X-MailAssure-Outgoing-Class: ham

X-MailAssure-Outgoing-Evidence: Combined (0.09)

X-Recommended-Action: accept

X-Filter-ID: 
Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT/SWj98WPq4CtCgxem7mj3kPUtbdvnXkggZ

 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yFJoHAUTOjf1aFNKd7CnV+O+QzD67WU21zwtdtt9m3QQ/C

 h5SE4jAyhe1COeASyU/5LRRHPJulhFeIJoq48nHN5WCy5VkstzhnxgTXqsdmp0LoMm7rojSS/Sxh

 qDMvUmM1LQhYNBd1FP7U4OZT407FpuGXed8VjoeeEKguXydrkSH+3gVyyqW6++HqPXPhE0NcYe4a

 MjKFhzJKmH0BGgJrQLk01CIbYZxgOAvibIM/Z6W7d1t4HzZ7ipKhj9PWSiyZOZh/196Uh/xDSW9g

 kA3LEWgKIJ7Ay0RVJqlA03GHx5mIvc52cbna8kydvLENQgQtChAJ8MhPXbXvhZAyklffRAwX31WV

 Y5lWjWxuGSRuxRfiiXKDnS3cS+VcIvEFMphhKzy27dJ+eI97x1+KvbnG5YE5enyccp7RH4WQio3u

 Ga0qZK6eP2yJPYHuIR7M4/shEWyJzIkwSFAW0Pw8uiKeltK+MtP+Q+MOaQQT+Vn8BIlSPGIn6LIh

 6vfZt6Tuc+uVfVL7ygxIxIEhQBgsu7ia6J1fhOzjF0b4LXcjJZ5loquXN5jFSCbczMwQYmA5Fgmk

 3lS1t6QdEPz08qMKOQH7dKFTuGZxy4YnIveHBkunQ