Re: iOS Connection Problems
>Asai: > This problem has been very difficult to figure out, but before I > dive head first into debugging, I?m wondering if there have been > any known issues with iOS that have been addressed in later versions > of Postfix? Asai You might be better off figuring out what the failing sessions have in common. Are they failing in the TLS handshake? Are they failing in the TCP handshake? These are basic questions that you should be able to answer just by looking at logs. Wietse
Re: Tailored filter
On 11/7/2017 2:36 PM, Seb wrote: >> I can confirm that the example greylist.pl program and sample >> configuration work perfectly. > > This is very comforting. Would you mind telling me more? Did you try > it yourself, just following the instructions in > http://www.postfix.org/SMTPD_POLICY_README.html#client_config I followed the instructions and "it works for me"TM > >> Sometimes system security features such as SELinux or AppArmor can >> interfere with program access. If you have such features, turn >> them off for testing. > > I do not use these, but following this line of thought I remembered > that for configuring DKIM I added to main.cf the following line: > smtpd_milters = inet:localhost:12301 > Could it be that I need to add here the information about greylist.pl? Milters are a separate feature and controlled by their own configuration. The example config for greylist.pl shows all the necessary steps for adding a policy service. > On a related note, is it possible in smtpd_recipient_restrictions to > use the following two lines? > check_policy_service inet:127.0.0.1:10023, > check_policy_service unix:/home/seb/sandra/bin/fuck, > I mean, would the second one complement the first one (this is what > I hope) or would it interfer with it because they share the same > beginning? It's valid to have as many check_policy_service lines as needed, and they are executed in the order you specify. Execution stops when a policy service returns OK or REJECT. Other actions available are listed in the access(5) man page. -- Noel Jones
Re: Tailored filter
Hello, Just because I don't see your implementation error doesn't mean there isn't one. Fair point. I can confirm that the example greylist.pl program and sample configuration work perfectly. This is very comforting. Would you mind telling me more? Did you try it yourself, just following the instructions in http://www.postfix.org/SMTPD_POLICY_README.html#client_config ? Sometimes system security features such as SELinux or AppArmor can interfere with program access. If you have such features, turn them off for testing. I do not use these, but following this line of thought I remembered that for configuring DKIM I added to main.cf the following line: smtpd_milters = inet:localhost:12301 Could it be that I need to add here the information about greylist.pl? On a related note, is it possible in smtpd_recipient_restrictions to use the following two lines? check_policy_service inet:127.0.0.1:10023, check_policy_service unix:/home/seb/sandra/bin/fuck, I mean, would the second one complement the first one (this is what I hope) or would it interfer with it because they share the same beginning? Kind regards, Sébastien.
Re: Tailored filter
On 11/7/2017 1:53 PM, Seb wrote: > Well I just followed that path: reading carefully the documentation > and reproducing as closely as possible the examples given within, to > no avail. The documentation does mention sockets, even though its > examples don't use them. So either way you are right :-) Just because I don't see your implementation error doesn't mean there isn't one. I can confirm that the example greylist.pl program and sample configuration work perfectly. Sometimes system security features such as SELinux or AppArmor can interfere with program access. If you have such features, turn them off for testing. and of course I'm right. ;) -- Noel Jones
Re: Tailored filter
Hello, My first guess is http://www.postfix.org/DEBUG_README.html#no_chroot Sorry, wrong guess. Your test program is not a policy server. http://www.postfix.org/addon.html#policy I see. So the example given in the online documentation can't work, and the more complete, apparently self-sufficient example greylist.pl given in postfix' source code can't work either. That's disturbing :-) But okay, I had a look at Postgrey's source code and it does indeed communicate through a socket, a feature that is definitely missing from what I tried. I'll give it another go in a few weeks. The examples work just fine. More likely my explanation is flawed. Refer to the documentation and examples, which are correct. Well I just followed that path: reading carefully the documentation and reproducing as closely as possible the examples given within, to no avail. The documentation does mention sockets, even though its examples don't use them. So either way you are right :-) Sébastien.
Re: iOS Connection Problems
Have you checked the certificates of postfix (if SSL supported) and firewall rules of the server?Anvar Kuchkartaev an...@anvartay.com From: AsaiSent: martes, 7 de noviembre de 2017 07:28 p.m.To: postfix-users@postfix.orgSubject: iOS Connection ProblemsGreetings,We’re running Postfix 2.11.1 and have been having ongoing intermittent problems with iOS devices connecting to the SMTP service, or so it seems. Sometime, iOS devices don’t even seem to connect at all and they have to be restarted in order to connect. This is intermittent on some devices. Some devices don’t seem have any problems, one in particular has it constantly. E.g. we have a newer iPhone with the latest iOS and it’s constantly needing to be restarted in order to send mail. However, this issue has been seen on other iOS devices, but not as often.This problem has been very difficult to figure out, but before I dive head first into debugging, I’m wondering if there have been any known issues with iOS that have been addressed in later versions of Postfix? Asai
iOS Connection Problems
Greetings, We’re running Postfix 2.11.1 and have been having ongoing intermittent problems with iOS devices connecting to the SMTP service, or so it seems. Sometime, iOS devices don’t even seem to connect at all and they have to be restarted in order to connect. This is intermittent on some devices. Some devices don’t seem have any problems, one in particular has it constantly. E.g. we have a newer iPhone with the latest iOS and it’s constantly needing to be restarted in order to send mail. However, this issue has been seen on other iOS devices, but not as often. This problem has been very difficult to figure out, but before I dive head first into debugging, I’m wondering if there have been any known issues with iOS that have been addressed in later versions of Postfix? Asai
Re: Tailored filter
On 11/7/2017 10:55 AM, Seb wrote: > > Hello, > > My first guess is http://www.postfix.org/DEBUG_README.html#no_chroot >> Sorry, wrong guess. Your test program is not a policy server. >> You need something that listens on a unix or tcp socket. An >> incomplete list of available policy servers can be found here: >> http://www.postfix.org/addon.html#policy > > I see. So the example given in the online documentation can't work, > and the more complete, apparently self-sufficient example > greylist.pl given in postfix' source code can't work either. That's > disturbing :-) But okay, I had a look at Postgrey's source code and > it does indeed communicate through a socket, a feature that is > definitely missing from what I tried. I'll give it another go in a > few weeks. > > Thanks! > > > Sébastien. The examples work just fine. More likely my explanation is flawed. Refer to the documentation and examples, which are correct. -- Noel Jones
Re: Tailored filter
Hello, My first guess is http://www.postfix.org/DEBUG_README.html#no_chroot Sorry, wrong guess. Your test program is not a policy server. You need something that listens on a unix or tcp socket. An incomplete list of available policy servers can be found here: http://www.postfix.org/addon.html#policy I see. So the example given in the online documentation can't work, and the more complete, apparently self-sufficient example greylist.pl given in postfix' source code can't work either. That's disturbing :-) But okay, I had a look at Postgrey's source code and it does indeed communicate through a socket, a feature that is definitely missing from what I tried. I'll give it another go in a few weeks. Thanks! Sébastien.
Re: Tailored filter
On 11/7/2017 10:18 AM, Seb wrote: > > Hello, > > >> My first guess is >> http://www.postfix.org/DEBUG_README.html#no_chroot > Sorry, wrong guess. Your test program is not a policy server. You need something that listens on a unix or tcp socket. An incomplete list of available policy servers can be found here: http://www.postfix.org/addon.html#policy -- Noel Jones
Re: Tailored filter
Hello, My first guess is http://www.postfix.org/DEBUG_README.html#no_chroot So I went through /etc/postfix/master.cf and changed each line to make sure that nothing was left in a chroot: #egrep '^[a-z]' master.cf smtp inet n - n - - smtpd pickupfifo n - n 60 1 pickup cleanup unix n - n - 0 cleanup qmgr fifo n - n 300 1 qmgr tlsmgrunix - - n 1000? 1 tlsmgr rewrite unix - - n - - trivial-rewrite bounceunix - - n - 0 bounce defer unix - - n - 0 bounce trace unix - - n - 0 bounce verifyunix - - n - 1 verify flush unix n - n 1000? 0 flush proxymap unix - - n - - proxymap proxywrite unix - - n - 1 proxymap smtp unix - - n - - smtp relay unix - - n - - smtp showq unix n - n - - showq error unix - - n - - error retry unix - - n - - error discard unix - - n - - discard local unix - n n - - local virtual unix - n n - - virtual lmtp unix - - n - - lmtp anvil unix - - n - 1 anvil scacheunix - - n - 1 scache maildrop unix - n n - - pipe policyunix - n n - 0 spawn uucp unix - n n - - pipe ifmailunix - n n - - pipe bsmtp unix - n n - - pipe scalemail-backend unix - n n - 2 pipe mailman unix - n n - - pipe smtp-amavis unix- - n - 2 smtp and alas, the message remains in mail.log . It was a good call though. Any other idea? Sébastien. Noel Jones (Tue, 7 Nov 2017): On 11/7/2017 9:40 AM, Seb wrote: Hello, I run a small publishing company and for the sake of easing communication between authors (who work in teams) I have provided each of them with a local alias. Typically, mail sent to .@ is redirected to .@gmail.com, the usual email address of the author. You can use a postfix policy service such as postfwd to create a list of allowed senders for some particular recipient. This isn't difficult, but will require manual intervention anytime a change is needed. Postfwd may be kinda old, but is still widely used. http://postfwd.org/ (Reminder: my aim is to allow emails for our site's users only if the emails come from a certain dynamic list of addresses. It's a tool to Filter Unauthorized Communications with Keyholes, or in short, let's call it f.u.c.k.) I looked at the three solutions hinted at by Noel Jones. Postfwd was closest to my needs but it seemed more straightforward to use Postfix' SMTP Access Policy Delegation, which is mentioned in Postfwd's own documentation. To this end I closely followed the instructions provided by the documentation: http://www.postfix.org/SMTPD_POLICY_README.html#client_config In master.cf I added the lines # service type private unpriv chroot wakeup maxproc command + args policy unix - n n - 0 spawn user=nobody argv=/home/seb/sandra/bin/fuck (I tried writing this on 1 line or on 2 lines.) In main.cf I extended smtpd_recipient_restrictions to: smtpd_recipient_restrictions = reject_invalid_helo_hostname, [...] check_policy_service inet:127.0.0.1:10023, check_policy_service unix:/home/seb/sandra/bin/fuck, permit and, as the doc instructed, I also added: policy_time_limit = 3600 As for the Perl script that would decide whether an email should go through or not, for testing purposes I simply wrote: #!/usr/bin/perl print "action=dunno\n\n"; I then did a "chmod a+x" on /home/seb/sandra/bin/fuck and a "postfix reload"; my postfix version is 2.11 (Debian 8). This setup is as close to the documentation as I can make it. Yet I have missed something because /var/log/mail.log says: Nov 7 13:51:17 ns3358511 postfix/smtpd[14177]: warning: connect to /home/seb/sandra/bin/fuck: No such file or directory Nov 7 13:51:17 ns3358511 postfix/smtpd[14177]: warning: problem talking to server /home/seb/sandra/bin/fuck: No such file or directory although the file really exists: ~>ls -l /home/seb/sandra/bin/fuck -rwxr-xr-x 1 seb seb 2880 Nov 7 16:31 /home/seb/sandra/bin/fuck The problem could very well be
Re: Tailored filter
On 11/7/2017 9:40 AM, Seb wrote: > > Hello, > > >>> I run a small publishing company and for the sake of easing >>> communication between authors (who work in teams) I have provided >>> each of them with a local alias. Typically, mail sent to >>> .@ is redirected to >>> .@gmail.com, the usual email address of the >>> author. >> You can use a postfix policy service such as postfwd to create a >> list of allowed senders for some particular recipient. This isn't >> difficult, but will require manual intervention anytime a change >> is needed. Postfwd may be kinda old, but is still widely used. >> http://postfwd.org/ > > (Reminder: my aim is to allow emails for our site's users only if > the emails come from a certain dynamic list of addresses. It's a > tool to Filter Unauthorized Communications with Keyholes, or in > short, let's call it f.u.c.k.) > > I looked at the three solutions hinted at by Noel Jones. Postfwd was > closest to my needs but it seemed more straightforward to use > Postfix' SMTP Access Policy Delegation, which is mentioned in > Postfwd's own documentation. To this end I closely followed the > instructions provided by the documentation: > http://www.postfix.org/SMTPD_POLICY_README.html#client_config > > In master.cf I added the lines > # service type private unpriv chroot wakeup maxproc command > + args > policy unix - n n - 0 spawn > user=nobody argv=/home/seb/sandra/bin/fuck > (I tried writing this on 1 line or on 2 lines.) > > In main.cf I extended smtpd_recipient_restrictions to: > smtpd_recipient_restrictions = > reject_invalid_helo_hostname, > [...] > check_policy_service inet:127.0.0.1:10023, > check_policy_service unix:/home/seb/sandra/bin/fuck, > permit > and, as the doc instructed, I also added: > policy_time_limit = 3600 > > As for the Perl script that would decide whether an email should go > through or not, for testing purposes I simply wrote: > #!/usr/bin/perl > print "action=dunno\n\n"; > > I then did a "chmod a+x" on /home/seb/sandra/bin/fuck and a "postfix > reload"; my postfix version is 2.11 (Debian 8). > > This setup is as close to the documentation as I can make it. Yet I > have missed something because /var/log/mail.log says: > Nov 7 13:51:17 ns3358511 postfix/smtpd[14177]: warning: connect to > /home/seb/sandra/bin/fuck: No such file or directory > Nov 7 13:51:17 ns3358511 postfix/smtpd[14177]: warning: problem > talking > to server /home/seb/sandra/bin/fuck: No such file or directory > > although the file really exists: > ~>ls -l /home/seb/sandra/bin/fuck > -rwxr-xr-x 1 seb seb 2880 Nov 7 16:31 /home/seb/sandra/bin/fuck > > The problem could very well be something simple or so self-evident > that it was not deemed necessary to write it in the documentation. > > I toyed with this as much as I dared on a live system, and still > have no clue what the message in mail.log really means. > > Any help figuring this out would be very much appreciated, thank you! > > > Kind regards, > Sébastien. My first guess is http://www.postfix.org/DEBUG_README.html#no_chroot -- Noel Jones
Re: Tailored filter
Hello, I run a small publishing company and for the sake of easing communication between authors (who work in teams) I have provided each of them with a local alias. Typically, mail sent to .@ is redirected to .@gmail.com, the usual email address of the author. You can use a postfix policy service such as postfwd to create a list of allowed senders for some particular recipient. This isn't difficult, but will require manual intervention anytime a change is needed. Postfwd may be kinda old, but is still widely used. http://postfwd.org/ (Reminder: my aim is to allow emails for our site's users only if the emails come from a certain dynamic list of addresses. It's a tool to Filter Unauthorized Communications with Keyholes, or in short, let's call it f.u.c.k.) I looked at the three solutions hinted at by Noel Jones. Postfwd was closest to my needs but it seemed more straightforward to use Postfix' SMTP Access Policy Delegation, which is mentioned in Postfwd's own documentation. To this end I closely followed the instructions provided by the documentation: http://www.postfix.org/SMTPD_POLICY_README.html#client_config In master.cf I added the lines # service type private unpriv chroot wakeup maxproc command + args policyunix - n n - 0 spawn user=nobody argv=/home/seb/sandra/bin/fuck (I tried writing this on 1 line or on 2 lines.) In main.cf I extended smtpd_recipient_restrictions to: smtpd_recipient_restrictions = reject_invalid_helo_hostname, [...] check_policy_service inet:127.0.0.1:10023, check_policy_service unix:/home/seb/sandra/bin/fuck, permit and, as the doc instructed, I also added: policy_time_limit = 3600 As for the Perl script that would decide whether an email should go through or not, for testing purposes I simply wrote: #!/usr/bin/perl print "action=dunno\n\n"; I then did a "chmod a+x" on /home/seb/sandra/bin/fuck and a "postfix reload"; my postfix version is 2.11 (Debian 8). This setup is as close to the documentation as I can make it. Yet I have missed something because /var/log/mail.log says: Nov 7 13:51:17 ns3358511 postfix/smtpd[14177]: warning: connect to /home/seb/sandra/bin/fuck: No such file or directory Nov 7 13:51:17 ns3358511 postfix/smtpd[14177]: warning: problem talking to server /home/seb/sandra/bin/fuck: No such file or directory although the file really exists: ~>ls -l /home/seb/sandra/bin/fuck -rwxr-xr-x 1 seb seb 2880 Nov 7 16:31 /home/seb/sandra/bin/fuck The problem could very well be something simple or so self-evident that it was not deemed necessary to write it in the documentation. I toyed with this as much as I dared on a live system, and still have no clue what the message in mail.log really means. Any help figuring this out would be very much appreciated, thank you! Kind regards, Sébastien.
Re: bloc domains with all variants of tld
On Mon, 6 Nov 2017, Viktor Dukhovni wrote: /.*infusionmail.com$/ 550 Infusionmail is not wanted or welcome /.*\yahoo\.com/ 550 Yahoo.com is not allowed here, use gmail or someone who hasn't leaked 3 billion passwords /\.(com|net|org|edu|gov|ca|mx|de|dk|fi|uk|us|tv|info|biz|eu|es|il|it|nl|name|jp|host)$/ DUNNO /.*webinar.com/ 550 Die in a Fire spammer scum /.*xpoof\.us/ 550 Die is a Fire spammer scum /.*\.*/ 550 Mail for this TLD is not allowed (those are the TLDs that my server gets mail from, not recommending anyone else use that list). And thus we balkanize the Internet. I would discourage anyone from deploying such filters, IMHO they do more harm than good. There are many legitimate domains under ".xyz", ".ovh", ... and much junk email from ".biz" and ".info". Use decent RBLs and content-based filters, avoid crude tools that impose indiscriminate restrictions. The above is a bad idea, that may be tolerable for their creator, but such things do harm at a global level. Don't do it. I operate a bug tracker with free account registration. From time to time users with such "intelligent" filters try to register. Usually I simply remove the accounts to get rid of the bounces. It is not worth investigating when someone does not want to be contacted. :-) Ciao -- http://www.dstoecker.eu/ (PGP key available)
bounce notify class
I want to turn off the the bounce error class to reduce clutter in my postmaster mailbox, but don't want to miss something important. The bounce error class is defined ( http://www.postfix.org/postconf.5.html#notify_classes) as: 'Send the postmaster copies of the headers of bounced mail, and send transcripts of SMTP sessions when Postfix rejects mail.' I understand the second of these (and receive many of them, which I don't want) but not the first (and don't seem to receive any). What are 'copies of the headers of bounced mail' - would this be mail that has been bounced by Postfix (not interesting to me) or mail bounced by an onward mailserver (interesting to me - but maybe this is covered by the 2bounce error class)?
Re: Removal or obfuscation of mail_name
On 6 Nov 2017, at 14:26 (-0500), J Doe wrote: Is there any third-party servers or tools in the e-mail ecosystem that would depend on this being “Postfix” ? Nothing *SHOULD* depend on any particular content in the text part of any SMTP response except EHLO. As Viktor said, it's generally useless to pretend not to be Postfix, since there are clues you can't configure away. However, it can be interesting to see what some spambots try when you claim to be specific old versions of Sendmail. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Currently Seeking Steady Work: https://linkedin.com/in/billcole
