RE: [Non-DoD Source] Is there a CWE for this?

[Steven M Christey]

Rob,

I believe it makes sense to update CWE-436 based on your suggestion. An 
immediate question is whether the clarification belongs in the extended 
description or the modes of introduction, although “Specification” is not 
currently treated as a distinct SDLC phase within the XML schema 
(pre-implementation, we mostly have just Requirements and Design/Architecture, 
and it seems to me that “specifications” can be developed in many different 
phases). Currently, CWE-436’s modes of introduction list both Implementation 
and Architecture/Design without further explanation, so that could be further 
expanded upon.

- Steve


From: Rob Wissmann 
Sent: Tuesday, July 5, 2022 12:19 PM
To: Steven M Christey ; Seifried, Kurt ; 
jonathan.w.hood6@army.mil
Cc: CWE Research Discussion 
Subject: RE: [Non-DoD Source] Is there a CWE for this?

Steven,

Is there any room to update the description or extended description of CWE-436: 
Interpretation Conflict to suggest specs or requirements may be at fault for 
leaving certain behaviors up the implementation that should not be, leaving 
room for interpretation conflicts to occur and become vulnerabilities?

For example, the JSON spec is underspecified for certain error conditions, 
which leads to interoperability errors. 
https://bishopfox.com/blog/json-interoperability-vulnerabilities

Not sure if Kurt’s issue is an RFC issue but if the RFC doesn’t specify what a 
client should do when receiving a bad header field, it could be.

-Rob

From: Steven M Christey mailto:co...@mitre.org>>
Sent: Monday, July 4, 2022 7:50 PM
To: Seifried, Kurt mailto:k...@seifried.org>>; 
jonathan.w.hood6@army.mil<mailto:jonathan.w.hood6@army.mil>
Cc: CWE Research Discussion 
mailto:cwe-research-list@mitre.org>>
Subject: RE: [Non-DoD Source] Is there a CWE for this?

This is an interesting and simultaneously complicated question.

While the names and descriptions for CWE-140 through CWE-146 are not clear 
about the distinction, the mitigations are all about input, and their 
Class-level ancestor CWE-138: Improper Neutralization of Special Elements is 
input-focused: “The software receives input from an upstream component…” So, 
the intention of these CWEs was for input only.

As a side note, the names and descriptions for CWE-140 through CWE-146 should 
be modernized because of the possibility of misinterpretation, and the lack of 
emphasis on the intended behavior (also, was it really necessary to make 
variants for each type of “delimiter”? That PLOVER guy from 2006 has some 
explaining to do (for those who don’t get the joke, it was me)). These are 
early-day CWEs that reflected the focus on skilled vuln researchers, not 
developers.

In this case with the extra semicolon for includeSubdomains, deeper analysis is 
required. Kurt says that the semicolon is “not needed.” But is it technically 
allowed according to the spec (… and if so,  spec? HSTS? HTTP?) If a 
semicolon is technically allowed, then maybe there’s some kind of parsing error 
on the part of the client because it isn’t following the spec (CWE-684: 
Incorrect Provision of Specified Functionality )? But if both sides of this 
exchange are following some spec (with allowances for “undefined” behavior), 
then this could be regarded as CWE-436: Interpretation Conflict.

Parsing input and translating it to incorrect values is a gap in CWE that we’re 
aware of, but even if the issue is CWE-684 or some descendant of CWE-138, 
hopefully this will show that there are community-wide limitations in our 
language for classifying weaknesses that aren’t the “usual” basic issues like 
overflows and injection.

- Steve


From: Kurt Seifried mailto:k...@seifried.org>>
Sent: Sunday, July 3, 2022 3:47 PM
To: jonathan.w.hood6@army.mil<mailto:jonathan.w.hood6@army.mil>
Cc: CWE Research Discussion 
mailto:cwe-research-list@mitre.org>>
Subject: Re: [Non-DoD Source] Is there a CWE for this?

I would prefer to split them because you have two possibilities:

1) fix the output
2) be more tolerant of input and maybe (safely?) try to suss out what happens, 
e.g. is there an attack scenario for an attacker injecting headers with an 
extra ; that are then parses in an HSTS scenario? I can't think of one, so it 
should be safe, but I could be wrong.



On Sun, Jul 3, 2022 at 10:36 AM Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) 
mailto:jonathan.w.hood6@army.mil>> wrote:
I see what you’re saying about the CWE-14[0-6] family being pretty limited to 
input processing when the issue could exist because of input or malformed 
output. Perhaps changing these to input/output would be more inclusive of this 
type of issue. Good catch.

From: Kurt Seifried mailto:k...@seifried.org>>
Sent: Friday, July 1, 2022 8:37 PM
To: CWE-RESEARCH-LIST CWE RESEARCH DISCUSSION 
mailto:CWE-RESEARCH-LIST@mitre.org>>
Subject: [Non-DoD Source] Is there a CWE for this?

I ran across this today while auditin

Re: [Non-DoD Source] Is there a CWE for this?

[Kurt Seifried]

I would say it's a sliding scale with room for several CWE's:

at the "definite": end, someone implements the RFC incorrectly. I mean.
Yeah. the output should look like X, it doesn't, therefore it's wrong.

at the maybe middle: there are common behaviors/consensus, like Rob's JSON
example, which... well. "it depends". There are definitely more safe
behaviors than not (e.g. throw an error, refuse it, etc.), so in my mind,
as there is a solution, something actionable, then there is value in having
a CWE.

at the "we're not sure" end: there are things that are not
security/exploitable per se (at least not yet)... but they are concerning.
And again being aware of them is a lot safer than not being aware of them
at all. But I've seen all too many things go from "that's weird but never a
problem" to "that's a CWE top 25 now." So I would say the sooner it gets a
CWE, the better.



On Tue, Jul 5, 2022 at 10:19 AM Rob Wissmann 
wrote:

> Steven,
>
>
>
> Is there any room to update the description or extended description of
> CWE-436: Interpretation Conflict to suggest specs or requirements may be at
> fault for leaving certain behaviors up the implementation that should not
> be, leaving room for interpretation conflicts to occur and become
> vulnerabilities?
>
>
>
> For example, the JSON spec is underspecified for certain error conditions,
> which leads to interoperability errors.
> https://bishopfox.com/blog/json-interoperability-vulnerabilities
>
>
>
> Not sure if Kurt’s issue is an RFC issue but if the RFC doesn’t specify
> what a client should do when receiving a bad header field, it could be.
>
>
>
> -Rob
>
>
>
> *From:* Steven M Christey 
> *Sent:* Monday, July 4, 2022 7:50 PM
> *To:* Seifried, Kurt ; jonathan.w.hood6@army.mil
> *Cc:* CWE Research Discussion 
> *Subject:* RE: [Non-DoD Source] Is there a CWE for this?
>
>
>
> This is an interesting and simultaneously complicated question.
>
>
>
> While the names and descriptions for CWE-140 through CWE-146 are not clear
> about the distinction, the mitigations are all about input, and their
> Class-level ancestor CWE-138: Improper Neutralization of Special Elements
> is input-focused: “The software receives input from an upstream component…”
> So, the intention of these CWEs was for input only.
>
>
>
> As a side note, the names and descriptions for CWE-140 through CWE-146
> should be modernized because of the possibility of misinterpretation, and
> the lack of emphasis on the intended behavior (also, was it really
> necessary to make variants for each type of “delimiter”? That PLOVER guy
> from 2006 has some explaining to do (for those who don’t get the joke, it
> was me)). These are early-day CWEs that reflected the focus on skilled vuln
> researchers, not developers.
>
>
>
> In this case with the extra semicolon for includeSubdomains, deeper
> analysis is required. Kurt says that the semicolon is “not needed.” But is
> it technically allowed according to the spec (… and if so,  spec?
> HSTS? HTTP?) If a semicolon is technically allowed, then maybe there’s some
> kind of parsing error on the part of the client because it isn’t following
> the spec (CWE-684: Incorrect Provision of Specified Functionality )? But if
> both sides of this exchange are following some spec (with allowances for
> “undefined” behavior), then this could be regarded as CWE-436:
> Interpretation Conflict.
>
>
>
> Parsing input and translating it to incorrect values is a gap in CWE that
> we’re aware of, but even if the issue is CWE-684 or some descendant of
> CWE-138, hopefully this will show that there are community-wide limitations
> in our language for classifying weaknesses that aren’t the “usual” basic
> issues like overflows and injection.
>
>
>
> - Steve
>
>
>
>
>
> *From:* Kurt Seifried 
> *Sent:* Sunday, July 3, 2022 3:47 PM
> *To:* jonathan.w.hood6@army.mil
> *Cc:* CWE Research Discussion 
> *Subject:* Re: [Non-DoD Source] Is there a CWE for this?
>
>
>
> I would prefer to split them because you have two possibilities:
>
>
>
> 1) fix the output
>
> 2) be more tolerant of input and maybe (safely?) try to suss out what
> happens, e.g. is there an attack scenario for an attacker injecting headers
> with an extra ; that are then parses in an HSTS scenario? I can't think of
> one, so it should be safe, but I could be wrong.
>
>
>
>
>
>
>
> On Sun, Jul 3, 2022 at 10:36 AM Hood, Jonathan W CTR USARMY DEVCOM AVMC
> (USA)  wrote:
>
> I see what you’re saying about the CWE-14[0-6] family being pretty limited
> to input processing when the issue could exist because of input or
> mal

RE: [Non-DoD Source] Is there a CWE for this?

[Rob Wissmann]

Steven,

Is there any room to update the description or extended description of CWE-436: 
Interpretation Conflict to suggest specs or requirements may be at fault for 
leaving certain behaviors up the implementation that should not be, leaving 
room for interpretation conflicts to occur and become vulnerabilities?

For example, the JSON spec is underspecified for certain error conditions, 
which leads to interoperability errors. 
https://bishopfox.com/blog/json-interoperability-vulnerabilities

Not sure if Kurt’s issue is an RFC issue but if the RFC doesn’t specify what a 
client should do when receiving a bad header field, it could be.

-Rob

From: Steven M Christey 
Sent: Monday, July 4, 2022 7:50 PM
To: Seifried, Kurt ; jonathan.w.hood6@army.mil
Cc: CWE Research Discussion 
Subject: RE: [Non-DoD Source] Is there a CWE for this?

This is an interesting and simultaneously complicated question.

While the names and descriptions for CWE-140 through CWE-146 are not clear 
about the distinction, the mitigations are all about input, and their 
Class-level ancestor CWE-138: Improper Neutralization of Special Elements is 
input-focused: “The software receives input from an upstream component…” So, 
the intention of these CWEs was for input only.

As a side note, the names and descriptions for CWE-140 through CWE-146 should 
be modernized because of the possibility of misinterpretation, and the lack of 
emphasis on the intended behavior (also, was it really necessary to make 
variants for each type of “delimiter”? That PLOVER guy from 2006 has some 
explaining to do (for those who don’t get the joke, it was me)). These are 
early-day CWEs that reflected the focus on skilled vuln researchers, not 
developers.

In this case with the extra semicolon for includeSubdomains, deeper analysis is 
required. Kurt says that the semicolon is “not needed.” But is it technically 
allowed according to the spec (… and if so,  spec? HSTS? HTTP?) If a 
semicolon is technically allowed, then maybe there’s some kind of parsing error 
on the part of the client because it isn’t following the spec (CWE-684: 
Incorrect Provision of Specified Functionality )? But if both sides of this 
exchange are following some spec (with allowances for “undefined” behavior), 
then this could be regarded as CWE-436: Interpretation Conflict.

Parsing input and translating it to incorrect values is a gap in CWE that we’re 
aware of, but even if the issue is CWE-684 or some descendant of CWE-138, 
hopefully this will show that there are community-wide limitations in our 
language for classifying weaknesses that aren’t the “usual” basic issues like 
overflows and injection.

- Steve


From: Kurt Seifried mailto:k...@seifried.org>>
Sent: Sunday, July 3, 2022 3:47 PM
To: jonathan.w.hood6@army.mil<mailto:jonathan.w.hood6@army.mil>
Cc: CWE Research Discussion 
mailto:cwe-research-list@mitre.org>>
Subject: Re: [Non-DoD Source] Is there a CWE for this?

I would prefer to split them because you have two possibilities:

1) fix the output
2) be more tolerant of input and maybe (safely?) try to suss out what happens, 
e.g. is there an attack scenario for an attacker injecting headers with an 
extra ; that are then parses in an HSTS scenario? I can't think of one, so it 
should be safe, but I could be wrong.



On Sun, Jul 3, 2022 at 10:36 AM Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) 
mailto:jonathan.w.hood6@army.mil>> wrote:
I see what you’re saying about the CWE-14[0-6] family being pretty limited to 
input processing when the issue could exist because of input or malformed 
output. Perhaps changing these to input/output would be more inclusive of this 
type of issue. Good catch.

From: Kurt Seifried mailto:k...@seifried.org>>
Sent: Friday, July 1, 2022 8:37 PM
To: CWE-RESEARCH-LIST CWE RESEARCH DISCUSSION 
mailto:CWE-RESEARCH-LIST@mitre.org>>
Subject: [Non-DoD Source] Is there a CWE for this?

I ran across this today while auditing CSA services quarterly:

In bl.ink URL redirection service, as of 2022-07-01 an improperly formatted 
security header exists in the HSTS support, specifically, the header served is 
\"strict-transport-security: max-age=63072000; includeSubdomains;\" which 
contains an extra semicolon (the final one is not needed), this may result in 
some client ignoring the HSTS header and thus rendering this security 
protection ineffective.

there's some stuff for inbound/input/malformed/configuration/directive/etc, but 
I'm not seeing anything for malformed outbound configuration/output.

--
Kurt Seifried (He/Him)
k...@seifried.org<mailto:k...@seifried.org>


--
Kurt Seifried (He/Him)
k...@seifried.org<mailto:k...@seifried.org>

Re: [Non-DoD Source] Is there a CWE for this?

[Kurt Seifried]

On Mon, Jul 4, 2022 at 5:49 PM Steven M Christey  wrote:

> This is an interesting and simultaneously complicated question.
>
>
>
> While the names and descriptions for CWE-140 through CWE-146 are not clear
> about the distinction, the mitigations are all about input, and their
> Class-level ancestor CWE-138: Improper Neutralization of Special Elements
> is input-focused: “The software receives input from an upstream component…”
> So, the intention of these CWEs was for input only.
>
>
>
> As a side note, the names and descriptions for CWE-140 through CWE-146
> should be modernized because of the possibility of misinterpretation, and
> the lack of emphasis on the intended behavior (also, was it really
> necessary to make variants for each type of “delimiter”? That PLOVER guy
> from 2006 has some explaining to do (for those who don’t get the joke, it
> was me)). These are early-day CWEs that reflected the focus on skilled vuln
> researchers, not developers.
>
>
>
> In this case with the extra semicolon for includeSubdomains, deeper
> analysis is required. Kurt says that the semicolon is “not needed.” But is
> it technically allowed according to the spec (… and if so,  spec?
> HSTS? HTTP?) If a semicolon is technically allowed, then maybe there’s some
> kind of parsing error on the part of the client because it isn’t following
> the spec (CWE-684: Incorrect Provision of Specified Functionality )? But if
> both sides of this exchange are following some spec (with allowances for
> “undefined” behavior), then this could be regarded as CWE-436:
> Interpretation Conflict.
>
>
Nope, there's no ambiguity, those extra semicolons are out of spec:

https://datatracker.ietf.org/doc/html/rfc6797

6.1.  Strict-Transport-Security HTTP Response Header Field

   The Strict-Transport-Security HTTP response header field (STS header
   field) indicates to a UA that it MUST enforce the HSTS Policy in
   regards to the host emitting the response message containing this
   header field.

   The ABNF (Augmented Backus-Naur Form) syntax for the STS header field
   is given below.  It is based on the Generic Grammar defined in
   Section 2 of [RFC2616] (which includes a notion of "implied linear
   whitespace", also known as "implied *LWS").

 Strict-Transport-Security = "Strict-Transport-Security" ":"
 [ directive ]  *( ";" [ directive ] )

 directive = directive-name [ "=" directive-value ]
 directive-name= token
 directive-value   = token | quoted-string


==

6.2.  Examples

   The HSTS header field below stipulates that the HSTS Policy is to
   remain in effect for one year (there are approximately 31536000
   seconds in a year), and the policy applies only to the domain of the
   HSTS Host issuing it:

 Strict-Transport-Security: max-age=31536000

   The HSTS header field below stipulates that the HSTS Policy is to
   remain in effect for approximately six months and that the policy
   applies to the domain of the issuing HSTS Host and all of its
   subdomains:

 Strict-Transport-Security: max-age=15768000 ; includeSubDomains




> Parsing input and translating it to incorrect values is a gap in CWE that
> we’re aware of, but even if the issue is CWE-684 or some descendant of
> CWE-138, hopefully this will show that there are community-wide limitations
> in our language for classifying weaknesses that aren’t the “usual” basic
> issues like overflows and injection.
>
>
>
> - Steve
>
>
>
>
>
> *From:* Kurt Seifried 
> *Sent:* Sunday, July 3, 2022 3:47 PM
> *To:* jonathan.w.hood6@army.mil
> *Cc:* CWE Research Discussion 
> *Subject:* Re: [Non-DoD Source] Is there a CWE for this?
>
>
>
> I would prefer to split them because you have two possibilities:
>
>
>
> 1) fix the output
>
> 2) be more tolerant of input and maybe (safely?) try to suss out what
> happens, e.g. is there an attack scenario for an attacker injecting headers
> with an extra ; that are then parses in an HSTS scenario? I can't think of
> one, so it should be safe, but I could be wrong.
>
>
>
>
>
>
>
> On Sun, Jul 3, 2022 at 10:36 AM Hood, Jonathan W CTR USARMY DEVCOM AVMC
> (USA)  wrote:
>
> I see what you’re saying about the CWE-14[0-6] family being pretty limited
> to input processing when the issue could exist because of input or
> malformed output. Perhaps changing these to input/output would be more
> inclusive of this type of issue. Good catch.
>
>
>
> *From:* Kurt Seifried 
> *Sent:* Friday, July 1, 2022 8:37 PM
> *To:* CWE-RESEARCH-LIST CWE RESEARCH DISCUSSION <
> CWE-RESEARCH-LIST@mitre.org>
> *Subject:* [Non-DoD Source] Is there a 

RE: [Non-DoD Source] Is there a CWE for this?

[Steven M Christey]

This is an interesting and simultaneously complicated question.

While the names and descriptions for CWE-140 through CWE-146 are not clear 
about the distinction, the mitigations are all about input, and their 
Class-level ancestor CWE-138: Improper Neutralization of Special Elements is 
input-focused: “The software receives input from an upstream component…” So, 
the intention of these CWEs was for input only.

As a side note, the names and descriptions for CWE-140 through CWE-146 should 
be modernized because of the possibility of misinterpretation, and the lack of 
emphasis on the intended behavior (also, was it really necessary to make 
variants for each type of “delimiter”? That PLOVER guy from 2006 has some 
explaining to do (for those who don’t get the joke, it was me)). These are 
early-day CWEs that reflected the focus on skilled vuln researchers, not 
developers.

In this case with the extra semicolon for includeSubdomains, deeper analysis is 
required. Kurt says that the semicolon is “not needed.” But is it technically 
allowed according to the spec (… and if so,  spec? HSTS? HTTP?) If a 
semicolon is technically allowed, then maybe there’s some kind of parsing error 
on the part of the client because it isn’t following the spec (CWE-684: 
Incorrect Provision of Specified Functionality )? But if both sides of this 
exchange are following some spec (with allowances for “undefined” behavior), 
then this could be regarded as CWE-436: Interpretation Conflict.

Parsing input and translating it to incorrect values is a gap in CWE that we’re 
aware of, but even if the issue is CWE-684 or some descendant of CWE-138, 
hopefully this will show that there are community-wide limitations in our 
language for classifying weaknesses that aren’t the “usual” basic issues like 
overflows and injection.

- Steve


From: Kurt Seifried 
Sent: Sunday, July 3, 2022 3:47 PM
To: jonathan.w.hood6@army.mil
Cc: CWE Research Discussion 
Subject: Re: [Non-DoD Source] Is there a CWE for this?

I would prefer to split them because you have two possibilities:

1) fix the output
2) be more tolerant of input and maybe (safely?) try to suss out what happens, 
e.g. is there an attack scenario for an attacker injecting headers with an 
extra ; that are then parses in an HSTS scenario? I can't think of one, so it 
should be safe, but I could be wrong.



On Sun, Jul 3, 2022 at 10:36 AM Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) 
mailto:jonathan.w.hood6@army.mil>> wrote:
I see what you’re saying about the CWE-14[0-6] family being pretty limited to 
input processing when the issue could exist because of input or malformed 
output. Perhaps changing these to input/output would be more inclusive of this 
type of issue. Good catch.

From: Kurt Seifried mailto:k...@seifried.org>>
Sent: Friday, July 1, 2022 8:37 PM
To: CWE-RESEARCH-LIST CWE RESEARCH DISCUSSION 
mailto:CWE-RESEARCH-LIST@mitre.org>>
Subject: [Non-DoD Source] Is there a CWE for this?

I ran across this today while auditing CSA services quarterly:

In bl.ink URL redirection service, as of 2022-07-01 an improperly formatted 
security header exists in the HSTS support, specifically, the header served is 
\"strict-transport-security: max-age=63072000; includeSubdomains;\" which 
contains an extra semicolon (the final one is not needed), this may result in 
some client ignoring the HSTS header and thus rendering this security 
protection ineffective.

there's some stuff for inbound/input/malformed/configuration/directive/etc, but 
I'm not seeing anything for malformed outbound configuration/output.

--
Kurt Seifried (He/Him)
k...@seifried.org<mailto:k...@seifried.org>


--
Kurt Seifried (He/Him)
k...@seifried.org<mailto:k...@seifried.org>

Re: [Non-DoD Source] Is there a CWE for this?

[Kurt Seifried]

I would prefer to split them because you have two possibilities:

1) fix the output
2) be more tolerant of input and maybe (safely?) try to suss out what
happens, e.g. is there an attack scenario for an attacker injecting headers
with an extra ; that are then parses in an HSTS scenario? I can't think of
one, so it should be safe, but I could be wrong.



On Sun, Jul 3, 2022 at 10:36 AM Hood, Jonathan W CTR USARMY DEVCOM AVMC
(USA)  wrote:

> I see what you’re saying about the CWE-14[0-6] family being pretty limited
> to input processing when the issue could exist because of input or
> malformed output. Perhaps changing these to input/output would be more
> inclusive of this type of issue. Good catch.
>
>
>
> *From:* Kurt Seifried 
> *Sent:* Friday, July 1, 2022 8:37 PM
> *To:* CWE-RESEARCH-LIST CWE RESEARCH DISCUSSION <
> CWE-RESEARCH-LIST@mitre.org>
> *Subject:* [Non-DoD Source] Is there a CWE for this?
>
>
>
> I ran across this today while auditing CSA services quarterly:
>
>
>
> In bl.ink URL redirection service, as of 2022-07-01 an improperly
> formatted security header exists in the HSTS support, specifically, the
> header served is \"strict-transport-security: max-age=63072000;
> includeSubdomains;\" which contains an extra semicolon (the final one is
> not needed), this may result in some client ignoring the HSTS header and
> thus rendering this security protection ineffective.
>
>
>
> there's some stuff for
> inbound/input/malformed/configuration/directive/etc, but I'm not seeing
> anything for malformed outbound configuration/output.
>
>
>
> --
>
> Kurt Seifried (He/Him)
> k...@seifried.org
>


-- 
Kurt Seifried (He/Him)
k...@seifried.org

RE: [Non-DoD Source] Is there a CWE for this?

[Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA)]

I see what you’re saying about the CWE-14[0-6] family being pretty limited to 
input processing when the issue could exist because of input or malformed 
output. Perhaps changing these to input/output would be more inclusive of this 
type of issue. Good catch.

 

From: Kurt Seifried  
Sent: Friday, July 1, 2022 8:37 PM
To: CWE-RESEARCH-LIST CWE RESEARCH DISCUSSION 
Subject: [Non-DoD Source] Is there a CWE for this?

 

I ran across this today while auditing CSA services quarterly:

 

In bl.ink URL redirection service, as of 2022-07-01 an improperly formatted 
security header exists in the HSTS support, specifically, the header served is 
\"strict-transport-security: max-age=63072000; includeSubdomains;\" which 
contains an extra semicolon (the final one is not needed), this may result in 
some client ignoring the HSTS header and thus rendering this security 
protection ineffective.

 

there's some stuff for inbound/input/malformed/configuration/directive/etc, but 
I'm not seeing anything for malformed outbound configuration/output. 


 

-- 

Kurt Seifried (He/Him)
k...@seifried.org  



smime.p7s
Description: S/MIME cryptographic signature