Suggestion
Hi, Where can I make a suggestion? Regards, Marius.
Re: Suggestion
On Mon, 2 Jun 2014 11:38:27 +0300 "Marius Gologan" wrote: > Where can I make a suggestion? > What kind suggestion? You can post here..
RE: Suggestion
It might be an workaround for some firewalls blocking Postfix SMTP client: Here is the case I worked out: Problem - Postfix (SMTP Client) receives 500 5.3.3 Unrecognized command from the SMTP Server. Of course both Postfix and Exchange (in this example) know smtp commands. Cause: - A firewall in the middle is altering SMTP syntax. Workaround: - Replacing the hard error with a soft error (400 in smtp_reply_filter) causes Postfix SMTP client to retry and deliver the messages. I did not debug the second retry and see if Postfix client is sending the message in a different way - possible it does. Suggestion: - In other words, with the smtp_reply_filter listed below, the delivery chances are significantly increased and might be a good idea to implement a smtp_(cisco?)_workaround_(harderror?) = yes/no. Here is my smtp_reply_filter (first in line works in real case, the others are assumptions) /^500 5\.3\.3 Unrecogni[zs]ed command/ 400 4.3.3 Message not accepted by Exchange. Retrying later /^500 unrecogni[zs]ed command/ 400 Message not accepted by Exim. Retrying later /^502 5\.5\.2 Error: command not recognized/ 402 5.5.2 Message not accepted by Postfix. Retrying later /^500 Syntax error/ 400 Message not accepted by Lotus. Retrying later Marius. -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Wijatmoko U. Prayitno Sent: Monday, June 2, 2014 12:00 PM To: postfix-users@postfix.org Subject: Re: Suggestion On Mon, 2 Jun 2014 11:38:27 +0300 "Marius Gologan" wrote: > Where can I make a suggestion? > What kind suggestion? You can post here..
Re: smtp sending priorities depending on client IP address?
Hi, On 05/29/2014 04:24 PM, Viktor Dukhovni wrote: On Thu, May 29, 2014 at 01:35:45PM +0200, ?? ??? wrote: [snip] Are there any good ways to configure my postfix to only slow down the traffic originating from my newsletter host? A separate Postfix instance for the newsletter delivery is the best approach. Queue controls are by destination. Thanks for the advice. I found a very useful document about this topic here: http://www.postfix.org/MULTI_INSTANCE_README.html One thing I fail to understand is how I with multiple postfix instances can determine which queue is used for newsletter and for all the rest. Do I have to configure multiple IP addresses - one for each postfix instance? TIA, Mikael
Re: smtpd_sasl_path
> st...@thornet.co.uk: >> > Real evidence would be in the form of strace (or equivalent) >> output >> > that shows Postfix uses an AF_UNIX (AF_LOCAL) socket. >> > We found an RPM of Ver 2.6 and updated. All working as expected now. Thanks Wietse and Viktor for your prompt and helpful support. Steve
Re: smtp sending priorities depending on client IP address?
mikael.bak: > I found a very useful document about this topic here: > http://www.postfix.org/MULTI_INSTANCE_README.html > > One thing I fail to understand is how I with multiple postfix instances > can determine which queue is used for newsletter and for all the rest. > Do I have to configure multiple IP addresses - one for each postfix > instance? Each instance has its own mail queue and scheduler. If an instance needs to receive mail via SMTP, THEN it needs its own IP address or TCP port. To submit mail with the Postfix sendmail command: /usr/sbin/sendmail -C config-directory-of-alternate-instance ... Begin quote from Postfix sendmail manpage -C config_file -C config_dir The path name of the Postfix main.cf file, or of its parent directory. This information is ignored with Postfix versions before 2.3. With all Postfix versions, you can specify a directory pathname with the MAIL_CONFIG environment variable to override the loca- tion of configuration files. End quote from Postfix sendmail manpage Wietse
Re: Blocking executables. What did I miss?
On Mon 02/Jun/2014 05:46:04 +0200 Noel Jones wrote: On 6/1/2014 4:22 PM, Inteq Solution - Dep. Tehnic wrote: Using both my examples (mime_header_checks and header_checks), my executable (.bat) is blocked when I send a test email from Outlook with the correct REJECT text. But, when testing from emailsecuritycheck.net, I receive the .bat attachment. When header_checks (and mime_header_checks) don't work as expected, it's because the input doesn't match the pattern. The next step is to examine the message that passed and see exactly what it contains, and that will help you track down why it didn't match. Correct. Emailsecuritycheck don't just put filename=attached.bat, but more convolute stuff such as filename=attached.()bat, newlines as in filename=attached\ .bat and even a dubious: Content-Disposition: attachment; filename*0*="''attached%2E"; filename*1*="%62"; filename*2=at Ale
Re: Blocking executables. What did I miss?
On Mon, Jun 02, 2014 at 01:15:37PM +0200, Alessandro Vesely wrote: > and even a dubious: > > Content-Disposition: attachment; > filename*0*="''attached%2E"; > filename*1*="%62"; > filename*2=at That's not dubious, that's RFC 2231. The MIME normalizer I wrote some years back, (sorry not publically available) was able to recognize restricted file extensions even in this case. Sufficiently advanced MIME encodings require more than than a regular expression matcher to recognize. The attachment filtering in header_checks is a best-effort junk reduction technique, not a robust defense. -- Viktor.
Re: Blocking executables. What did I miss?
Viktor Dukhovni: > On Mon, Jun 02, 2014 at 01:15:37PM +0200, Alessandro Vesely wrote: > > > and even a dubious: > > > > Content-Disposition: attachment; > > filename*0*="''attached%2E"; > > filename*1*="%62"; > > filename*2=at > > That's not dubious, that's RFC 2231. The MIME normalizer I wrote > some years back, (sorry not publically available) was able to > recognize restricted file extensions even in this case. > > Sufficiently advanced MIME encodings require more than than a > regular expression matcher to recognize. The attachment filtering > in header_checks is a best-effort junk reduction technique, not a > robust defense. Postfix documentation states in more than one place that header/body_checks are not and will not be a deep content filter. If that is what you want, then use the right tool for the right job. Wietse
policy daemon failure
Hi We use sqlgrey as a policy daemon for greylisting. It runs on both our mail servers with a shared database on one of them. If the database is unavailable for some reason on the main server the backup rejects mail with "451 4.3.5 Server configuration problem" Is it possible to change the default to accept the mail if the policy daemon fails. Most of our users would prefer a bit of extra spam to losing genuine mail. Thanks steve
Re: policy daemon failure
Am 02.06.2014 17:11, schrieb st...@thornet.co.uk: > We use sqlgrey as a policy daemon for greylisting. It runs on both our mail > servers with a shared database on one > of them. If the database is unavailable for some reason on the main server > the backup rejects mail with "451 4.3.5 > Server configuration problem" Is it possible to change the default to accept > the mail if the policy daemon fails. > Most of our users would prefer a bit of extra spam to losing genuine mail. you *do not* lose anything 451 is a *temporary* error 5xx would be a complete reject please learn how email works
Re: policy daemon failure
On Mon, Jun 02, 2014 at 04:11:27PM +0100, st...@thornet.co.uk wrote: > We use sqlgrey as a policy daemon for greylisting. It runs on > both our mail servers with a shared database on one of them. If the > database is unavailable for some reason on the main server the backup > rejects mail with "451 4.3.5 Server configuration problem" Is it > possible to change the default to accept the mail if the policy daemon > fails. Most of our users would prefer a bit of extra spam to losing > genuine mail. The place to apply such logic is in the policy server itself. Postfix should not second-guess the policy server verdict. As noted by others 4XX is not a permanent error, the sending system should retry the delivery. -- Viktor.
Re: policy daemon failure
> > you *do not* lose anything > > 451 is a *temporary* error > 5xx would be a complete reject > Yes, but many mails rejected in an incident this morning haven't been resent. I guess we're dealing with broken clients. Steve
Re: policy daemon failure
Am 02.06.2014 18:05, schrieb st...@thornet.co.uk: >> >> you *do not* lose anything >> >> 451 is a *temporary* error >> 5xx would be a complete reject >> > > Yes, but many mails rejected in an incident this morning haven't been > resent. I guess we're dealing with broken clients. perhaps, but this is not "your" problem, the sender has to fix it, some more workaround may use greylist more selective like perhaps read https://sys4.de/de/blog/2013/10/09/selektive-rbl-spf-greylisting-checks-mit-smtpd_restriction_classes/ sorry german, but setup should speak for its own > > Steve > Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
RE: Blocking executables. What did I miss?
Thank you Wietse, Viktor, Learned something new today. Even though I read the documentation regarding content filtering, it seems I missed that part. Will look for a complementary solution. All the best Razvan -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Wietse Venema Sent: Monday, June 02, 2014 4:34 PM To: postfix-users@postfix.org Subject: Re: Blocking executables. What did I miss? Viktor Dukhovni: > On Mon, Jun 02, 2014 at 01:15:37PM +0200, Alessandro Vesely wrote: > > > and even a dubious: > > > > Content-Disposition: attachment; > > filename*0*="''attached%2E"; > > filename*1*="%62"; > > filename*2=at > > That's not dubious, that's RFC 2231. The MIME normalizer I wrote some > years back, (sorry not publically available) was able to recognize > restricted file extensions even in this case. > > Sufficiently advanced MIME encodings require more than than a regular > expression matcher to recognize. The attachment filtering in > header_checks is a best-effort junk reduction technique, not a robust > defense. Postfix documentation states in more than one place that header/body_checks are not and will not be a deep content filter. If that is what you want, then use the right tool for the right job. Wietse
Re: Blocking executables. What did I miss?
> Thank you Wietse, Viktor, > > Learned something new today. > Even though I read the documentation regarding content filtering, it seems I > missed that part. > Will look for a complementary solution. http://www.postfix.org/CONTENT_INSPECTION_README.html before queue, built-in, light-weight This method inspects mail BEFORE it is stored in the queue, and uses Postfix's built-in message header and message body inspection. Although the main purpose is to stop a specific flood of mail from worms or viruses, it is also useful to block a flood of bounced junk email and email notifications from virus detection systems. The built-in regular expressions are not meant to implement general SPAM and virus detection. For that, you should use one of the content inspection methods described below. Details are described in the BUILTIN_FILTER_README and BACKSCATTER_README documents. http://www.postfix.org/BUILTIN_FILTER_README.html Limitations of Postfix header/body checks Header/body checks do not decode message headers or message body content. For example, if text in the message body is BASE64 encoded (RFC 2045) then your regular expressions will have to match the BASE64 encoded form. Likewise, message headers with encoded non-ASCII characters (RFC 2047) need to be matched in their encoded form. Header/body checks cannot filter on a combination of message headers or body lines. Header/body checks examine content one message header at a time, or one message body line at a time, and cannot carry a decision over to the next message header or body line. Header/body checks cannot depend on the recipient of a message. One message can have multiple recipients, and all recipients of a message receive the same treatment. Workarounds have been proposed that involve selectively deferring some recipients of multi-recipient mail, but that results in poor SMTP performance and does not work for non-SMTP mail. Some sources of mail send the headers and content ahead of the recipient information. It would be inefficient to buffer up an entire message before deciding if it needs to be filtered, and it would be clumsy to filter mail and to buffer up all the actions until it is known whether those actions need to be executed. Despite warnings, some people try to use the built-in filter feature for general junk email and/or virus blocking, using hundreds or even thousands of regular expressions. This can result in catastrophic performance failure. The symptoms are as follows: The cleanup(8) processes use up all available CPU time in order to process the regular expressions, and/or they use up all available memory so that the system begins to swap. This slows down all incoming mail deliveries. As Postfix needs more and more time to receive an email message, the number of simultaneous SMTP sessions increases to the point that the SMTP server process limit is reached. While all SMTP server processes are waiting for the cleanup(8) servers to finish, new SMTP clients have to wait until an SMTP server process becomes available. This causes mail deliveries to time out before they have even begun. The remedy for this type of performance problem is simple: don't use header/body checks for general junk email and/or virus blocking, and don't filter mail before it is queued. When performance is a concern, use an external content filter that runs after mail is queued, as described in the FILTER_README document. Wietse
