Re: fatal: no SASL authentication mechanisms
Edgar Pettijohn skrev den 2015-01-18 15:07: I think its default in a lot of distros. I know it is in openbsd and I'm pretty sure freebsd also. its not so in gentoo, living on edge ? :=)
Re: PATCH: smtps support (was: Problem relaying through Virginmedia)
On Thu, Jan 15, 2015 at 12:53:38PM +, Nick Howitt wrote: In the meanwhile as it will probably take ages for RHEL to incorporate your patches and upgrade to the latest version (I think I'm on 2.6.6-6 but I'd need to check at home) I'll follow your suggestion and look at stunnel. The new code is in Postfix 2.12-20150118. This, plus any final bits of polish, will become an official release in a couple of weeks or so. It might be 2.12, or it be 3.0. As for when RedHat might ship it, no idea. For what it is worth, I believe Debian jessie will ship 2.11, so a stable Debian release with Postfix 2.12 is a couple of years away. A RedHat release with 2.12 (or 3.0) will indeed likely keep you waiting for some time. -- Viktor.
Re: Conditional/soft smtpd restrictions
-Original Message- From: Noel Jones Sent: Saturday, January 17, 2015 12:20 AM You want to conditionally run some extra restrictions based on the outcome of prior restrictions? Some of the existing policy servers do weighted scoring, which gives very similar results. Conditional greylisting? Some of the existing greylisting daemons do that already. Do you have any specific suggestions? I looked at several policy servers and could not find one that could be (natively) configured to do what I want -- and I would like to avoid hacking/patching the internals... In fact, generally I feel that one of the problems with existing policy servers is that there are too many of them, without clear leader or clear comparison available =) The mtpolicyd can be used to apply actions based on scoring. The default configuration builds a score based on dns whitelist/blacklists, spf and geoip and applies actions based on the score: https://github.com/benningm/mtpolicyd/blob/master/etc/mtpolicyd.conf Based on the score the client is: * rejected (and if configured with fail2ban blocked on IP layer) * greylisted * pass If you're familiar with perl it should be easy to implement your own checks in plugins (without hacking internals): https://www.mtpolicyd.org/getting-started.html#Mail::MtPolicyd::Cookbook::BasicModule There are already several plugins: https://www.mtpolicyd.org/documentation.html Feedback, code, bug reports, requests welcome. Markus -- Markus Benning, https://markusbenning.de/
include part of bounced messaged
Hi All As I learned, setting bounce_size_limit=X, will drop original message of size X and more from bounce report. I wonder to know if it is possible in case of dropping oversize bounced message, include a few first bytes of the original message in the bounce report. Best Regards -payam
Re: fatal: no SASL authentication mechanisms
James Lockie skrev den 2015-01-18 05:40: On 01/17/15 22:55, Viktor Dukhovni wrote: On Sat, Jan 17, 2015 at 10:51:30PM -0500, James Lockie wrote: /var/log/mail.log postfix/smtpd[1519]: warning: SASL: Connect to /var/spool/postfix/private/auth failed: No such file or directory /etc/postfix/master.cf submission inet n - - - - smtpd -v -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING Just another chroot victim, Oh. Is Postfix and/or Dovecot chrooted by default? Can a message be output in the info log? you already see it in verbose logs ? submission inet n - n - - smtpd i have never seen a problem with dovecot just dont use - as default wish list
Re: custom script adds header
On 2015-01-18 23:35, Christian Rößner wrote: Am 18.01.2015 um 23:27 schrieb m...@ruggedinbox.com: Return-Path: vm...@ruggedinbox.com Delivered-To: m...@ruggedinbox.com Received: from localhost (localhost.localdomain [127.0.0.1]) by ruggedinbox.com (Postfix) with ESMTP id 7693331405C7 for m...@ruggedinbox.com; Sun, 18 Jan 2015 23:23:03 +0100 (CET) At this stage, the Return-Path is already included through the amavisd filter (Postfix smtpd_proxy_filter…). See below. It’s a while ago that I used proxy. Is it right that amavisd sends mail back over port 10024? (I use milters since decades) X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 required=5 tests=[NO_RECEIVED=-0.001, NO_RELAYS=-0.001] autolearn=no Received: from ruggedinbox.com ([127.0.0.1]) by localhost (ruggedinbox.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y_8qU3bCUyh9 for m...@ruggedinbox.com; Sun, 18 Jan 2015 23:23:01 +0100 (CET) It seems your test mail goes through amavisd, right? Not a milter. You are using proxy as described above? So I guess your Return-Path is added here, not later. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 18 Jan 2015 22:23:01 + From: m...@ruggedinbox.com To: m...@ruggedinbox.com Subject: test3 Message-ID: 4cbb98dd59ce89a54078d25049815...@ruggedinbox.com X-Sender: m...@ruggedinbox.com Just what I guess… Christian -- Bachelor of Science Informatik Erlenwiese 14, 36304 Alsfeld T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345 USt-IdNr.: DE225643613, http://www.roessner-network-solutions.com Hi yes we use amavis, not using milter and not using proxy. We checked our configuration and google and were unable to find references about amavis and 'return-path'. The relevant lines in master.cf are: amavis unix - - - - 1 smtp -o smtp_data_done_timeout=1200 -o smtp_send_xforward_command=yes -o disable_dns_lookups=yes -o max_use=2 and in main.cf: content_filter = amavis:[127.0.0.1]:10024 Anyway we tried to comment the line in main.cf which calls our custom script and the return-path is correct: Return-Path: m...@ruggedinbox.com so it looks like the problem is around the script or its invocation. Thank you.
Re: custom script adds header
On 2015-01-18 23:51, wie...@porcupine.org wrote: m...@ruggedinbox.com: and the header is still there. By default, Postfix REMOVES Return-Path headers from email messages. The default setting is: message_drop_headers = bcc, content-length, resent-bcc, return-path You claim that you removed all the pipe R flags. You can verify that by temporarily configuring the pipe daemon to deliver the mail to the command /usr/bin/logger -p mail.info Then you can see all the headers and content in the maillog file. The discussion has focused on the pipe with the content filter, but there are other places where the header may be added. If there are other places in the mail flow that invoke a pipe daemon, you also need to temporarily configuring the pipe daemon to deliver the mail to the command /usr/bin/logger -p mail.info Again, convince yourself that Return-Path is absent. Wietse We tried to use the 'message_drop_headers' parameter in both main.cf and master.cf (under the 'cleanup' line) but always get the error: [] Reloading Postfix configuration.../usr/sbin/postconf: warning: /etc/postfix/master.cf: unused parameter: message_drop_headers=bcc,content-length,resent-bcc,return-path can we have a working example of how to use it ? Also, at the end of the main.cf file, we have: mime_header_checks = pcre:/etc/postfix/header_checks smtp_header_checks = pcre:/etc/postfix/header_checks and in the 'header_checks' file we have a number of regexp to strip headers, for example: /^\s*X-Mailer/ IGNORE /^\s*X-Originating-IP/ IGNORE maybe this conflicts with the default parameters of 'message_drop_headers' ? Anyway we tried to add 'Return-Path' to the 'header_checks' file but the header is still there. Finally we tried to comment the line in main.cf which calls our custom script and the return-path is correct: Return-Path: m...@ruggedinbox.com so it looks like the problem is around the script or its invocation. Thank you.
Re: custom script adds header
m...@ruggedinbox.com: By default, Postfix REMOVES Return-Path headers from email messages. The default setting is: message_drop_headers = bcc, content-length, resent-bcc, return-path That is the default setting. We tried to use the 'message_drop_headers' parameter in both main.cf and master.cf (under the 'cleanup' line) but always get the error: There is no need to seet this. It is the default. [] Reloading Postfix configuration.../usr/sbin/postconf: warning: /etc/postfix/master.cf: unused parameter: message_drop_headers=bcc,content-length,resent-bcc,return-path can we have a working example of how to use it ? You don't need to set this. It is the default. Finally we tried to comment the line in main.cf which calls our custom script and the return-path is correct: Return-Path: m...@ruggedinbox.com so it looks like the problem is around the script or its invocation. OK, so you know the mistake is outside Postfix. Wietse
DMARC
I am not sure about implementing DMARC on my servers. However, is it worth adding a DMARC record to the DNS? What, if anything, would it buy us. If we were to add such a record, what would be the best setup/set of parameters be? -- John Allen KLaM -- How many of you believe in telekinesis? Raise my hand... smime.p7s Description: S/MIME Cryptographic Signature
Re: custom script adds header
On 2015-01-19 00:53, wie...@porcupine.org wrote:
m...@ruggedinbox.com:
By default, Postfix REMOVES Return-Path headers from email messages.
The default setting is:
message_drop_headers = bcc, content-length, resent-bcc, return-path
That is the default setting.
We tried to use the 'message_drop_headers' parameter in both main.cf
and
master.cf (under the 'cleanup' line) but always get the error:
There is no need to seet this. It is the default.
[] Reloading Postfix configuration.../usr/sbin/postconf: warning:
/etc/postfix/master.cf: unused parameter:
message_drop_headers=bcc,content-length,resent-bcc,return-path
can we have a working example of how to use it ?
You don't need to set this. It is the default.
Finally we tried to comment the line in main.cf which calls our custom
script
and the return-path is correct:
Return-Path: m...@ruggedinbox.com
so it looks like the problem is around the script or its invocation.
OK, so you know the mistake is outside Postfix.
Wietse
Yes that's the subject of the thread
and since the script gets invoked by postfix
and sends back the email to postfix, it is postfix related.
Otherwise were could we ask for help, on the PHP mailing list ? ;)
The script checks a number of things and then uses 'sendmail' for the
delivery:
unset($argv[0]);
$sendmail = '/usr/sbin/sendmail -G -i ' . implode(' ', $argv);
$handle = popen($sendmail, 'w');
fwrite($handle, $content);
$sendmail_return_value = pclose($handle);
as you can see there is the -G flag, but the Return-Path header is still
there and gets modified with, probably, the owner of the process
(vmail).
You say that postfix removes the header as the default behavior
so we checked the 'message_drop_headers' parameter (which is missing in
our config)
and asked, with examples, if some other parameter would affect
'message_drop_headers'.
Perhaps we could pass ${sender} to our custom script
and then use sendmail's -f argument to change the Return-Path header ?
Re: DMARC
On Sun, January 18, 2015 20:14, John wrote: I am not sure about implementing DMARC on my servers. However, is it worth adding a DMARC record to the DNS? What, if anything, would it buy us. Nothing, unless you have somebody to read the reports and the capacity to act on them. All DMARC will tell you is if somebody else is pretending to be you. It does, however, help protect other people from getting fraudulently addressed email claiming to originate from your domain. Services exist that will accept DMARC reports and analyse them for you. I am not sure about the privacy and security implications of that approach. If we were to add such a record, what would be the best setup/set of parameters be? If you have people posting though mailing lists then it is likely best that you leave DMARC policy set to none or possibly quarantine. Reject is probably too severe to seriously consider for some time yet; Yahoo, AOL et al. positions on the matter notwithstanding. Be aware that Google will deliver quarantined messages to the Gmail users spam folder. User sending mail from a quarantined DMARC domain through a mailing list will likely have many of their messages disappear when sent to subscribers with Gmail accounts. -- *** E-Mail is NOT a SECURE channel *** James B. Byrnemailto:byrn...@harte-lyne.ca Harte Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
Re: custom script adds header
m...@ruggedinbox.com:
Perhaps we could pass ${sender} to our custom script
and then use sendmail's -f argument to change the Return-Path header ?
The -f argument IS THE RETURN-PATH ADDRESS.
SENDMAIL(1)SENDMAIL(1)
NAME
sendmail - Postfix to Sendmail compatibility interface
SYNOPSIS
sendmail [option ...] [recipient ...]
-f sender
Set the envelope sender address. This is the address where
delivery problems are sent to.
If you ever find the time to read up on Internet email, that is also
the address that ends up in the Return-Path header.
That has nothing to do with Postfix. All mail systems with a
sendmail command work that way.
Wietse
Re: SPF configurations
Am 18.01.2015 um 12:01 schrieb SW: I have an SPF record created in DNS for my domain. In my main.cf config file for Postfix I have the following SPF settings: spf_received_header = yes spf_mark_only = no smtpd_recipient_restrictions = peject_spf_invalid_sender, permit_spf_valid_sender, smtpd_sender_restrictions = reject_spf_invalid_sender, permit_spf_valid_sender Is the above config correct to reject received emails that is NOT being delivered from the specified IP addresses in SPF? a) postfix don' t support SPF out of the box there are policy daemons for that task b) hence all the spf_ params are fantasy c) SPF of your own domain is not relevant for yourself to receive mails, to prevent forged mails just add you domains in a access table with a reject and place permit_mynetworks and permit_sasl_authenticated in front of that restriction
Re: SPF configurations
Am 18.01.2015 um 12:28 schrieb SW: Am 18.01.2015 um 12:01 schrieb SW: I have an SPF record created in DNS for my domain. In my main.cf config file for Postfix I have the following SPF settings: spf_received_header = yes spf_mark_only = no smtpd_recipient_restrictions = peject_spf_invalid_sender, permit_spf_valid_sender, smtpd_sender_restrictions = reject_spf_invalid_sender, permit_spf_valid_sender Is the above config correct to reject received emails that is NOT being delivered from the specified IP addresses in SPF? a) postfix don' t support SPF out of the box there are policy daemons for that task b) hence all the spf_ params are fantasy c) SPF of your own domain is not relevant for yourself to receive mails, to prevent forged mails just add you domains in a access table with a reject and place permit_mynetworks and permit_sasl_authenticated in front of that restriction When I ran make config (on FreeBSD) to install the Postfix port I selected the SPF support option. I assumed that would allow me to do SPF checking with the options I mentioned? Although, I just noticed that when I ran make config now it says: SPF - SPF support (via libspf2 1.2.x) that's a unofficial patch i guess and would have been a good idea to mention your environemnt in the initial post Is this the policy you were referring to? I do have libspf2 installed currently. i referred to a *policy daemon* http://www.postfix.org/SMTPD_POLICY_README.html https://www.google.at/search?q=spf+policyd If I check the mail headers I can see the SPF: Received-SPF: pass (mail.domain.com: domain of anotherdomain.net designates xxx.xxx.xxx.xxx as permitted sender) Does this mean SPF is working correctly? looks so but that's likely the wrong mailing list because these options are *not* part of a stock postfix https://www.google.at/search?q=postfix+reject_spf_invalid_sender
for in Received: is missing
I hope this question is not too stupid... But I miss the for line in the Received: Header in my Postfix. I guess it has to do with my SpamAssassin-Configuration. But I don't know where to start to look. Here is an example. you see the for is in the Received: from cloud9. Then there are the lines from SpamAssassin. And then the Received from my nobswolf with the for missing: Received: by nobswolf.info (Postfix, from userid 5001) id 67C5D44BA023; Sun, 18 Jan 2015 12:29:28 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on nobswolf.info X-Spam-Level: X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_ADSP_ALL, RCVD_IN_DNSWL_HI,URIBL_BLOCKED,URI_HEX autolearn=ham version=3.3.1 X-Spam-fromip: 168.100.1.7 X-Greylist: delayed 359 seconds by postgrey-1.32 at h1169115.serverkompetenz.net; Sun, 18 Jan 2015 12:29:25 CET Received: from english-breakfast.cloud9.net (english-breakfast.cloud9.net [168.100.1.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN mail.cloud9.net, Issuer GeoTrust DV SSL CA (not verified)) by nobswolf.info (Postfix) with ESMTPS id B65BC44BA010 for n...@nobswolf.info; Sun, 18 Jan 2015 12:29:25 +0100 (CET) Postfix is version 2.7.1 Is this a problem with Postfix or with SpamAssassin? Thanks for any hints. attachment: nobs.vcf
Re: fatal: no SASL authentication mechanisms
On 01/18/15 09:07, Edgar Pettijohn wrote: better make a bugreport at your distribution https://www.google.at/search?q=postfix+debian+chroot+problems Assuming this is Debian, there's no bug report needed. It's an intentional maintainer choice and not a bug. Scott K I think its default in a lot of distros. I know it is in openbsd and I'm pretty sure freebsd also. What would cause the warning: SASL: Connect to /var/spool/postfix/private/auth failed: No such file or directory to come back after working for a while? I had to restart dovecot and postfix, Is there any postfix debug tool like doveadm that I can run to test authentication?
Re: SPF configurations
On Sun, 18 Jan 2015 07:20:35 -0700 (MST) SW post...@bsdpanic.com wrote: But I now get the following error in maillog: * Jan 18 13:26:59 mail policyd-spf[58514]: Action: prepend: Text: Received-SPF: Temperror (SPF Temporary Error: DNS Timeout) identity=mailfrom; client-ip=209.85.216.170; helo=mail-qc0-f170.google.com; envelope-from=qlx...@gmail.com; receiver=m...@domain.com* make sure all requirement policyd-spf is installed. maybe you missing DNS python module. try to run /usr/local/bin/policyd-spf at the console and see what happen. check also mail log...
Re: SPF configurations
On Sun, 18 Jan 2015 08:30:29 -0700 (MST) SW post...@bsdpanic.com wrote: If I run /usr/local/bin/policyd-spf at the console it just does nothing? (theres no output) yes, it does not provide any output. it mean policyd-spf are fine and all requirement python module is ok. ask at freebsd port maintainer, ask him/her about this error. good luck...
Re: SPF configurations
Thanks for the help. I have installed the postfix-policyd-spf-python port on my FreeBSD server and enabled it in the main.cf and master.cf config files as follows: smtpd_recipient_restrictions = check_policy_service unix:private/policyd-spf policyd-spf unix - n n - 0 spawn user=nobody argv=/usr/local/bin/policyd-spf But I now get the following error in maillog: * Jan 18 13:26:59 mail policyd-spf[58514]: Action: prepend: Text: Received-SPF: Temperror (SPF Temporary Error: DNS Timeout) identity=mailfrom; client-ip=209.85.216.170; helo=mail-qc0-f170.google.com; envelope-from=qlx...@gmail.com; receiver=m...@domain.com* I know my DNS is working as when I run dig txt _spf.google.com I get Googles SPF records: ;; ANSWER SECTION: _spf.google.com. 300 IN TXT v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all I'm using my ISPs DNS servers and have been using them with Postscreen/RBLs successfully for years. Can anyone help? If this is the incorrect forum then apologies! -- View this message in context: http://postfix.1071664.n5.nabble.com/SPF-configurations-tp73872p73880.html Sent from the Postfix Users mailing list archive at Nabble.com.
Re: SPF configurations
On January 18, 2015 6:36:51 AM EST, li...@rhsoft.net li...@rhsoft.net wrote: Am 18.01.2015 um 12:28 schrieb SW: Am 18.01.2015 um 12:01 schrieb SW: I have an SPF record created in DNS for my domain. In my main.cf config file for Postfix I have the following SPF settings: spf_received_header = yes spf_mark_only = no smtpd_recipient_restrictions = peject_spf_invalid_sender, permit_spf_valid_sender, smtpd_sender_restrictions = reject_spf_invalid_sender, permit_spf_valid_sender Is the above config correct to reject received emails that is NOT being delivered from the specified IP addresses in SPF? a) postfix don' t support SPF out of the box there are policy daemons for that task b) hence all the spf_ params are fantasy c) SPF of your own domain is not relevant for yourself to receive mails, to prevent forged mails just add you domains in a access table with a reject and place permit_mynetworks and permit_sasl_authenticated in front of that restriction When I ran make config (on FreeBSD) to install the Postfix port I selected the SPF support option. I assumed that would allow me to do SPF checking with the options I mentioned? Although, I just noticed that when I ran make config now it says: SPF - SPF support (via libspf2 1.2.x) that's a unofficial patch i guess and would have been a good idea to mention your environemnt in the initial post Is this the policy you were referring to? I do have libspf2 installed currently. i referred to a *policy daemon* http://www.postfix.org/SMTPD_POLICY_README.html https://www.google.at/search?q=spf+policyd If I check the mail headers I can see the SPF: Received-SPF: pass (mail.domain.com: domain of anotherdomain.net designates xxx.xxx.xxx.xxx as permitted sender) Does this mean SPF is working correctly? looks so but that's likely the wrong mailing list because these options are *not* part of a stock postfix https://www.google.at/search?q=postfix+reject_spf_invalid_sender Early in the SPF project, there were some unofficial postfix patches developed that integrated SPF checking directly into Postfix. This was before the Postfix policy service was introduced in Postfix 2.1. They have not been recommended by the SPF project since shortly after 2.1 was released. Libspf2 1.2 is similarly ancient (2.10 is the current version). Versions older than approximately 2.8 suffer from some serious security issues and are not suitable for use. Regardless of if your setup is functional, it's not one you want. As already mentioned, use a policy server to check SPF. There are (IIRC) multiple choices available in Ports. Scott K
Re: fatal: no SASL authentication mechanisms
On 01/18/15 08:55, James Lockie wrote: On 01/18/15 09:07, Edgar Pettijohn wrote: better make a bugreport at your distribution https://www.google.at/search?q=postfix+debian+chroot+problems Assuming this is Debian, there's no bug report needed. It's an intentional maintainer choice and not a bug. Scott K I think its default in a lot of distros. I know it is in openbsd and I'm pretty sure freebsd also. What would cause the warning: SASL: Connect to /var/spool/postfix/private/auth failed: No such file or directory to come back after working for a while? I had to restart dovecot and postfix, Is there any postfix debug tool like doveadm that I can run to test authentication? I think what it comes down to is if you have turned off chroot or not. If not you need to think about the following lines: /etc/postfix/main.cf smtpd_sasl_type = dovecot smtpd_sasl_path = /var/spool/postfix/private/auth Because if you are chroot its really looking for /var/spool/postfix/var/spool/postfix/private/auth which doesn't exist most likely.
Re: fatal: no SASL authentication mechanisms
On 01/18/15 10:03, Edgar Pettijohn wrote: On 01/18/15 08:55, James Lockie wrote: On 01/18/15 09:07, Edgar Pettijohn wrote: better make a bugreport at your distribution https://www.google.at/search?q=postfix+debian+chroot+problems Assuming this is Debian, there's no bug report needed. It's an intentional maintainer choice and not a bug. Scott K I think its default in a lot of distros. I know it is in openbsd and I'm pretty sure freebsd also. What would cause the warning: SASL: Connect to /var/spool/postfix/private/auth failed: No such file or directory to come back after working for a while? I had to restart dovecot and postfix, Is there any postfix debug tool like doveadm that I can run to test authentication? I think what it comes down to is if you have turned off chroot or not. If not you need to think about the following lines: /etc/postfix/main.cf smtpd_sasl_type = dovecot smtpd_sasl_path = /var/spool/postfix/private/auth Because if you are chroot its really looking for /var/spool/postfix/var/spool/postfix/private/auth which doesn't exist most likely. I turned off chroot, that is why it works for a while. :-(
Re: SPF configurations
Koko Wijatmoko wrote make sure all requirement policyd-spf is installed. maybe you missing DNS python module. try to run /usr/local/bin/policyd-spf at the console and see what happen. check also mail log... When you install the policyd-spf port on FreeBSD it installs all the required dependencies for you. I've already quoted the error I get in maillog but here it is again: Jan 18 13:26:59 mail policyd-spf[58514]: Action: prepend: *Text: Received-SPF: Temperror (SPF Temporary Error: DNS Timeout)* identity=mailfrom; client-ip=209.85.216.170; helo=mail-qc0-f170.google.com; envelope-from=qlx...@gmail.com; receiver=m...@domain.com If I run /usr/local/bin/policyd-spf at the console it just does nothing? (theres no output) -- View this message in context: http://postfix.1071664.n5.nabble.com/SPF-configurations-tp73872p73888.html Sent from the Postfix Users mailing list archive at Nabble.com.
chroot defaults (was: fatal: no SASL authentication mechanisms)
better make a bugreport at your distribution https://www.google.at/search?q=postfix+debian+chroot+problems Scott K: Assuming this is Debian, there's no bug report needed. It's an intentional maintainer choice and not a bug. Edgar Pettijohn: I think its default in a lot of distros. I know it is in openbsd and I'm pretty sure freebsd also. With the upcoming stable release(*), the built-in chroot is no by default. However, a built-in backwards-compatibility safety net will preserve past Postfix behavior, so if the maintainers get it right, then you get to decide if you like the new defaults, not the maintainers. http://www.postfix.org/COMPATIBILITY_README.html *I expect to issue release candidates in a week or so. Wietse
Re: fatal: no SASL authentication mechanisms
better make a bugreport at your distribution https://www.google.at/search?q=postfix+debian+chroot+problems Assuming this is Debian, there's no bug report needed. It's an intentional maintainer choice and not a bug. Scott K I think its default in a lot of distros. I know it is in openbsd and I'm pretty sure freebsd also.
Re: SPF configurations
Thanks Scott. If you look at my previous post you can see that I have installed postfix-policyd-spf-python but am having DNS timeout issues when I enable it. I have been looking online for a solition but have come up empty handed so far! -- View this message in context: http://postfix.1071664.n5.nabble.com/SPF-configurations-tp73872p73882.html Sent from the Postfix Users mailing list archive at Nabble.com.
Re: fatal: no SASL authentication mechanisms
* James Lockie robertloc...@teksavvy.com: On 01/18/15 09:07, Edgar Pettijohn wrote: better make a bugreport at your distribution https://www.google.at/search?q=postfix+debian+chroot+problems Assuming this is Debian, there's no bug report needed. It's an intentional maintainer choice and not a bug. Scott K I think its default in a lot of distros. I know it is in openbsd and I'm pretty sure freebsd also. What would cause the warning: SASL: Connect to /var/spool/postfix/private/auth failed: No such file or directory to come back after working for a while? I had to restart dovecot and postfix, Is there any postfix debug tool like doveadm that I can run to test authentication? Sure, read the docs out there. There's plenty of them. Start at the Postfix Website in the section about debugging. p@rick -- [*] sys4 AG https://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
SPF configurations
Hello I have an SPF record created in DNS for my domain. In my main.cf config file for Postfix I have the following SPF settings: spf_received_header = yes spf_mark_only = no smtpd_recipient_restrictions = peject_spf_invalid_sender, permit_spf_valid_sender, smtpd_sender_restrictions = reject_spf_invalid_sender, permit_spf_valid_sender Is the above config correct to reject received emails that is NOT being delivered from the specified IP addresses in SPF? I basically want to reject/fail emails that are not coming from the correct IP address specified by the domains SPF record. Also, recently I received one of these: This is a spf/dkim authentication-failure report for an email message received from IP 14.16.26.208 on Sun, 11 Jan 2015 00:32:42 +0800. Below is some detail information about this message: 1. SPF-authenticated Identifiers: none; 2. DKIM-authenticated Identifiers: none; 3. DMARC Mechanism Check Result: Identifier non-aligned, DMARC mechanism check failures; For more information please check Aggregate Reports or mail to [hidden email]. Feedback-Type: auth-failure User-Agent: NtesDmarcReporter/1.0 Version: 1 Original-Mail-From: [hidden email] Arrival-Date: Sun, 11 Jan 2015 00:32:42 +0800 Source-IP: 14.16.26.208 Reported-Domain: mydomain.com Original-Envelope-Id: PMCowEApi0cjVLFUK2fmEQ--.1291S2 Authentication-Results: 163.com; dkim=none; spf=fail [hidden email] Delivery-Result: delivered Received: from qoeeisq (unknown [150.108.4.5]) by mydomain.com with SMTP id 1UqgGfirbN2SASB9.1 for [hidden email]; Sun, 11 Jan 2015 00:32:40 +0800 Message-ID: 2D836C2DA068C6B28993B9B4FEBCFF2D@qoeeisq From: --- [hidden email] To: [hidden email] Subject: =?big5?B?ru+sS6tC?= Date: Sun, 11 Jan 2015 00:32:35 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Does this mean SPF has failed as it said that the delivery results says delivered? I didn't receive this email so maybe its fake? What is the above message? Thank you. -- View this message in context: http://postfix.1071664.n5.nabble.com/SPF-configurations-tp73872.html Sent from the Postfix Users mailing list archive at Nabble.com.
Re: fatal: no SASL authentication mechanisms
Am 18.01.2015 um 06:14 schrieb Viktor Dukhovni: On Sun, Jan 18, 2015 at 12:02:24AM -0500, Scott Kitterman wrote: better make a bugreport at your distribution https://www.google.at/search?q=postfix+debian+chroot+problems Assuming this is Debian, there's no bug report needed. It's an intentional maintainer choice and not a bug. I think the intentional maintainer choice has long proved unwise. So though not a bug, it is definitely misfeature. Since the default chroot is far from seamless: - Lost logs - Milter socket problems - SASL problems - DNS resolution problems - ... If the level of integration were such that none of these issues were to ever happen, I'd accept this as a valid maintainer choice. Given that problems come up all the time, I rather see this is a maintainer mistake that should finally be corrected. Chroot is for experts willing and able to figure out what needs to be done to get it working. As a default Debian/Ubuntu configuration I think it just needlessly gives Postfix on these systems a bad name. that's all true but if each and every day a new user opens a fresh bugreport claiming the defualts are broken and stupid over the time the intentional maintainer choice may change that won't happen by explain the same porblem on that list each week __ honestly postfix is not completly innocent because the internal default should be no for - instead yes, i saw way too much people believe it's disabled untill someone explained that this is only the case with an explicit n having it enabled builtin but with the shipped default config disabled is not really the best way to explain people it's a bad idea enable it until you know exactly what you are doing
Re: for in Received: is missing
nobswolf: I hope this question is not too stupid... But I miss the for line in the Received: Header in my Postfix. The for clause is not required (RFC 5321 section 4.4). Postfix adds it if there is **one** RCPT TO command. Wietse
Re: SPF configurations
Am 18.01.2015 um 12:01 schrieb SW: I have an SPF record created in DNS for my domain. In my main.cf config file for Postfix I have the following SPF settings: spf_received_header = yes spf_mark_only = no smtpd_recipient_restrictions = peject_spf_invalid_sender, permit_spf_valid_sender, smtpd_sender_restrictions = reject_spf_invalid_sender, permit_spf_valid_sender Is the above config correct to reject received emails that is NOT being delivered from the specified IP addresses in SPF? a) postfix don' t support SPF out of the box there are policy daemons for that task b) hence all the spf_ params are fantasy c) SPF of your own domain is not relevant for yourself to receive mails, to prevent forged mails just add you domains in a access table with a reject and place permit_mynetworks and permit_sasl_authenticated in front of that restriction When I ran make config (on FreeBSD) to install the Postfix port I selected the SPF support option. I assumed that would allow me to do SPF checking with the options I mentioned? Although, I just noticed that when I ran make config now it says: SPF - SPF support (via libspf2 1.2.x) Is this the policy you were referring to? I do have libspf2 installed currently. If I check the mail headers I can see the SPF: Received-SPF: pass (mail.domain.com: domain of anotherdomain.net designates xxx.xxx.xxx.xxx as permitted sender) Does this mean SPF is working correctly? -- View this message in context: http://postfix.1071664.n5.nabble.com/SPF-configurations-tp73872p73875.html Sent from the Postfix Users mailing list archive at Nabble.com.
Re: custom script adds header
On 2015-01-18 18:43, wie...@porcupine.org wrote:
m...@ruggedinbox.com:
Hi!
At the end of the /etc/postfix/master.cf file (Debian Wheezy)
we have a nice custom PHP script which checks and limits outgoing
emails:
outCustomFilter unix - n n - - pipe
flags=F user=vmail:vmail argv=/etc/postfix/outCustomFilter.php
${recipient}
This script does its checks and if everything looks fine, it sends the
email to the destination:
unset($argv[0]);
$sendmail = '/usr/sbin/sendmail -G -i ' . implode(' ', $argv);
$handle = popen($sendmail, 'w');
fwrite($handle, $content);
$sendmail_return_value = pclose($handle);
Problem: when postfix runs the script, it also adds an header, not
sure
if
X-Postfix-Sender: rfc822; vm...@ruggedinbox.com
or
Return-Path: vm...@ruggedinbox.com
The Postfix bounce(8) daemon reports X-Postfix-Sender in a delivery
status notification, but evenm there, it is not part of a message
header.
The Postfix pipe(8) daemon prepends Return-Path only when the pipe
command flag 'R' is specified.
Wietse
anyway .. it is possible to remove that additional header ?
Thank you,
RuggedInbox team
Hi ok we double checked and this is the source of an email sent from
m...@ruggedinbox.com to m...@ruggedinbox.com:
Return-Path: vm...@ruggedinbox.com
Delivered-To: m...@ruggedinbox.com
Received: from localhost (localhost.localdomain [127.0.0.1])
by ruggedinbox.com (Postfix) with ESMTP id 75B4C3140083
for m...@ruggedinbox.com; Sun, 18 Jan 2015 20:28:26 +0100 (CET)
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level:
X-Spam-Status: No, score=-0.002 required=5 tests=[NO_RECEIVED=-0.001,
NO_RELAYS=-0.001] autolearn=no
Received: from ruggedinbox.com ([127.0.0.1])
by localhost (ruggedinbox.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id uDmvEM5lO0vR for m...@ruggedinbox.com;
Sun, 18 Jan 2015 20:28:24 +0100 (CET)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Sun, 18 Jan 2015 19:28:24 +
From: m...@ruggedinbox.com
To: m...@ruggedinbox.com
Subject: test
Message-ID: 99d775ed6c322d7165bc4dfb8eca5...@ruggedinbox.com
X-Sender: m...@ruggedinbox.com
test
so it looks like 'Return-Path: vm...@ruggedinbox.com' is added.
We have some 'R' flag enabled in master.cf:
dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d
${recipient}
spamassassin unix - n n - - pipe
flags=R user=debian-spamd argv=/usr/bin/spamc -e /usr/sbin/sendmail
-oi -f ${sender} ${recipient}
do you think the problem is here ?
Re: custom script adds header
Am 18.01.2015 um 19:36 schrieb m...@ruggedinbox.com:
At the end of the /etc/postfix/master.cf file (Debian Wheezy)
we have a nice custom PHP script which checks and limits outgoing emails:
outCustomFilter unix - n n - - pipe
flags=F user=vmail:vmail argv=/etc/postfix/outCustomFilter.php
${recipient}
This script does its checks and if everything looks fine, it sends the
email to the destination:
unset($argv[0]);
$sendmail = '/usr/sbin/sendmail -G -i ' . implode(' ', $argv);
$handle = popen($sendmail, 'w');
fwrite($handle, $content);
$sendmail_return_value = pclose($handle);
Problem: when postfix runs the script, it also adds an header, not sure if
X-Postfix-Sender: rfc822; vm...@ruggedinbox.com
or
Return-Path: vm...@ruggedinbox.com
anyway .. it is possible to remove that additional header?
first: why?
second: http://www.postfix.org/postconf.5.html#smtp_header_checks
custom script adds header
Hi!
At the end of the /etc/postfix/master.cf file (Debian Wheezy)
we have a nice custom PHP script which checks and limits outgoing
emails:
outCustomFilter unix - n n - - pipe
flags=F user=vmail:vmail argv=/etc/postfix/outCustomFilter.php
${recipient}
This script does its checks and if everything looks fine, it sends the
email to the destination:
unset($argv[0]);
$sendmail = '/usr/sbin/sendmail -G -i ' . implode(' ', $argv);
$handle = popen($sendmail, 'w');
fwrite($handle, $content);
$sendmail_return_value = pclose($handle);
Problem: when postfix runs the script, it also adds an header, not sure
if
X-Postfix-Sender: rfc822; vm...@ruggedinbox.com
or
Return-Path: vm...@ruggedinbox.com
anyway .. it is possible to remove that additional header ?
Thank you,
RuggedInbox team
Re: custom script adds header
m...@ruggedinbox.com:
Hi!
At the end of the /etc/postfix/master.cf file (Debian Wheezy)
we have a nice custom PHP script which checks and limits outgoing
emails:
outCustomFilter unix - n n - - pipe
flags=F user=vmail:vmail argv=/etc/postfix/outCustomFilter.php
${recipient}
This script does its checks and if everything looks fine, it sends the
email to the destination:
unset($argv[0]);
$sendmail = '/usr/sbin/sendmail -G -i ' . implode(' ', $argv);
$handle = popen($sendmail, 'w');
fwrite($handle, $content);
$sendmail_return_value = pclose($handle);
Problem: when postfix runs the script, it also adds an header, not sure
if
X-Postfix-Sender: rfc822; vm...@ruggedinbox.com
or
Return-Path: vm...@ruggedinbox.com
The Postfix bounce(8) daemon reports X-Postfix-Sender in a delivery
status notification, but evenm there, it is not part of a message
header.
The Postfix pipe(8) daemon prepends Return-Path only when the pipe
command flag 'R' is specified.
Wietse
anyway .. it is possible to remove that additional header ?
Thank you,
RuggedInbox team
Re: custom script adds header
On Sun, Jan 18, 2015 at 07:41:15PM +, m...@ruggedinbox.com wrote:
Hi ok we double checked and this is the source of an email sent from
m...@ruggedinbox.com to m...@ruggedinbox.com:
Return-Path: vm...@ruggedinbox.com
Delivered-To: m...@ruggedinbox.com
[...]
so it looks like 'Return-Path: vm...@ruggedinbox.com' is added.
We have some 'R' flag enabled in master.cf:
dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${recipient}
Why do you believe that adding Return-Path on final delivery is a
problem? It is rather a requirement IMHO.
spamassassin unix - n n - - pipe
flags=R user=debian-spamd argv=/usr/bin/spamc -e /usr/sbin/sendmail -oi -f
${sender} ${recipient}
do you think the problem is here ?
This is not final delivery, don't use R here. And don't forget --
before the recipient list.
spamassassin unix - n n - - pipe
flags=R user=debian-spamd
argv=/usr/bin/spamc -e /usr/sbin/sendmail -oi -f ${sender} --
${recipient}
Postfix does its best to protect you with:
http://www.postfix.org/postconf.5.html#allow_min_user
but it is best to not rely on that too much.
--
Viktor.
Re: custom script adds header
Am 18.01.2015 um 23:27 schrieb m...@ruggedinbox.com: Return-Path: vm...@ruggedinbox.com Delivered-To: m...@ruggedinbox.com Received: from localhost (localhost.localdomain [127.0.0.1]) by ruggedinbox.com (Postfix) with ESMTP id 7693331405C7 for m...@ruggedinbox.com; Sun, 18 Jan 2015 23:23:03 +0100 (CET) At this stage, the Return-Path is already included through the amavisd filter (Postfix smtpd_proxy_filter…). See below. It’s a while ago that I used proxy. Is it right that amavisd sends mail back over port 10024? (I use milters since decades) X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 required=5 tests=[NO_RECEIVED=-0.001, NO_RELAYS=-0.001] autolearn=no Received: from ruggedinbox.com ([127.0.0.1]) by localhost (ruggedinbox.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y_8qU3bCUyh9 for m...@ruggedinbox.com; Sun, 18 Jan 2015 23:23:01 +0100 (CET) It seems your test mail goes through amavisd, right? Not a milter. You are using proxy as described above? So I guess your Return-Path is added here, not later. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 18 Jan 2015 22:23:01 + From: m...@ruggedinbox.com To: m...@ruggedinbox.com Subject: test3 Message-ID: 4cbb98dd59ce89a54078d25049815...@ruggedinbox.com X-Sender: m...@ruggedinbox.com Just what I guess… Christian -- Bachelor of Science Informatik Erlenwiese 14, 36304 Alsfeld T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345 USt-IdNr.: DE225643613, http://www.roessner-network-solutions.com signature.asc Description: Message signed with OpenPGP using GPGMail
Re: SPF configurations
On Sun, January 18, 2015 17:21, SW wrote: I don't run a firewall on my server and my router allows ALL outgoing traffic. Whats weird is I use RBLs in Postfix which relies heavily on DNS and that works 100% but for some reason policyd-spf will not do a successful DNS lookup! When running dig on a domain and specifying a txt record type I get a successful reply. Totally baffled by this! Thanks for the suggestion. On 18/01/2015 21:38, James B. Byrne wrote: On Sun, January 18, 2015 10:30, SW wrote: If I run /usr/local/bin/policyd-spf at the console it just does nothing? (theres no output) Have you opened tcp 53 on your firewall? What are the contents of your /etc/resolv.conf? Are any of the listed resolvers down? -- *** E-Mail is NOT a SECURE channel *** James B. Byrnemailto:byrn...@harte-lyne.ca Harte Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
Re: custom script adds header
m...@ruggedinbox.com: and the header is still there. By default, Postfix REMOVES Return-Path headers from email messages. The default setting is: message_drop_headers = bcc, content-length, resent-bcc, return-path You claim that you removed all the pipe R flags. You can verify that by temporarily configuring the pipe daemon to deliver the mail to the command /usr/bin/logger -p mail.info Then you can see all the headers and content in the maillog file. The discussion has focused on the pipe with the content filter, but there are other places where the header may be added. If there are other places in the mail flow that invoke a pipe daemon, you also need to temporarily configuring the pipe daemon to deliver the mail to the command /usr/bin/logger -p mail.info Again, convince yourself that Return-Path is absent. Wietse
Re: chroot defaults (was: fatal: no SASL authentication mechanisms)
On 01/18/15 10:57, Wietse Venema wrote: better make a bugreport at your distribution https://www.google.at/search?q=postfix+debian+chroot+problems Scott K: Assuming this is Debian, there's no bug report needed. It's an intentional maintainer choice and not a bug. Edgar Pettijohn: I think its default in a lot of distros. I know it is in openbsd and I'm pretty sure freebsd also. With the upcoming stable release(*), the built-in chroot is no by default. However, a built-in backwards-compatibility safety net will preserve past Postfix behavior, so if the maintainers get it right, then you get to decide if you like the new defaults, not the maintainers. http://www.postfix.org/COMPATIBILITY_README.html *I expect to issue release candidates in a week or so. Wietse Thanks everyone that replied, It seems to work reliably now.
Re: SPF configurations
Am 18.01.2015 um 15:20 schrieb SW post...@bsdpanic.com: policyd-spf unix - n n - 0 spawn user=nobody argv=/usr/local/bin/policyd-spf I use this: policyd-spf unix -n n - 0 spawn user=nobody argv=/usr/bin/policyd-spf /etc/python-policyd-spf/policyd-spf.conf Maybe the configuration file is not used. So you might specify it like I did (with the correct paths from your system) Christian -- Bachelor of Science Informatik Erlenwiese 14, 36304 Alsfeld T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345 USt-IdNr.: DE225643613, http://www.roessner-network-solutions.com signature.asc Description: Message signed with OpenPGP using GPGMail
Re: SPF configurations
Thanks for the suggestion but I have just tried what you mentioned but still same error in the headers: Received-SPF: Temperror (SPF Temporary Error: DNS Timeout) identity=mailfrom; client-ip=209.85.216.182; -- View this message in context: http://postfix.1071664.n5.nabble.com/SPF-configurations-tp73872p73905.html Sent from the Postfix Users mailing list archive at Nabble.com.
Re: Altering content and/or headers depending on forward connection
Back from travelling... On 12 Jan 2015, at 12:00 pm, Wietse Venema wie...@porcupine.org wrote: Mark Nottingham: Hi, I?d like to insert SMTP headers and/or body content (e.g., using alterMIME) in outgoing e-mails *if* the SMTP connection to the recipient is not protected by TLS. Is this possible in postfix today, or would it require a change to source? No, you add the headers with a policy daemon, a Milter, or with an SMTP-based content filter. With a policy daemon in smtpd_data_restrictions, use the PREPEND action to add a header when the encryption_protocol, encryption_cipher or encryption_keysize attributes are empty. postfwd might have all that you need. Milters are available in Python, Perl, C, Java, and probably more languages. Just look at your Postfix's Received: header, assuming that you have smtpd_tls_received_header = yes. You may also be interested in smtpd_sasl_authenticated_header = yes. Just to check here -- I'm interested in doing this for e-mail that I send to others -- i.e., when Postfix is operating as an SMTP client, not server. The purpose is to inform recipients when their mail server doesn't support TLS for incoming e-mail (by modifying message content). smtpd_tls_received_header appears to record the state of incoming connections -- i.e., those in which it is acting as a server. I effectively need a milter to run on outgoing e-mail when the connection is open, not beforehand. Cheers, -- Mark Nottingham https://www.mnot.net/
Re: custom script adds header
m...@ruggedinbox.com:
Ok the new rule is:
spamassassin unix - n n - - pipe
user=debian-spamd argv=/usr/bin/spamc -e /usr/sbin/sendmail -oi -f -G
${sender} -- ${recipient}
You can't put -G between -f and sender. I assumed that you would be
familiar with the way UNIX command-line syntax works, but I must
have been too optimistic.
did a postfix restart (of course) and sent a test email:
There is no such thing as postfix restart. In other words,
Postfix keeps using the old configuration.
If you had done postfix reload with -G between -f and sender,
then the return-path would contain -G, not vm...@ruggedinbox.com.
This demonstrates again that all the changes you're making are
having zero effect. The biggest problem here is between the chair
and the keyboard. Good luck.
Wietse
Re: custom script adds header
On 19.01.2015. 0:01, Wietse Venema wrote: m...@ruggedinbox.com: did a postfix restart (of course) and sent a test email: There is no such thing as postfix restart. In other words, Postfix keeps using the old configuration. Wietse Probably ML used init.d script restart facility, which makes stopstart. -- KSB
Re: custom script adds header
On 2015-01-18 22:17, KSB wrote: On 19.01.2015. 0:01, Wietse Venema wrote: m...@ruggedinbox.com: did a postfix restart (of course) and sent a test email: There is no such thing as postfix restart. In other words, Postfix keeps using the old configuration. Wietse Probably ML used init.d script restart facility, which makes stopstart. -- KSB Yep, true. RuggedInbox team
Re: custom script adds header
On 2015-01-18 22:01, wie...@porcupine.org wrote:
m...@ruggedinbox.com:
Ok the new rule is:
spamassassin unix - n n - - pipe
user=debian-spamd argv=/usr/bin/spamc -e /usr/sbin/sendmail -oi -f
-G
${sender} -- ${recipient}
You can't put -G between -f and sender. I assumed that you would be
familiar with the way UNIX command-line syntax works, but I must
have been too optimistic.
did a postfix restart (of course) and sent a test email:
There is no such thing as postfix restart. In other words,
Postfix keeps using the old configuration.
If you had done postfix reload with -G between -f and sender,
then the return-path would contain -G, not vm...@ruggedinbox.com.
This demonstrates again that all the changes you're making are
having zero effect. The biggest problem here is between the chair
and the keyboard. Good luck.
Wietse
Ok new spamassassin rule:
spamassassin unix - n n - - pipe
user=debian-spamd argv=/usr/bin/spamc -e /usr/sbin/sendmail -oi -G -f
${sender} -- ${recipient}
did an /etc/init.d/postfix reload
and ensured about it:
Jan 18 23:22:23 ruggedinbox postfix/master[24779]: reload -- version
2.9.6, configuration /etc/postfix
sent a test email:
Return-Path: vm...@ruggedinbox.com
Delivered-To: m...@ruggedinbox.com
Received: from localhost (localhost.localdomain [127.0.0.1])
by ruggedinbox.com (Postfix) with ESMTP id 7693331405C7
for m...@ruggedinbox.com; Sun, 18 Jan 2015 23:23:03 +0100 (CET)
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level:
X-Spam-Status: No, score=-0.002 required=5 tests=[NO_RECEIVED=-0.001,
NO_RELAYS=-0.001] autolearn=no
Received: from ruggedinbox.com ([127.0.0.1])
by localhost (ruggedinbox.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id y_8qU3bCUyh9 for m...@ruggedinbox.com;
Sun, 18 Jan 2015 23:23:01 +0100 (CET)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Sun, 18 Jan 2015 22:23:01 +
From: m...@ruggedinbox.com
To: m...@ruggedinbox.com
Subject: test3
Message-ID: 4cbb98dd59ce89a54078d25049815...@ruggedinbox.com
X-Sender: m...@ruggedinbox.com
test3
and the header is still there.
Re: custom script adds header
On 2015-01-18 20:48, wie...@porcupine.org wrote:
m...@ruggedinbox.com:
spamassassin unix - n n - - pipe
flags=R user=debian-spamd argv=/usr/bin/spamc -e /usr/sbin/sendmail
-oi -f
${sender} ${recipient}
This is not final delivery, don't use R here. And don't forget --
before the recipient list.
...
About the spamassassin rule, you mean that the correct definition
should
be
spamassassin unix - n n - - pipe
user=debian-spamd
argv=/usr/bin/spamc -e /usr/sbin/sendmail -oi -f ${sender} --
${recipient}
This is better, without R flags and with -- before the recipients.
The Postfix FILTER_README also recommends the sendmail -G option,
which prevents Postfix from appending your domain to broken email
addresses in email headers.
Wietse
Hi ok applied the suggested changes:
spamassassin unix - n n - - pipe
flags=G user=debian-spamd argv=/usr/bin/spamc -e /usr/sbin/sendmail
-oi -f ${sender} -- ${recipient}
and tried to send a test email, 'Return-Path' is still there:
Return-Path: vm...@ruggedinbox.com
Delivered-To: m...@ruggedinbox.com
Received: from localhost (localhost.localdomain [127.0.0.1])
by ruggedinbox.com (Postfix) with ESMTP id 9B31B31405C7
for m...@ruggedinbox.com; Sun, 18 Jan 2015 22:08:23 +0100 (CET)
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level:
X-Spam-Status: No, score=-0.002 required=5 tests=[NO_RECEIVED=-0.001,
NO_RELAYS=-0.001] autolearn=no
Received: from ruggedinbox.com ([127.0.0.1])
by localhost (ruggedinbox.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 4aYR2P5tCjvr for m...@ruggedinbox.com;
Sun, 18 Jan 2015 22:08:21 +0100 (CET)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Sun, 18 Jan 2015 21:08:18 +
From: m...@ruggedinbox.com
To: m...@ruggedinbox.com
Subject: test1
Message-ID: 78f9184e7cbad3872c7b3523d8189...@ruggedinbox.com
X-Sender: m...@ruggedinbox.com
test1
Thank you.
Re: custom script adds header
On 2015-01-18 21:17, wie...@porcupine.org wrote:
m...@ruggedinbox.com:
spamassassin unix - n n - - pipe
user=debian-spamd
argv=/usr/bin/spamc -e /usr/sbin/sendmail -oi -f ${sender} --
${recipient}
This is better, without R flags and with -- before the recipients.
The Postfix FILTER_README also recommends the sendmail -G option,
which prevents Postfix from appending your domain to broken email
addresses in email headers.
Wietse
Hi ok applied the suggested changes:
spamassassin unix - n n - - pipe
flags=G user=debian-spamd argv=/usr/bin/spamc -e /usr/sbin/sendmail
-oi -f ${sender} -- ${recipient}
I SAID SENDMAIL -G OPTION NOT PIPE G FLAG.
and tried to send a test email, 'Return-Path' is still there:
Of course it is. You did not execute postfix reload.
Wietse
Ok the new rule is:
spamassassin unix - n n - - pipe
user=debian-spamd argv=/usr/bin/spamc -e /usr/sbin/sendmail -oi -f -G
${sender} -- ${recipient}
did a postfix restart (of course) and sent a test email:
Return-Path: vm...@ruggedinbox.com
Delivered-To: m...@ruggedinbox.com
Received: from localhost (localhost.localdomain [127.0.0.1])
by ruggedinbox.com (Postfix) with ESMTP id 87D4731405CA
for m...@ruggedinbox.com; Sun, 18 Jan 2015 22:25:41 +0100 (CET)
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level:
X-Spam-Status: No, score=-0.002 required=5 tests=[NO_RECEIVED=-0.001,
NO_RELAYS=-0.001] autolearn=no
Received: from ruggedinbox.com ([127.0.0.1])
by localhost (ruggedinbox.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id XVXTFibwS3gk for m...@ruggedinbox.com;
Sun, 18 Jan 2015 22:25:39 +0100 (CET)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Sun, 18 Jan 2015 21:25:39 +
From: m...@ruggedinbox.com
To: m...@ruggedinbox.com
Subject: test2
Message-ID: 7e747ecd8d7c92e086e382307c80a...@ruggedinbox.com
X-Sender: m...@ruggedinbox.com
test2
header still there :)
Re: SPF configurations
Fair enough. Thanks Wietse. I have done plenty of research online regarding this but still haven't had much luck. I will contact the developer. Thanks everyone for the assistance. -- View this message in context: http://postfix.1071664.n5.nabble.com/SPF-configurations-tp73872p73902.html Sent from the Postfix Users mailing list archive at Nabble.com.
Re: custom script adds header
On 2015-01-18 19:53, Viktor Dukhovni wrote:
On Sun, Jan 18, 2015 at 07:41:15PM +, m...@ruggedinbox.com wrote:
Hi ok we double checked and this is the source of an email sent from
m...@ruggedinbox.com to m...@ruggedinbox.com:
Return-Path: vm...@ruggedinbox.com
Delivered-To: m...@ruggedinbox.com
[...]
so it looks like 'Return-Path: vm...@ruggedinbox.com' is added.
We have some 'R' flag enabled in master.cf:
dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d
${recipient}
Why do you believe that adding Return-Path on final delivery is a
problem? It is rather a requirement IMHO.
spamassassin unix - n n - - pipe
flags=R user=debian-spamd argv=/usr/bin/spamc -e /usr/sbin/sendmail
-oi -f
${sender} ${recipient}
do you think the problem is here ?
This is not final delivery, don't use R here. And don't forget --
before the recipient list.
spamassassin unix - n n - - pipe
flags=R user=debian-spamd
argv=/usr/bin/spamc -e /usr/sbin/sendmail -oi -f ${sender} --
${recipient}
Postfix does its best to protect you with:
http://www.postfix.org/postconf.5.html#allow_min_user
but it is best to not rely on that too much.
That Return-Path header causes problems with some services, for example
ebay, which uses 'vm...@ruggedinbox.com' instead of the sender address.
It also causes problems when delivery is failed, the returning email
with the error is sometime sent to vm...@ruggedinbox.com instead of the
sender address.
About the spamassassin rule, you mean that the correct definition should
be
spamassassin unix - n n - - pipe
user=debian-spamd
argv=/usr/bin/spamc -e /usr/sbin/sendmail -oi -f ${sender} --
${recipient}
?
Re: custom script adds header
m...@ruggedinbox.com:
spamassassin unix - n n - - pipe
flags=R user=debian-spamd argv=/usr/bin/spamc -e /usr/sbin/sendmail
-oi -f
${sender} ${recipient}
This is not final delivery, don't use R here. And don't forget --
before the recipient list.
...
About the spamassassin rule, you mean that the correct definition should
be
spamassassin unix - n n - - pipe
user=debian-spamd
argv=/usr/bin/spamc -e /usr/sbin/sendmail -oi -f ${sender} --
${recipient}
This is better, without R flags and with -- before the recipients.
The Postfix FILTER_README also recommends the sendmail -G option,
which prevents Postfix from appending your domain to broken email
addresses in email headers.
Wietse
Re: SPF configurations
I have contacted the port maintaner but he couldn't help. Can anyone else assist please? -- View this message in context: http://postfix.1071664.n5.nabble.com/SPF-configurations-tp73872p73898.html Sent from the Postfix Users mailing list archive at Nabble.com.
Re: SPF configurations
SW: I have contacted the port maintaner but he couldn't help. Can anyone else assist please? I am pretty certain that policyd-spf does not use Postfix to make its DNS queries. Therefore, some other mailing list will be more appropriate. A quick search on the web shows that your problem is not unique. Wietse
Re: custom script adds header
m...@ruggedinbox.com:
spamassassin unix - n n - - pipe
user=debian-spamd
argv=/usr/bin/spamc -e /usr/sbin/sendmail -oi -f ${sender} --
${recipient}
This is better, without R flags and with -- before the recipients.
The Postfix FILTER_README also recommends the sendmail -G option,
which prevents Postfix from appending your domain to broken email
addresses in email headers.
Wietse
Hi ok applied the suggested changes:
spamassassin unix - n n - - pipe
flags=G user=debian-spamd argv=/usr/bin/spamc -e /usr/sbin/sendmail
-oi -f ${sender} -- ${recipient}
I SAID SENDMAIL -G OPTION NOT PIPE G FLAG.
and tried to send a test email, 'Return-Path' is still there:
Of course it is. You did not execute postfix reload.
Wietse
