Re: header_checks and regexes

2022-03-02 Thread Viktor Dukhovni
On Wed, Mar 02, 2022 at 08:57:51PM -0500, Alex wrote:

> Content-Type: text/html; charset="US-ASCII"; name="download.html"
> Content-Disposition: attachment; filename="download.html"
> 
> And this is the regex I currently have. Hopefully it wraps properly.

> /^Content-(Disposition|Type):\s+.+?(?:file)?name="?.+?\(386|exe|ad[ept]|app|as[dpx]|ba[st]|bin|btm|cab|cb[lt]|cgi|chm|cil|cla(ss)?|cmd|cp[el]|crt|cs[chs]|cvp|dll|dot|drv|em(ai)?l|ex[_e]|fon|fxp|hlp|ht[ar]|in[fips]|html|isp|jar|jse?|keyreg|ksh|lib|lnk|md[abetw]|mht(m|ml)?|mp3|ms[ciopt]|nte|nws|obj|ocx|ops|ov.|pcd|pgm|pif|p[lm]|pot|pps|prg|reg|sc[rt]|sh[bs]?|slb|smm|sw[ft]|sys|url|vb[esx]?|vir|vmx|vxd|wm[dsz]|ws[cfh]|xlw|xms|\{[\da-f]{8}(?:-[\da-f]{4}){3}-[\da-f]{12}\})\b/
>  REJECT ".$2" file attachment types not allowed

The above regular expression is malformed,  instead of:

/...name="?.+?\(386|.../

it should be:

/...name="?.+?(386|.../

It works as expected without the extaneous "\".

-- 
Viktor.


header_checks and regexes

2022-03-02 Thread Alex
Hi,
Many years ago I picked up a regex pattern that would reject different
attachment types, but it no longer seems to match properly. Perhaps
someone here can help me with the regex so I don't inadvertently start
rejecting mail that I shouldn't?

This is what the string that I'd like to reject looks like now:

--17a7a105d9467429
Content-Type: text/html; charset="US-ASCII"; name="download.html"
Content-Disposition: attachment; filename="download.html"
Content-Transfer-Encoding: base64
Content-ID: 
X-Attachment-Id: f_l0abi2410

TWFpbGd1biBNYWduaWZpY2VudCBBUEk=
--17a7a105d9467429--

And this is the regex I currently have. Hopefully it wraps properly.
/^Content-(Disposition|Type):\s+.+?(?:file)?name="?.+?\(386|exe|ad[ept]|app|as[dpx]|ba[st]|bin|btm|cab|cb[lt]|cgi|chm|cil|cla(ss)?|cmd|cp[el]|crt|cs[chs]|cvp|dll|dot|drv|em(ai)?l|ex[_e]|fon|fxp|hlp|ht[ar]|in[fips]|html|isp|jar|jse?|keyreg|ksh|lib|lnk|md[abetw]|mht(m|ml)?|mp3|ms[ciopt]|nte|nws|obj|ocx|ops|ov.|pcd|pgm|pif|p[lm]|pot|pps|prg|reg|sc[rt]|sh[bs]?|slb|smm|sw[ft]|sys|url|vb[esx]?|vir|vmx|vxd|wm[dsz]|ws[cfh]|xlw|xms|\{[\da-f]{8}(?:-[\da-f]{4}){3}-[\da-f]{12}\})\b/
   REJECT ".$2" file attachment types not allowed

Thanks so much,
Alex


Re: Tuning question for very large mail batches

2022-03-02 Thread Wietse Venema
Wietse Venema:
> Cooper, Robert A:
> > We use an external cloud service for emergency notifications and
> > are testing a new process to send out notification email - on the
> > order of 81,000+ addresses in just a few minutes.  What we ran
> > into is that the Proofpoint seemed to connect to one of the four
> > nodes for about 3 minutes - sending about 60 batches of addresses
> > through a single smtpd process.  Somewhere in that, the node started
> > telling Proofpoint to back off and deferred around 70,000 messages
> > from the overall batch; 
> 
> It would be good to investigate what reason Postfix gave. 

My expectation is that there is some configuration issue, or some
client-side violation of SMTP.

Without some detail of the reason given by Postfix, there is not
much we can do to bring a solution closer.

This would not be the first time that some mail generating app
violates protocol limits or requirements, such as:

- Sending too many RCPT TO commands per MAIL FROM command (the SMTP
standard says don't send more than 100, Postfix generously accepts
1000, other MTAs may have different limits).

- Not escaping '.' at the beginning of a line (that would be a
problem with all SMTP servers not just Postfix).

Or any other number of things some but not all of which Postfix can
be configured to tolerate.

Wietse