<div dir="ltr"><div>Thanks, that was what I thought.  The examples I'm seeing do not include TAB characters after the break in the file name.  They all start with a LF control character, then a series of space characters (0x20), then the rest of the file name.  The amount of spaces seems to be variable.  I'm finding some that go above 20, some that are around 10... I can't discern a pattern, and I can't fully prove that this is Yahoo that is doing it, though it would seem odd to have that many senders doing the same thing on their own in this way.  I don't think this is a MailScanner issue, just that a rule in MailScanner is potentially exposing RFC breaking behavior.</div><div><br></div><div>I do see another commonality, and that is the X-Mailer header containing the following information (or similar):</div><div><br></div><div>X-Mailer: WebService/1.1.17501 YahooMailIosMobile Yahoo%20Mail/52372 CFNetwork/1209 Darwin/20.2.0</div><div><br></div><div>Every single example that I've seen so far indicates that these are being sent potentially from the same type of email client (with some variations on version strings, etc.).  If I have time I'll see if there are any non @<a href="http://yahoo.com">yahoo.com</a> examples that might indicate a commonality (iOS/macOS, etc.).</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 19, 2021 at 5:48 PM Mark Sapiro <<a href="mailto:mark@msapiro.net">mark@msapiro.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 1/19/21 1:58 PM, Ricky Boone wrote:<br>
> Hello everyone,<br>
> <br>
> I was seeing a disproportionate number of messages from legitimate<br>
> @<a href="http://yahoo.com" rel="noreferrer" target="_blank">yahoo.com</a> <<a href="http://yahoo.com" rel="noreferrer" target="_blank">http://yahoo.com</a>> senders hitting our environment that, when<br>
> they have an attachment with a long name with spaces, they hit the<br>
> "Filename contains lots of white space" rule in filename.rules.conf. <br>
> Upon deeper inspection, it appears it may be something with Yahoo and<br>
> how they handle spaces when generating the Content-Disposition header in<br>
> the message.  In most cases, when the file name went past a certain<br>
> number of characters, it was wrapped to the next line, but with 5-10<br>
> blank characters padded to it.<br>
<br>
<br>
See <<a href="https://www.rfc-editor.org/rfc/rfc5322.html#section-2.2.3" rel="noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc5322.html#section-2.2.3</a>><br>
<br>
Note that the filename= parameter in a Content-Disposition is a<br>
structured field and should not be folded - try telling Yahoo that.<br>
<br>
Are you saying that Yahoo is folding by inserting more than just a CRLF,<br>
i.e. a CRLF and a TAB or multiple spaces. In that case, Yahoo is again<br>
non-conformant.<br>
<br>
However, none of that is helpful to you. There may be a MailScanner<br>
issue if Yahoo is folding by inserting CRLF TAB and MailScanner is<br>
considering the TAB to be multiple spaces. Is that the case?<br>
<br>
-- <br>
Mark Sapiro <<a href="mailto:mark@msapiro.net" target="_blank">mark@msapiro.net</a>>        The highway is for gamblers,<br>
San Francisco Bay Area, California    better use your sense - B. Dylan<br>
<br>
<br>
-- <br>
MailScanner mailing list<br>
<a href="mailto:mailscanner@lists.mailscanner.info" target="_blank">mailscanner@lists.mailscanner.info</a><br>
<a href="http://lists.mailscanner.info/mailman/listinfo/mailscanner" rel="noreferrer" target="_blank">http://lists.mailscanner.info/mailman/listinfo/mailscanner</a><br>
<br>
</blockquote></div>