Re: "smtp_sasl_auth_enable = yes" for specific peers only?
Hi Viktor, thank you very much, you gave me the right hint! In the past, when we had a dynamic ip, we used the gmail relays for sending mail from the local domains (those relays can be authorized to send for any domain or email address). I've commented these lines in the sender_dependent file later when we got a static ip, but in the sasl_passwd file the login credentials for the google relays were still present. So, when Postfix got AUTH from the peer, it tried to authenticate with the gmail credentials, which of course failed. Solved, thanks! Cheers, Robert Am Dienstag, den 05.05.2015, 23:22 + schrieb Viktor Dukhovni: > On Tue, May 05, 2015 at 10:22:42PM +0200, Robert Senger wrote: > > > I am having trouble sending mail to a specific smtp host, which is > > configured for sasl authentication on port 25. > > This should have no impact on your machine, unless you also configure > smtp_sasl_password_maps non-empty, and configure a table entry that > matches the nexthop domain (the smtp host in question). > > > I have configured Postfix to send smtp mail from a small number of local > > domains to the recipient domain's mail exchanger, and to send mail from > > non local domains such as gmx.de and gmail.com via the appropriate > > relays using sender_dependent lists. All worked fine until today. > > If you do configure sender-dependent SASL authentication, then you > MUST either ensure that all outbound mail from the sender in question > goes through the expected relay (for which the sender has credentials), > via sender_dependent_relayhost_maps, or via a different transport > via sender_dependent_default_transport_maps, so that you never > connect to some other relay expecting to authenticate because you've > configured a sender-specific SASL password. > > > The peer that causes trouble is using sasl authentication on port 25, to > > allow authenticated users sending mail via smtp instead of submission. > > The trouble is not the peer. It is your server's misconfiguration. > Postfix happily ignores remote "AUTH" by default, unless you've > configured a password for the destination or the sender. > > > So, my own Postfix tries to authenticate to this server, but of course > > fails as it does not have any credentials. > > It does, for the sender. > > > I see that this seems to be caused by the smtp_sasl_auth_enable = yes > > flag set in main.cf, which I need because without this, Postfix will > > never try to authenticate to the sender_dependent relays, e.g. for > > gmail.com. > > No, that's not the reason. Even with that on, authentication only > happens to destinations (or for senders) for which you've set a > password. > > > I don't know what to do about this, is there a way to tell Postfix to > > only authenticate to those relays defined in sender_dependent, or only > > when connecting to the submission port? > > > > Or can this be a misconfiguration at the peer's side? > > Misconfiguration on your side. > -- Robert Senger PGP/GPG Public Key ID: 24E78B5E signature.asc Description: This is a digitally signed message part
postfix-policyd-spf-perl and troubles with Amazon?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi list I know it's technically not a postfix issue :-) But maybe someone else here on this list has the same problem. I'm using Postfix with postfix-policyd-spf-perl About 4 or 5 days ago I started to get error messages from postfix for mails from Amazon. The log shows << May 6 15:33:12 mail1 postfix/policy-spf[10692]: Policy action=DEFER_IF_PERMIT SPF-Result=marketplace.amazon.de ... spf1.amazon.com: Unknown error on DNS 'TXT' lookup of 'spf1.amazon.com' May 6 15:33:12 mail1 postfix/smtpd[10069]: NOQUEUE: reject: RCPT from a0-3.smtp-out.eu-west-1.amazonses.com[54.240.0.3]: 450 4.7.1 : Recipient address rejected: SPF-Result=marketplace.amazon.de ... spf1.amazon.com: Unknown error on DNS 'TXT' lookup of 'spf1.amazon.com'; from= to= proto=ESMTP helo= May 6 15:33:37 mail1 postfix/smtpd[10069]: disconnect from a0-3.smtp-out.eu-west-1.amazonses.com[54.240.0.3] >> I did not change anything on the server side. I tried to verify the SPF records from Amazon with http://www.kitterman.com/spf/validate.html but the tests were always successfull. Does anyone have this problem too with Amazon? Or does anyone have an idea how to solve it? Thanks tobi -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVShrmAAoJEDUc5iWoaKTkd7kP/RxLTO0uzrxcPg348cnm9yjG l2fIodQqvyRG2BgloKd3ldseVhc5B1+f/Ee+xFiofjMI5KSMYf9UbiH2cmmbfBZq /AyZesUwwDUsHWHw6vhY9DwXP/QjHLLpUOsiY0iyQsH2sesOneSYYp0W1ZHmDcOU CRF07QgduCOHNsHueEsw8BF+RqluXIwklJ83hXZBziTBT0PR0QvF9ZW/TxI3n+Sg Pkijo5e/l48efvykZffJjl6qMC22twS42hCHCnHbZujjg7vaSvyTGaVGzfuEGRUn z3qCe0ISDKM2QyB2ljXmCITwWT5tt/2rdkA5UV/ENHpl5g66y0aMV7sJP9Hd7QBG l2UeuLMtiq3IMy+Banc30ZiBq/Id0IdpkidHzn+3kgxP9SDf4VBvXJpSozz8i/BN ASvggyeRno08tcqBBgysX7FXn+m1s3KGYfWNWrrWe4061Fh2gcLw3zgrE1CyO9OH 9uS3jeD5EiMQYfQ9vb5ZHhBWz7BbA1TC3KQg7wP7nuGIeKqAUL821PX38xKoMiva lTVtx5IRqMfh8gDuVf6umO1BnUpx8ttc5hPd2HGPRyD5d+lZhP7FBrjaFPwf7UHe w0wyAFQXVzo2vGImq2GReZE/Em88NNvHqNcbKgNcDWLe+35v/Rm1W+83PD+slumB gSvSt8ODswf8UjbrWbbp =2Xb7 -END PGP SIGNATURE-
Re: postfix-policyd-spf-perl and troubles with Amazon?
On Wed, May 6, 2015 09:45, Tobi wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi list > > I know it's technically not a postfix issue :-) But maybe someone else > here on this list has the same problem. > I'm using Postfix with postfix-policyd-spf-perl About 4 or 5 days ago > I started to get error messages from postfix for mails from Amazon. > The log shows > > << > May 6 15:33:12 mail1 postfix/policy-spf[10692]: Policy > action=DEFER_IF_PERMIT SPF-Result=marketplace.amazon.de ... > spf1.amazon.com: Unknown error on DNS 'TXT' lookup of > 'spf1.amazon.com' > May 6 15:33:12 mail1 postfix/smtpd[10069]: NOQUEUE: reject: RCPT from > a0-3.smtp-out.eu-west-1.amazonses.com[54.240.0.3]: 450 4.7.1 > : Recipient address rejected: > SPF-Result=marketplace.amazon.de ... spf1.amazon.com: Unknown error on > DNS 'TXT' lookup of 'spf1.amazon.com'; > from= > to= proto=ESMTP > helo= > May 6 15:33:37 mail1 postfix/smtpd[10069]: disconnect from > a0-3.smtp-out.eu-west-1.amazonses.com[54.240.0.3] >>> > > I did not change anything on the server side. I tried to verify the > SPF records from Amazon with > http://www.kitterman.com/spf/validate.html but the tests were always > successfull. > Does anyone have this problem too with Amazon? Or does anyone have an > idea how to solve it? > > Thanks > dig spf1.amazon.com TXT ;; ANSWER SECTION: spf1.amazon.com.900 IN TXT "spf2.0/pra ip4:207.171.160.0/19 ip4:87.238.80.0/21 ip4:72.21.192.0/19 ip4:194.154.193.192/27 ip4:194.7.41.152/28 ip4:212.123.28.40/32 ip4:203.81.17.0/24 ip4:72.21.212.0/25 ip4:178.236.10.128/26 -all" spf1.amazon.com.900 IN TXT "v=spf1 ip4:207.171.160.0/19 ip4:87.238.80.0/21 ip4:72.21.192.0/19 ip4:194.154.193.192/27 ip4:194.7.41.152/28 ip4:212.123.28.40/32 ip4:203.81.17.0/24 ip4:72.21.212.0/25 ip4:178.236.10.128/26 -all" Amazon has screwed up their spf records. A DNS host can have only ONE spf TXT RR and that must not contain or recursively resolve to more than TEN tags. You will have to contact the DNS maintainer for the amazon.com zone ;; AUTHORITY SECTION: amazon.com. 60 IN SOA dns-external-master.amazon.com. root.amazon.com. 2010112764 180 60 3024000 60 Who evidently is reached via r...@amazon.com. Good luck with that. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: postfix-policyd-spf-perl and troubles with Amazon?
On Wednesday, May 06, 2015 09:58:57 AM James B. Byrne wrote: > On Wed, May 6, 2015 09:45, Tobi wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Hi list > > > > I know it's technically not a postfix issue :-) But maybe someone else > > here on this list has the same problem. > > I'm using Postfix with postfix-policyd-spf-perl About 4 or 5 days ago > > I started to get error messages from postfix for mails from Amazon. > > The log shows > > > > << > > May 6 15:33:12 mail1 postfix/policy-spf[10692]: Policy > > action=DEFER_IF_PERMIT SPF-Result=marketplace.amazon.de ... > > spf1.amazon.com: Unknown error on DNS 'TXT' lookup of > > 'spf1.amazon.com' > > May 6 15:33:12 mail1 postfix/smtpd[10069]: NOQUEUE: reject: RCPT from > > a0-3.smtp-out.eu-west-1.amazonses.com[54.240.0.3]: 450 4.7.1 > > : Recipient address rejected: > > SPF-Result=marketplace.amazon.de ... spf1.amazon.com: Unknown error on > > DNS 'TXT' lookup of 'spf1.amazon.com'; > > from= > > to= proto=ESMTP > > helo= > > May 6 15:33:37 mail1 postfix/smtpd[10069]: disconnect from > > a0-3.smtp-out.eu-west-1.amazonses.com[54.240.0.3] > > > > > > I did not change anything on the server side. I tried to verify the > > SPF records from Amazon with > > http://www.kitterman.com/spf/validate.html but the tests were always > > successfull. > > Does anyone have this problem too with Amazon? Or does anyone have an > > idea how to solve it? > > > > Thanks > > dig spf1.amazon.com TXT > > ;; ANSWER SECTION: > spf1.amazon.com. 900 IN TXT "spf2.0/pra ip4:207.171.160.0/19 > ip4:87.238.80.0/21 ip4:72.21.192.0/19 ip4:194.154.193.192/27 > ip4:194.7.41.152/28 ip4:212.123.28.40/32 ip4:203.81.17.0/24 > ip4:72.21.212.0/25 ip4:178.236.10.128/26 -all" > spf1.amazon.com. 900 IN TXT "v=spf1 ip4:207.171.160.0/19 > ip4:87.238.80.0/21 ip4:72.21.192.0/19 ip4:194.154.193.192/27 > ip4:194.7.41.152/28 ip4:212.123.28.40/32 ip4:203.81.17.0/24 > ip4:72.21.212.0/25 ip4:178.236.10.128/26 -all" > > Amazon has screwed up their spf records. A DNS host can have only ONE > spf TXT RR and that must not contain or recursively resolve to more > than TEN tags. > > You will have to contact the DNS maintainer for the amazon.com zone > > ;; AUTHORITY SECTION: > amazon.com. 60 IN SOA dns-external-master.amazon.com. > root.amazon.com. 2010112764 180 60 3024000 60 > > Who evidently is reached via r...@amazon.com. Good luck with that. No. That's not it. One of those is a v=spf1 SPF record and the other is a spf2.0 Sender ID record. Much more likely the issue is the use of EDNS0. In the part of the dig output you didn't include, you probably got: ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 and ;; MSG SIZE rcvd: 611 I would guess that they published a new record that pushed them outside the size of a UDP packet, so it used EDNS0, and there's some incompatible box in the middle (and there wasn't such a box similarly in between amazon and my SPF validator). Followups should probably go to: https://answers.launchpad.net/postfix-policyd-spf-perl Scott K
Re: Stan Hoeppner's fqrdns.pcre file?
On Tue, May 5, 2015 at 11:38 AM, Vijay Rajah wrote: > There was a missing persons report on a Stanley D Hoeppner. This name no > longer appears on the active missing persons list. Hope he is ok. FYI: > http://i.imgur.com/3oiR3ID.png That's VERY concerning. He is from Missouri, so I think that is indeed him. I hope the fact that he's no longer on there doesn't mean the worst... > Also, It seems that his server is up and running. there is a single jpg > file with you point the browser to his server IP. > The fqrdns.pcre file is at http://65.41.216.221/fqrdns.pcre Thanks, Vijay. I've confirmed that the 10/2/2014 version there is the same as the one I stored on GitHub. His domain must have expired and got snapped up, but his server is still active. Steve J
Re: postfix-policyd-spf-perl and troubles with Amazon?
On Wed, May 6, 2015 10:11, Scott Kitterman wrote: > On Wednesday, May 06, 2015 09:58:57 AM James B. Byrne wrote: >> >> Amazon has screwed up their spf records. A DNS host can have only >> ONE spf TXT RR and that must not contain or recursively resolve to >> more than TEN tags. > > No. That's not it. One of those is a v=spf1 SPF record and the other > is a spf2.0 Sender ID record. > > Much more likely the issue is the use of EDNS0. In the part of the > dig output you didn't include, you probably got: > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > > and > > ;; MSG SIZE rcvd: 611 Actually, no. I got this: ;; ANSWER SECTION: spf1.amazon.com.900 IN TXT "spf2.0/pra ip4:207.171.160.0/19 ip4:87.238.80.0/21 ip4:72.21.192.0/19 ip4:194.154.193.192/27 ip4:194.7.41.152/28 ip4:212.123.28.40/32 ip4:203.81.17.0/24 ip4:72.21.212.0/25 ip4:178.236.10.128/26 -all" spf1.amazon.com.900 IN TXT "v=spf1 ip4:207.171.160.0/19 ip4:87.238.80.0/21 ip4:72.21.192.0/19 ip4:194.154.193.192/27 ip4:194.7.41.152/28 ip4:212.123.28.40/32 ip4:203.81.17.0/24 ip4:72.21.212.0/25 ip4:178.236.10.128/26 -all" ;; AUTHORITY SECTION: amazon.com. 2751IN NS ns3.p31.dynect.net. amazon.com. 2751IN NS ns1.p31.dynect.net. amazon.com. 2751IN NS ns4.p31.dynect.net. amazon.com. 2751IN NS ns2.p31.dynect.net. amazon.com. 2751IN NS pdns6.ultradns.co.uk. amazon.com. 2751IN NS pdns1.ultradns.net. ;; Query time: 1 msec ;; SERVER: 216.185.71.33#53(216.185.71.33) ;; WHEN: Wed May 6 09:54:00 2015 ;; MSG SIZE rcvd: 600 And thanks for the correction. I had never run into MS's Sender ID in the wild before and had no recollection of its existence until you reminded me. One more thing to look for. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail 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: Stan Hoeppner's fqrdns.pcre file?
On 6 May 2015, at 10:20, Steve Jenkins wrote: On Tue, May 5, 2015 at 11:38 AM, Vijay Rajah wrote: There was a missing persons report on a Stanley D Hoeppner. This name no longer appears on the active missing persons list. Hope he is ok. FYI: http://i.imgur.com/3oiR3ID.png That's VERY concerning. He is from Missouri, so I think that is indeed him. I hope the fact that he's no longer on there doesn't mean the worst... It would seem that it does not, and that in fact his location is under the capable control of the penal authorities of Los Angeles County California. I found the matching name last week but was dubious that it was him. Feeding suitable search terms to http://app4.lasd.org/iic/ajis_search.cfm (a site that seems to put a captcha on every link) and http://www.lacourt.org reveal that he has a 2nd pretrial hearing about 10 minutes from now. And that's the last I'll post on Stan Hoeppner. I don't expect we'll be seeing him back here soon.
Re: postfix-policyd-spf-perl and troubles with Amazon? [SOLVED]
@Scott thanks for putting me into the right direction :-) The answer for spf1.amazon.com TXT is indeed too big for UDP. So the query was retried in TCP mode. But the stupid admin (aka myself) forgot that he disabled tcp on the mailservers local resolvers (unbound). After enabling tcp mode for unbound the queries for spf1.amazon.com TXT were properly answered properly. Amazon did not retry yet, but I'm sure that this solved the problem. Thanks a iot tobi Am 06.05.2015 um 16:11 schrieb Scott Kitterman: On Wednesday, May 06, 2015 09:58:57 AM James B. Byrne wrote: On Wed, May 6, 2015 09:45, Tobi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi list I know it's technically not a postfix issue :-) But maybe someone else here on this list has the same problem. I'm using Postfix with postfix-policyd-spf-perl About 4 or 5 days ago I started to get error messages from postfix for mails from Amazon. The log shows << May 6 15:33:12 mail1 postfix/policy-spf[10692]: Policy action=DEFER_IF_PERMIT SPF-Result=marketplace.amazon.de ... spf1.amazon.com: Unknown error on DNS 'TXT' lookup of 'spf1.amazon.com' May 6 15:33:12 mail1 postfix/smtpd[10069]: NOQUEUE: reject: RCPT from a0-3.smtp-out.eu-west-1.amazonses.com[54.240.0.3]: 450 4.7.1 : Recipient address rejected: SPF-Result=marketplace.amazon.de ... spf1.amazon.com: Unknown error on DNS 'TXT' lookup of 'spf1.amazon.com'; from= to= proto=ESMTP helo= May 6 15:33:37 mail1 postfix/smtpd[10069]: disconnect from a0-3.smtp-out.eu-west-1.amazonses.com[54.240.0.3] I did not change anything on the server side. I tried to verify the SPF records from Amazon with http://www.kitterman.com/spf/validate.html but the tests were always successfull. Does anyone have this problem too with Amazon? Or does anyone have an idea how to solve it? Thanks dig spf1.amazon.com TXT ;; ANSWER SECTION: spf1.amazon.com.900 IN TXT "spf2.0/pra ip4:207.171.160.0/19 ip4:87.238.80.0/21 ip4:72.21.192.0/19 ip4:194.154.193.192/27 ip4:194.7.41.152/28 ip4:212.123.28.40/32 ip4:203.81.17.0/24 ip4:72.21.212.0/25 ip4:178.236.10.128/26 -all" spf1.amazon.com.900 IN TXT "v=spf1 ip4:207.171.160.0/19 ip4:87.238.80.0/21 ip4:72.21.192.0/19 ip4:194.154.193.192/27 ip4:194.7.41.152/28 ip4:212.123.28.40/32 ip4:203.81.17.0/24 ip4:72.21.212.0/25 ip4:178.236.10.128/26 -all" Amazon has screwed up their spf records. A DNS host can have only ONE spf TXT RR and that must not contain or recursively resolve to more than TEN tags. You will have to contact the DNS maintainer for the amazon.com zone ;; AUTHORITY SECTION: amazon.com. 60 IN SOA dns-external-master.amazon.com. root.amazon.com. 2010112764 180 60 3024000 60 Who evidently is reached via r...@amazon.com. Good luck with that. No. That's not it. One of those is a v=spf1 SPF record and the other is a spf2.0 Sender ID record. Much more likely the issue is the use of EDNS0. In the part of the dig output you didn't include, you probably got: ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 and ;; MSG SIZE rcvd: 611 I would guess that they published a new record that pushed them outside the size of a UDP packet, so it used EDNS0, and there's some incompatible box in the middle (and there wasn't such a box similarly in between amazon and my SPF validator). Followups should probably go to: https://answers.launchpad.net/postfix-policyd-spf-perl Scott K
Re: Stan Hoeppner's fqrdns.pcre file?
I have it on good authority that he is still in Missouri but is absent due to a personal nature. I will share more if allowed in time. In the interim, I've been checking to see if I can get his domain back up for everyone again. Thanks, Steffan > On May 6, 2015, at 8:21 AM, Bill Cole > wrote: > >> On 6 May 2015, at 10:20, Steve Jenkins wrote: >> >>> On Tue, May 5, 2015 at 11:38 AM, Vijay Rajah wrote: >>> >>> There was a missing persons report on a Stanley D Hoeppner. This name no >>> longer appears on the active missing persons list. Hope he is ok. FYI: >>> http://i.imgur.com/3oiR3ID.png >> >> >> That's VERY concerning. He is from Missouri, so I think that is indeed him. >> I hope the fact that he's no longer on there doesn't mean the worst... > > It would seem that it does not, and that in fact his location is under the > capable control of the penal authorities of Los Angeles County California. I > found the matching name last week but was dubious that it was him. Feeding > suitable search terms to http://app4.lasd.org/iic/ajis_search.cfm (a site > that seems to put a captcha on every link) and http://www.lacourt.org reveal > that he has a 2nd pretrial hearing about 10 minutes from now. > > And that's the last I'll post on Stan Hoeppner. I don't expect we'll be > seeing him back here soon. > On 6 May 2015, at 10:20, Steve Jenkins wrote: > On Tue, May 5, 2015 at 11:38 AM, Vijay Rajah wrote: > >> There was a missing persons report on a Stanley D Hoeppner. This name >> no >> longer appears on the active missing persons list. Hope he is ok. >> FYI: >> http://i.imgur.com/3oiR3ID.png > > > That's VERY concerning. He is from Missouri, so I think that is indeed > him. > I hope the fact that he's no longer on there doesn't mean the worst... It would seem that it does not, and that in fact his location is under the capable control of the penal authorities of Los Angeles County California. I found the matching name last week but was dubious that it was him. Feeding suitable search terms to http://app4.lasd.org/iic/ajis_search.cfm (a site that seems to put a captcha on every link) and http://www.lacourt.org reveal that he has a 2nd pretrial hearing about 10 minutes from now. And that's the last I'll post on Stan Hoeppner. I don't expect we'll be seeing him back here soon.
Re: Stan Hoeppner's fqrdns.pcre file?
On Wed, May 6, 2015 at 8:21 AM, Bill Cole < postfixlists-070...@billmail.scconsult.com> wrote: > On 6 May 2015, at 10:20, Steve Jenkins wrote: > > On Tue, May 5, 2015 at 11:38 AM, Vijay Rajah wrote: >> >> There was a missing persons report on a Stanley D Hoeppner. This name no >>> longer appears on the active missing persons list. Hope he is ok. FYI: >>> http://i.imgur.com/3oiR3ID.png >>> >> >> >> That's VERY concerning. He is from Missouri, so I think that is indeed >> him. >> I hope the fact that he's no longer on there doesn't mean the worst... >> > > It would seem that it does not, and that in fact his location is under the > capable control of the penal authorities of Los Angeles County California. > I found the matching name last week but was dubious that it was him. > Feeding suitable search terms to http://app4.lasd.org/iic/ajis_search.cfm > (a site that seems to put a captcha on every link) and > http://www.lacourt.org reveal that he has a 2nd pretrial hearing about 10 > minutes from now. > > And that's the last I'll post on Stan Hoeppner. I don't expect we'll be > seeing him back here soon. > Thanks, Bill. Now I feel REALLY bad for even bringing it up, but will admit that I'm glad the mystery is solved. I'm even more glad that Stan is not missing... or worse. Beyond that, whatever other issues may be facing him are his personal business, and I hope nothing but the best for him. SteveJ
Re: postfix-policyd-spf-perl and troubles with Amazon? [SOLVED]
On Wednesday, May 06, 2015 05:17:12 PM Tobi wrote: > @Scott > > thanks for putting me into the right direction :-) > The answer for spf1.amazon.com TXT is indeed too big for UDP. So the > query was retried in TCP mode. > But the stupid admin (aka myself) forgot that he disabled tcp on the > mailservers local resolvers (unbound). After enabling tcp mode for > unbound the queries for spf1.amazon.com TXT were properly answered properly. > Amazon did not retry yet, but I'm sure that this solved the problem. > Great. Feel free to throw RFC 7208 Section 3.4 (Record Size) at them. The SHOULD fit in a UDP packet is there for a reason. Scott K
Re: postfix-policyd-spf-perl and troubles with Amazon? [SOLVED]
On Wed, 06 May 2015 13:59:44 -0400, Scott Kitterman stated: > Great. Feel free to throw RFC 7208 Section 3.4 (Record Size) at them. The > SHOULD fit in a UDP packet is there for a reason. SHOULD ≠ MUST -- Jerry
Re: postfix-policyd-spf-perl and troubles with Amazon? [SOLVED]
Once upon a time, Scott Kitterman said: > Great. Feel free to throw RFC 7208 Section 3.4 (Record Size) at them. The > SHOULD fit in a UDP packet is there for a reason. I see your RFC and raise you RFC 6891. "[f]it in a UDP packet" does not mean 512 bytes. -- Chris Adams
Re: postfix-policyd-spf-perl and troubles with Amazon? [SOLVED]
On Wednesday, May 06, 2015 02:12:04 PM Chris Adams wrote: > Once upon a time, Scott Kitterman said: > > Great. Feel free to throw RFC 7208 Section 3.4 (Record Size) at them. > > The > > SHOULD fit in a UDP packet is there for a reason. > > I see your RFC and raise you RFC 6891. "[f]it in a UDP packet" does not > mean 512 bytes. RFC 7208 is more precise in it's language them my mail here. Bottom line is if your reply goes over 512 and it breaks, you get to keep both halves. Scott K
proof-of-work principle applied to mail sending protocol(s) - spams
Dear List, I was advised to come to this list with the idea below. I apologize if this is not the right forum, in that case please point be to more appropriate list. In any case i would appreciate any feedback on the thoughts below, which I try to explain very densly and can of course eloborate in detail later in case of interest. A one liner: An idea based on the proof-of-work principle to tremendously decrease mail spam traffic. A short extract: The problem: The problem of spam mails is still existing and current solutions are trying to cure the issue on the wrong side of the problem. Despite the fact, that due to state-of-art spam filters spams are not really problems for the end user, spam mails are still generated, sent and generating malicious internet traffic. This is because a.) it is virtually free for spammers to send the mails and b.) spams are treated only after they arrived into their destination. The solution: While keeping all the good properties of open message/mail sending protocols, we need to change a.) and b.) and there is a way to do this in one step, which is the following: Let's imagine the following imaginary mail sending protocol. 1.) Sender contacts the Receiver 2.) Receiver verifies Sender's identity 3a.) If Sender identity is known to Receiver, then Receiver accepts Sender's message. 3b.) If Sender's identity not know for the Receiver then Receiver says to Sender: "I do not know You, but you can still send me a message if you solve this problem!" 4.) The Receiver gives a computational problem to the Sender which a.) can be infinitely, trivially (or parallely) generated b.) can easily be verified c.) and can be solved only serially, i.e. unparalellizable (so as to ensure that it takes more-or less the same time for everybody) d.) has a well estimable and tunable computational complexity e.) generated on the spot, has limited lifetime and used only once so as to exclude any second or aftermarket of problem solvers and mail senders 5.) If the Sender is really serious about to send the message it solves the problem, i.e. it dedicates N seconds/minutes of computational time to solve the problem and connects back the Receiver with the solution 6.) Having the solution presented to the Receiver the Receiver accepts the message, since a proof-of-work was presented. 7.) The user who reads the mail can mark Sender as 'known' so next time Sender does not have to perform calculation What follows: a.) This way anybody can contact anybody (no whitelist/blacklist) and it it only the first contact which is "painful". b.) No human labor intensive captcha solving is involved c.) No money, 3rd party, administration or any legal regularisation involved still working. d.) Since this way it becomes several order of magnitudes more expensive to spammers to contact unknown email adresses for the first time, it becomes economically unfeasible to operate and manage spamming botnets or other spamming machinery. e.) Problem requiring can be optional and problem complexity can vary from address to address. f.) Problem can be sent as a 1 liner error message inside SMTP communication g.) The idea can be implemented organically inside the SMPT protocol. h.) In this way spams are not even generated and does not generate internet traffic so spam issue is treated at the right side of the problem. There is of course many more little but important details to discuss about, this is just the brief overview of the idea. Would appreciate any feedback and/or volunteer prototype implementation in case of interest Sincerely, Gergely Debreczeni
Re: proof-of-work principle applied to mail sending protocol(s) - spams
IT do already exist: http://www.hashcash.org/ Im already using it. See this mail, you find this header: X-Hashcash: 1:26:150428:nielsen.sebast...@gmail.com::8G9E5dBe8isoyoyL:07iLtb Thats a proof-of-work system with hashcash. Im currently have a module in my outgoing mail server that generates such "hashcash" stamps with the help of a milter. Spamassassin in default config should reward such headers with a negative spam score. -Ursprungligt meddelande- From: Gergely Debreczeni Sent: Thursday, May 07, 2015 12:11 AM To: postfix-users@postfix.org Subject: proof-of-work principle applied to mail sending protocol(s) - spams Dear List, I was advised to come to this list with the idea below. I apologize if this is not the right forum, in that case please point be to more appropriate list. In any case i would appreciate any feedback on the thoughts below, which I try to explain very densly and can of course eloborate in detail later in case of interest. A one liner: An idea based on the proof-of-work principle to tremendously decrease mail spam traffic. A short extract: The problem: The problem of spam mails is still existing and current solutions are trying to cure the issue on the wrong side of the problem. Despite the fact, that due to state-of-art spam filters spams are not really problems for the end user, spam mails are still generated, sent and generating malicious internet traffic. This is because a.) it is virtually free for spammers to send the mails and b.) spams are treated only after they arrived into their destination. The solution: While keeping all the good properties of open message/mail sending protocols, we need to change a.) and b.) and there is a way to do this in one step, which is the following: Let's imagine the following imaginary mail sending protocol. 1.) Sender contacts the Receiver 2.) Receiver verifies Sender's identity 3a.) If Sender identity is known to Receiver, then Receiver accepts Sender's message. 3b.) If Sender's identity not know for the Receiver then Receiver says to Sender: "I do not know You, but you can still send me a message if you solve this problem!" 4.) The Receiver gives a computational problem to the Sender which a.) can be infinitely, trivially (or parallely) generated b.) can easily be verified c.) and can be solved only serially, i.e. unparalellizable (so as to ensure that it takes more-or less the same time for everybody) d.) has a well estimable and tunable computational complexity e.) generated on the spot, has limited lifetime and used only once so as to exclude any second or aftermarket of problem solvers and mail senders 5.) If the Sender is really serious about to send the message it solves the problem, i.e. it dedicates N seconds/minutes of computational time to solve the problem and connects back the Receiver with the solution 6.) Having the solution presented to the Receiver the Receiver accepts the message, since a proof-of-work was presented. 7.) The user who reads the mail can mark Sender as 'known' so next time Sender does not have to perform calculation What follows: a.) This way anybody can contact anybody (no whitelist/blacklist) and it it only the first contact which is "painful". b.) No human labor intensive captcha solving is involved c.) No money, 3rd party, administration or any legal regularisation involved still working. d.) Since this way it becomes several order of magnitudes more expensive to spammers to contact unknown email adresses for the first time, it becomes economically unfeasible to operate and manage spamming botnets or other spamming machinery. e.) Problem requiring can be optional and problem complexity can vary from address to address. f.) Problem can be sent as a 1 liner error message inside SMTP communication g.) The idea can be implemented organically inside the SMPT protocol. h.) In this way spams are not even generated and does not generate internet traffic so spam issue is treated at the right side of the problem. There is of course many more little but important details to discuss about, this is just the brief overview of the idea. Would appreciate any feedback and/or volunteer prototype implementation in case of interest Sincerely, Gergely Debreczeni smime.p7s Description: S/MIME Cryptographic Signature
RE: proof-of-work principle applied to mail sending protocol(s) - spams
Thank you Sebastion ! i'll check on that better ! Though, it does not solve the part of spam generation. Spams are still generated but killed on the Receiver side. If all this could be implemented on the protocol level and 'on demand' than it would work much better. Cheers, Gergely From: Sebastian Nielsen [sebast...@sebbe.eu] Sent: 07 May 2015 00:20 To: Gergely Debreczeni; postfix-users@postfix.org Subject: Re: proof-of-work principle applied to mail sending protocol(s) - spams IT do already exist: http://www.hashcash.org/ Im already using it. See this mail, you find this header: X-Hashcash: 1:26:150428:nielsen.sebast...@gmail.com::8G9E5dBe8isoyoyL:07iLtb Thats a proof-of-work system with hashcash. Im currently have a module in my outgoing mail server that generates such "hashcash" stamps with the help of a milter. Spamassassin in default config should reward such headers with a negative spam score. -Ursprungligt meddelande- From: Gergely Debreczeni Sent: Thursday, May 07, 2015 12:11 AM To: postfix-users@postfix.org Subject: proof-of-work principle applied to mail sending protocol(s) - spams Dear List, I was advised to come to this list with the idea below. I apologize if this is not the right forum, in that case please point be to more appropriate list. In any case i would appreciate any feedback on the thoughts below, which I try to explain very densly and can of course eloborate in detail later in case of interest. A one liner: An idea based on the proof-of-work principle to tremendously decrease mail spam traffic. A short extract: The problem: The problem of spam mails is still existing and current solutions are trying to cure the issue on the wrong side of the problem. Despite the fact, that due to state-of-art spam filters spams are not really problems for the end user, spam mails are still generated, sent and generating malicious internet traffic. This is because a.) it is virtually free for spammers to send the mails and b.) spams are treated only after they arrived into their destination. The solution: While keeping all the good properties of open message/mail sending protocols, we need to change a.) and b.) and there is a way to do this in one step, which is the following: Let's imagine the following imaginary mail sending protocol. 1.) Sender contacts the Receiver 2.) Receiver verifies Sender's identity 3a.) If Sender identity is known to Receiver, then Receiver accepts Sender's message. 3b.) If Sender's identity not know for the Receiver then Receiver says to Sender: "I do not know You, but you can still send me a message if you solve this problem!" 4.) The Receiver gives a computational problem to the Sender which a.) can be infinitely, trivially (or parallely) generated b.) can easily be verified c.) and can be solved only serially, i.e. unparalellizable (so as to ensure that it takes more-or less the same time for everybody) d.) has a well estimable and tunable computational complexity e.) generated on the spot, has limited lifetime and used only once so as to exclude any second or aftermarket of problem solvers and mail senders 5.) If the Sender is really serious about to send the message it solves the problem, i.e. it dedicates N seconds/minutes of computational time to solve the problem and connects back the Receiver with the solution 6.) Having the solution presented to the Receiver the Receiver accepts the message, since a proof-of-work was presented. 7.) The user who reads the mail can mark Sender as 'known' so next time Sender does not have to perform calculation What follows: a.) This way anybody can contact anybody (no whitelist/blacklist) and it it only the first contact which is "painful". b.) No human labor intensive captcha solving is involved c.) No money, 3rd party, administration or any legal regularisation involved still working. d.) Since this way it becomes several order of magnitudes more expensive to spammers to contact unknown email adresses for the first time, it becomes economically unfeasible to operate and manage spamming botnets or other spamming machinery. e.) Problem requiring can be optional and problem complexity can vary from address to address. f.) Problem can be sent as a 1 liner error message inside SMTP communication g.) The idea can be implemented organically inside the SMPT protocol. h.) In this way spams are not even generated and does not generate internet traffic so spam issue is treated at the right side of the problem. There is of course many more little but important details to discuss about, this is just the brief overview of the idea. Would appreciate any feedback and/or volunteer prototype implementation in case of interest Sincerely, Gergely Debreczeni
Re: proof-of-work principle applied to mail sending protocol(s) - spams
Hashcash does already work on protocol level, but for a widely deployment to happen, senders must start using it "at own initiative", before receivers can start enforcing them. Once senders have adopted the system, receivers can simply start enforcing hashcash. Enforcing hashcash means rejecting all mails that have less than a certain bits on the hashcash stamp. (or no hashcash stamp) So basically, its the chicken-and-egg problem. Senders wont start using it before receivers do enforce it. Receivers cant start enforcing it before senders start using it. (same can be seen with chip'n'pin, you can't simply start enforcing chip cards because theres lots of issuers who use magstripe cards, thus all card readers today still have magstripe reader - and same with pin, theres lots of card readers who dont have a pinpad, thus you cannot enforce pin on the "issuer side", you have to accept signature transactions too - and theres lots of readers without chip slot, thus issuers have to issue chip+magstripe cards, not chip-only cards) So this is a problem that exist everywhere, once a system is widely adopted, its hard to change the system without either adding backwards compatibility or breaking the system. Even if you implement hashcash on the SMTP protocol level, you cannot simply "upgrade" your system because then you will start rejecting all mail from old systems. This still means that regardless on how you implement it, senders must start using the system at own initiative before receivers can start requiring it. Just look at STARTTLS. Even if most mailservers do support it, theres still mailservers out there that wont support STARTTLS, thus you cannot require encryption. Another thing to watch out for, is that lists, like this (postfix list) would have to generate *LOTS* of proof-of-work to be able to send mail to its users. If lists would get whitelisted in a "hashcash-mandatory" system, and the list itself would require "hashcash", then spammers would simply use the list as a "spam amplification" system. Nowadays, lists like "postfix users" are free of spam, just because its easier for spammers to send out spam themselves. But a thing mail server owners with greylist can do, is to express-lane all hashcash-stamped mails with a sufficent bit amount through, eg they dont have to negotiate greylist and queue mail for the specified waiting period. Same can be done for spam filters. The good thing with hashcash is that it does not require any previous negotiation. You just generate a hashcash that is "sufficently strong" for your taste, and then you see if the receiver likes it or not. This means you can also configure your greylist system to enforce different delay periods for different hashcash bit levels, so even "weak" hashcashes are accepted partially. -Ursprungligt meddelande- From: Gergely Debreczeni Sent: Thursday, May 07, 2015 12:31 AM To: Sebastian Nielsen ; postfix-users@postfix.org Subject: RE: proof-of-work principle applied to mail sending protocol(s) - spams Thank you Sebastion ! i'll check on that better ! Though, it does not solve the part of spam generation. Spams are still generated but killed on the Receiver side. If all this could be implemented on the protocol level and 'on demand' than it would work much better. Cheers, Gergely From: Sebastian Nielsen [sebast...@sebbe.eu] Sent: 07 May 2015 00:20 To: Gergely Debreczeni; postfix-users@postfix.org Subject: Re: proof-of-work principle applied to mail sending protocol(s) - spams IT do already exist: http://www.hashcash.org/ Im already using it. See this mail, you find this header: X-Hashcash: 1:26:150428:nielsen.sebast...@gmail.com::8G9E5dBe8isoyoyL:07iLtb Thats a proof-of-work system with hashcash. Im currently have a module in my outgoing mail server that generates such "hashcash" stamps with the help of a milter. Spamassassin in default config should reward such headers with a negative spam score. -Ursprungligt meddelande- From: Gergely Debreczeni Sent: Thursday, May 07, 2015 12:11 AM To: postfix-users@postfix.org Subject: proof-of-work principle applied to mail sending protocol(s) - spams Dear List, I was advised to come to this list with the idea below. I apologize if this is not the right forum, in that case please point be to more appropriate list. In any case i would appreciate any feedback on the thoughts below, which I try to explain very densly and can of course eloborate in detail later in case of interest. A one liner: An idea based on the proof-of-work principle to tremendously decrease mail spam traffic. A short extract: The problem: The problem of spam mails is still existing and current solutions are trying to cure the issue on the wrong side of the problem. Despite the fact, that due to state-of-art spam filters spams are not really problems for the end user, spam mails are stil
Love the docs
http://www.postfix.org/STANDARD_CONFIGURATION_README.html To whoever dreamed up the "configuration commands with line number followed by a translation": thank you Chris
Re: Love the docs
Chris Stankevitz: > http://www.postfix.org/STANDARD_CONFIGURATION_README.html > > To whoever dreamed up the "configuration commands with line number > followed by a translation": thank you I'm sure I must have gotten the idea from the days that computer systems filled a room, they were hard to use, and therefore they came with extensive documentation. Sometimes this was called the grey wall, or whatever was the color of the manufacturer. Wietse
