Re: Conditional milter_header_checks?
On 15/07/21 1:07 am, Bill Cole wrote: If you want to post to discussion mailing lists, you should either use a From address in a domain without any DMARC record or publish one with a p=none policy and sign your messages with DKIM, even though they are likely to be broken by the mailing list. This is not entirely necessary. If you send to a list, using a From address in a domain that has a DMARC policy (i.e. with p=quarantine or p=reject), then provided that the message is properly DKIM-signed by the From domain and hasn't been modified in a way that breaks that signature, then there is no problem. The reason is because the DKIM check still passes, and DMARC only requires the SPF check /or/ the DKIM check to pass, it doesn't need both. The main problem I've seen is when someone sends an email to a list, using a From address in a domain that has a DMARC policy, where the domain doesn't DKIM-sign the messages. In this case, because the mailing list forwards the email using a different envelope address, there is no way that DMARC can be satisfied. In my experience DMARC works well if you set it up properly. But unfortunately there are many opportunities for mail server administrators to set it up badly, and that's when it causes problems. And FWIW, I've never seen evidence of any DKIM signature breakage from this mailing list (i.e. Postfix Users). But perhaps other mailing list software might be problematic? Nick.
Re: Bypass postscreen
On 14/07/2021 23:56, Doug Hardie wrote: I have both of those set to enforce. Here is the complete postscreen section of main.cf: # postscreen spam filtering postscreen_greet_action = enforce postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = bl.spamcop.net zen.spamhaus.org b.barracudacentral.org postscreen_access_list = permit_mynetworks, cidr:/usr/local/etc/postfix/access.cidr # That seems to work as I see numerous spam being blocked by those dnsbl sites. Am I missing something? postscreen_blacklist_action [now postscreen_denylist_action] also needs to be set to either "enforce" or "drop" The default is "ignore"... Allen C
Re: Bypass postscreen
Doug Hardie: I have a postfix server that uses postscreen. However, occasionally a needed mail is blocked by one of the spam services. Is there a way to bypass postscreen for just one or more specific addresses for a short time? On 12 July 2021, at 18:27, Wietse Venema wrote: http://www.postfix.org/postconf.5.html#postscreen_access_list http://www.postfix.org/POSTSCREEN_README.html#quick Doug Hardie: I went through those earlier. I have configured: postscreen_access_list = permit_mynetworks, cidr:/usr/local/etc/postfix/access.cidr On 14 July 2021, at 06:12, Wietse Venema wrote: You also need to set postscreen_denylist_action (or postscreen_blacklist_action). On 14.07.21 15:56, Doug Hardie wrote: Perhaps I am a bit confused. The web page says: To use the postscreen(8) service to block mail, edit main.cf and specify one or more of: • "postscreen_dnsbl_action = enforce", to reject clients that are on DNS blocklists, and to log the helo/sender/recipient information. With good DNSBLs this reduces the amount of load on Postfix SMTP servers dramatically. • "postscreen_greet_action = enforce", to reject clients that talk before their turn, and to log the helo/sender/recipient information. This stops over half of all known-to-be illegitimate connections to Wietse's mail server. It is backup protection for zombies that haven't yet been denylisted. I have both of those set to enforce. Here is the complete postscreen section of main.cf: # postscreen spam filtering postscreen_greet_action = enforce postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = bl.spamcop.net zen.spamhaus.org b.barracudacentral.org postscreen_access_list = permit_mynetworks, cidr:/usr/local/etc/postfix/access.cidr # That seems to work as I see numerous spam being blocked by those dnsbl sites. Am I missing something? postscreen_denylist_action/postscreen_blacklist_action is needed if you want postscreen to refuse connections from IPs marked in your /usr/local/etc/postfix/access.cidr as "reject". since you only need to allow specific IPs, you apparently don't need that. I'd would set it anyway - to avoid wondering if you put "reject" there why it doesn't work. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Honk if you love peace and quiet.
Re: Conditional milter_header_checks?
On 07-15-2021 3:30 am, Nick Tait wrote: This is not entirely necessary. If you send to a list, using a From address in a domain that has a DMARC policy (i.e. with p=quarantine or p=reject), then provided that the message is properly DKIM-signed by the From domain and hasn't been modified in a way that breaks that signature, then there is no problem. The reason is because the DKIM check still passes, and DMARC only requires the SPF check _or_ the DKIM check to pass, it doesn't need both. The main problem I've seen is when someone sends an email to a list, using a From address in a domain that has a DMARC policy, where the domain doesn't DKIM-sign the messages. In this case, because the mailing list forwards the email using a different envelope address, there is no way that DMARC can be satisfied. In my experience DMARC works well if you set it up properly. But unfortunately there are many opportunities for mail server administrators to set it up badly, and that's when it causes problems. And FWIW, I've never seen evidence of any DKIM signature breakage from this mailing list (i.e. Postfix Users). But perhaps other mailing list software might be problematic? After hearing all sides, i decided to try using policy settings recommended by Viktor. Since then I've had two emails from this list rejected by DMARC which now confuses me. The email didn't fail SPF or DKIM. postfix/smtpd[226953]: connect from camomile.cloud9.net[168.100.1.3] policyd-spf[226970]: prepend Received-SPF: None (mailfrom) identity=mailfrom; client-ip=168.100.1.3; helo=camomile.cloud9.net; envelope-from=owner-postfix-us...@postfix.org; receiver= postfix/smtpd[226953]: 4GQLM7378Wz4l3hN: client=camomile.cloud9.net[168.100.1.3] postfix/cleanup[226977]: 4GQLM7378Wz4l3hN: info: header Subject: Re: Conditional milter_header_checks? from camomile.cloud9.net[168.100.1.3]; from= to= proto=ESMTP helo= postfix/cleanup[226977]: 4GQLM7378Wz4l3hN: message-id=<20210715040216.ga27...@raf.org> opendkim[221168]: 4GQLM7378Wz4l3hN: camomile.cloud9.net [168.100.1.3] not internal opendkim[221168]: 4GQLM7378Wz4l3hN: not authenticated opendkim[221168]: 4GQLM7378Wz4l3hN: no signature data opendmarc[221165]: 4GQLM7378Wz4l3hN: raf.org fail postfix/cleanup[226977]: 4GQLM7378Wz4l3hN: milter-reject: END-OF-MESSAGE from camomile.cloud9.net[168.100.1.3]: 5.7.1 rejected by DMARC policy for raf.org; from= to= proto=ESMTP helo= postfix/smtpd[226953]: disconnect from camomile.cloud9.net[168.100.1.3] ehlo=2 starttls=1 mail=1 rcpt=1 data=0/1 quit=1 commands=6/7 Was SPF looking up records for raf.org or for cloud9.net? I see both of those domains have published SPF records so why was SPF "None"? Why did DMARC reject this even though it didn't fail either check?
Re: Conditional milter_header_checks?
post...@ptld.com: After hearing all sides, i decided to try using policy settings recommended by Viktor. Since then I've had two emails from this list rejected by DMARC which now confuses me. The email didn't fail SPF or DKIM. postfix/smtpd[226953]: connect from camomile.cloud9.net[168.100.1.3] policyd-spf[226970]: prepend Received-SPF: None (mailfrom) identity=mailfrom; client-ip=168.100.1.3; helo=camomile.cloud9.net; envelope-from=owner-postfix-us...@postfix.org; receiver= postfix/smtpd[226953]: 4GQLM7378Wz4l3hN: client=camomile.cloud9.net[168.100.1.3] postfix/cleanup[226977]: 4GQLM7378Wz4l3hN: info: header Subject: Re: Conditional milter_header_checks? from camomile.cloud9.net[168.100.1.3]; from= to= proto=ESMTP helo= postfix/cleanup[226977]: 4GQLM7378Wz4l3hN: message-id=<20210715040216.ga27...@raf.org> opendkim[221168]: 4GQLM7378Wz4l3hN: camomile.cloud9.net [168.100.1.3] not internal opendkim[221168]: 4GQLM7378Wz4l3hN: not authenticated opendkim[221168]: 4GQLM7378Wz4l3hN: no signature data opendmarc[221165]: 4GQLM7378Wz4l3hN: raf.org fail postfix/cleanup[226977]: 4GQLM7378Wz4l3hN: milter-reject: END-OF-MESSAGE from camomile.cloud9.net[168.100.1.3]: 5.7.1 rejected by DMARC policy for raf.org; from= to= proto=ESMTP helo= postfix/smtpd[226953]: disconnect from camomile.cloud9.net[168.100.1.3] ehlo=2 starttls=1 mail=1 rcpt=1 data=0/1 quit=1 commands=6/7 Was SPF looking up records for raf.org or for cloud9.net? I see both of those domains have published SPF records so why was SPF "None"? Why did DMARC reject this even though it didn't fail either check? The header ‘From:’ domain is raf.org. SPF: The MAIL FROM domain is postfix.org with SPF result ‘none’, but this is irrelevant since the domain doesn’t align with raf.org. DKIM: There is no DKIM signature. DMARC: fails because there is no positive result for either SPF or DKIM. This is basic stuff, I recommend reading an intro to DMARC.
Re: Conditional milter_header_checks?
On 2021-07-15 14:12, post...@ptld.com wrote: Was SPF looking up records for raf.org or for cloud9.net? I see both of those domains have published SPF records so why was SPF "None"? Why did DMARC reject this even though it didn't fail either check? use smtpd_milter_maps to enforce no reject from maillists milters i dont use milters anymore if thats knowledge
Manual Clarification
daemon_timeout: "How much time a Postfix daemon process may take to handle a request before it is terminated" What is "a request"? Is that the amount of time a client is connected? Is that the amount of time between command request? Other? Does "a request" cover multiple client connections? smtpd_hard_error_limit: "The maximal number of errors a remote SMTP client is allowed to make without delivering mail." Is RCPT user unknown count as an error towards this limit? And "without delivering mail" means the counter is reset on a successful delivery so this is not a total hard limit for the entire length of the client connection? smtpd_junk_command_limit: "The number of junk commands that a remote SMTP client can send before the Postfix SMTP server starts to increment the error counter with each junk command." Making sure i understand correctly, using this means junk commands count as errors towards the hard error limit after giving the first x number of freebies? If hard error limit is 3 and junk limit is 3 then after 6 junk commands postfix would end the connection?
Re: Bypass postscreen
Doug Hardie: > > On 14 July 2021, at 06:12, Wietse Venema wrote: > > > > Doug Hardie: > >> > >>> On 12 July 2021, at 18:27, Wietse Venema wrote: > >>> > >>> Doug Hardie: > I have a postfix server that uses postscreen. However, occasionally > a needed mail is blocked by one of the spam services. Is there a > way to bypass postscreen for just one or more specific addresses > for a short time? > >>> > >>> http://www.postfix.org/postconf.5.html#postscreen_access_list > >>> http://www.postfix.org/POSTSCREEN_README.html#quick > >>> > >> > >> I went through those earlier. I have configured: > >> > >> postscreen_access_list = permit_mynetworks, > >>cidr:/usr/local/etc/postfix/access.cidr > > > > You also need to set postscreen_denylist_action (or > > postscreen_blacklist_action). > > > > Wietse > > Perhaps I am a bit confused. The web page says: See: http://www.postfix.org/postconf.5.html#postscreen_blacklist_action http://www.postfix.org/postconf.5.html#postscreen_denylist_action
Re: Manual Clarification
smtpd_timeout: "The time limit for sending a Postfix SMTP server response and for receiving a remote SMTP client request." Does the time a milter or policy script run count against this because it says "SMTP server response"? Or is the time postfix waits on a milter/policy reply excluded from this time out?
Re: Manual Clarification
post...@ptld.com: > > smtpd_timeout: > "The time limit for sending a Postfix SMTP server response and for > receiving a remote SMTP client request." When the Postfix SMTP server wants to send an SMTP server response, this limits how long the Postfix SMTP server will wait for an underlying network read operation to complete. When the Postfix SMTP server Postfix wants to receive an SMTP client request, this limits how long the Postfix SMTP server will wait for an underlying network read operation to complete. http://www.postfix.org/postconf.5.html#smtpd_per_record_deadline gives additional control over this process. Wietse
Re: Manual Clarification
Wietse Venema: > post...@ptld.com: > > > > smtpd_timeout: > > "The time limit for sending a Postfix SMTP server response and for > > receiving a remote SMTP client request." Typofix: When the Postfix SMTP server wants to send an SMTP server response, this limits how long the Postfix SMTP server will wait for an underlying network write operation to complete. When the Postfix SMTP server Postfix wants to receive an SMTP client request, this limits how long the Postfix SMTP server will wait for an underlying network read operation to complete. http://www.postfix.org/postconf.5.html#smtpd_per_record_deadline gives additional control over this process. Wietse
Re: Manual Clarification
Wietse Venema: post...@ptld.com: > > smtpd_timeout: > "The time limit for sending a Postfix SMTP server response and for > receiving a remote SMTP client request." When the Postfix SMTP server wants to send an SMTP server response, this limits how long the Postfix SMTP server will wait for an underlying network write operation to complete. When the Postfix SMTP server Postfix wants to receive an SMTP client request, this limits how long the Postfix SMTP server will wait for an underlying network read operation to complete. http://www.postfix.org/postconf.5.html#smtpd_per_record_deadline gives additional control over this process. Forgive me being slow to comprehend. Does this mean the time it takes for the client to transmit attached file data is controlled by this timeout? If the timeout is 10s and it takes 20s to upload a huge file will it trigger this timeout?
Re: Manual Clarification
On 07-15-2021 12:20 pm, post...@ptld.com wrote: Wietse Venema: post...@ptld.com: > > smtpd_timeout: > "The time limit for sending a Postfix SMTP server response and for > receiving a remote SMTP client request." When the Postfix SMTP server wants to send an SMTP server response, this limits how long the Postfix SMTP server will wait for an underlying network write operation to complete. When the Postfix SMTP server Postfix wants to receive an SMTP client request, this limits how long the Postfix SMTP server will wait for an underlying network read operation to complete. http://www.postfix.org/postconf.5.html#smtpd_per_record_deadline gives additional control over this process. Forgive me being slow to comprehend. Does this mean the time it takes for the client to transmit attached file data is controlled by this timeout? If the timeout is 10s and it takes 20s to upload a huge file will it trigger this timeout? Sorry, i forgot to finish that thought. If im understanding smtpd_per_record_deadline, the default is no meaning the timeout is just to the start of the client transmitting the file attachment and a setting of yes means the timeout would be in effect until the end of the file attachment transmission? Am i understanding correctly?
Re: Manual Clarification
post...@ptld.com: > > Wietse Venema: > >> post...@ptld.com: > >> > > >> > smtpd_timeout: > >> > "The time limit for sending a Postfix SMTP server response and for > >> > receiving a remote SMTP client request." > > > > When the Postfix SMTP server wants to send an SMTP server response, > > this limits how long the Postfix SMTP server will wait for an > > underlying network write operation to complete. > > > > When the Postfix SMTP server Postfix wants to receive an SMTP client > > request, this limits how long the Postfix SMTP server will wait for > > an underlying network read operation to complete. > > > > http://www.postfix.org/postconf.5.html#smtpd_per_record_deadline > > gives additional control over this process. > > Forgive me being slow to comprehend. Does this mean the time it takes > for the client to transmit attached file data is controlled by this > timeout? If the timeout is 10s and it takes 20s to upload a huge file > will it trigger this timeout? You, Sir, need to get some basic education on how packet-switched computer networks deliver data between applications. This mailing list, and Postfix documentation, are not the place to get that education. In a past epoch I would recommend the excellent books by Comer (Internetworking with TCP/IP) and Stevens (TCP/IP illustrated). Wietse
Re: Manual Clarification
this limits how long the Postfix SMTP server will wait for an underlying network write operation to complete. You, Sir, need to get some basic education on how packet-switched computer networks deliver data between applications. This mailing list, and Postfix documentation, are not the place to get that education. Just some construction criticism, but you have come across as arrogant and condescending on multiple occasions and not just with me. But i think you know this and do so on purpose. I was trying to be polite when i said i didn't comprehend. What i really meant is you often expect a reader to understand you 100% because you assume they know all the details you aren't saying out-loud. I do have a basic understand of networking, layers, TCP, UDP, packets, etc. I just don't always understand how an author might be using some technical jargon. For example your usage of "underlying network write operation" means exactly what? Its not officially defined and has a loose meaning depending on how you using it. If im wrong, whats the RFC giving it an exact definition? You spend more effort telling people off then just giving a simple few word answer. The last time was when you told me to RTFM, which you know i did cause i was quoting the manual to you. Just because i don't fully understand the exact meaning of your usage or words doesn't mean i didn't read it or understand the concepts. If you want to consider yourself superior because i don't always understand your usage of words, fine, you're smarter than me. I didn't know the users mailing list had a litmus test requiring everyone to be smarter than you to be worthy of help. So back to my question, must i really have a networking degree just to get you to say if the timeout covers how long it takes for the stream of TCP packets to complete and be reassembled, or just until it gets that first packet back starting the transmission of the stream? Or in my not-as-smart-as-you layman terms, will it time out in the middle of an attachment upload?
Re: Manual Clarification
post...@ptld.com: > >> this limits how long the Postfix SMTP server will wait for an > >> underlying network write operation to complete. > > > You, Sir, need to get some basic education on how packet-switched > > computer networks deliver data between applications. This mailing > > list, and Postfix documentation, are not the place to get that > > education. There is no malicious intent. This just isn't the right place to expand upon how an application-level data stream is broken up and reassembled by the network stack, and how this reflects in the behavior of OS-level read/write system calls. I appreciate that you are willing to learn. However, this is not the right place. Wietse
Re: Manual Clarification
> On 15 Jul 2021, at 10:41 am, post...@ptld.com wrote: > > "The time limit for sending a Postfix SMTP server response and for receiving > a remote SMTP client request." The amount of time that smtpd(8) is willing to wait for a network write to write some data when writing a command-response, or for a network read to return some data when reading an SMTP command. As elaborated under: http://www.postfix.org/postconf.5.html#smtpd_per_record_deadline Change the behavior of the smtpd_timeout and smtpd_starttls_timeout time limits, from a time limit per read or write system call, to a time limit to send or receive a complete record (an SMTP command line, SMTP response line, SMTP message content line, or TLS protocol message). This limits the impact from hostile peers that trickle data one byte at a time. Thus the default timeout is per read or write, rather than the complete requested operation. With the deadline timer the timeout applies to the entire I/O operation, possibly spanning multi reads or writes. However, even then it is never the transmission of an entire message body, rather it would be a logical data fragment, an SMTP command or response, a body content line, a TLS protocol record, ... which partly mitigates "Slowloris" attacks, https://en.wikipedia.org/wiki/Slowloris_(computer_security) meaningful progress must be made within the deadline timer, just sending a few characters per 300s is not enough. -- Viktor.
Re: Manual Clarification
I have to admit that when I first saw this, it was also a bit confusing as I was equating this with typical packet and session timeouts at the network level. What helped me better understand this was the phrase “one byte at a time” and then reading up on things like Slow Loris that Viktor included… Just my .02… - - - On 15 Jul 2021, at 12:21, Viktor Dukhovni wrote: On 15 Jul 2021, at 10:41 am, post...@ptld.com wrote: "The time limit for sending a Postfix SMTP server response and for receiving a remote SMTP client request." The amount of time that smtpd(8) is willing to wait for a network write to write some data when writing a command-response, or for a network read to return some data when reading an SMTP command. As elaborated under: http://www.postfix.org/postconf.5.html#smtpd_per_record_deadline Change the behavior of the smtpd_timeout and smtpd_starttls_timeout time limits, from a time limit per read or write system call, to a time limit to send or receive a complete record (an SMTP command line, SMTP response line, SMTP message content line, or TLS protocol message). This limits the impact from hostile peers that trickle data one byte at a time. Thus the default timeout is per read or write, rather than the complete requested operation. With the deadline timer the timeout applies to the entire I/O operation, possibly spanning multi reads or writes. However, even then it is never the transmission of an entire message body, rather it would be a logical data fragment, an SMTP command or response, a body content line, a TLS protocol record, ... which partly mitigates "Slowloris" attacks, https://en.wikipedia.org/wiki/Slowloris_(computer_security) meaningful progress must be made within the deadline timer, just sending a few characters per 300s is not enough. -- Viktor.
Re: Conditional milter_header_checks?
On Thu, Jul 15, 2021 at 08:12:39AM -0400, post...@ptld.com wrote: > Was SPF looking up records for raf.org or for cloud9.net? I see both of > those domains have published SPF records so why was SPF "None"? > Why did DMARC reject this even though it didn't fail either check? Here's my attempt at an explanation: SPF by itself would have checked the envelope address (owner-postfix-us...@postfix.org), but DMARC's reinterpretation of SPF is not the same as actual SPF. It checks the From: address (@raf.org) instead of the envelope address (@postfix.org). That's why the DMARC+SPF check failed (even though a plain SPF check (which didn't happen) would have passed). The From: address's SPF record did not include the IP addresses used by @postfix.org to send emails. [Actually, I have added them but that's just me being silly, and I'm assuming they weren't correctly in place at the time.] Similarly, DMARC's reinterpretation of DKIM is not the same as actual DKIM. DMARC+DKIM requires that the DKIM d= domain matches the From: header. Plain DKIM by itself doesn't require that. Someone on this list has implied that there needs to be both a DMARC+DKIM pass *and* a DMARC+SPF pass in order for DMARC to pass. Another (in this thread) has said that there only needs to be a DMARC+DKIM pass *or* a DMARC+SPF pass in order for DMARC to pass. I'm not sure which is correct (until I read the RFC myself). Whichever is correct, that email resulted in a DMARC failure because there was a DMARC+SPF failure and no DKIM at all so that's a DMARC+DKIM failure. This is even though a plain SPF check would have passed, and a plain DKIM check would never have taken place (and so wouldn't pass or fail). cheers, raf
Re: Conditional milter_header_checks?
On 2021-07-15 at 19:44:41 UTC-0400 (Fri, 16 Jul 2021 09:44:41 +1000) raf is rumored to have said: SPF by itself would have checked the envelope address (owner-postfix-us...@postfix.org), but DMARC's reinterpretation of SPF is not the same as actual SPF. It checks the From: address (@raf.org) instead of the envelope address (@postfix.org). Not exactly. SPF always checks the envelope sender. DMARC only considers SPF if the envelope sender domain aligns with the From header address domain. That's why the DMARC+SPF check failed (even though a plain SPF check (which didn't happen) would have passed). No, postfix.org has no TXT record, so mail from a postfix.org address can neither pass nor fail a SPF test. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Conditional milter_header_checks?
On Thu, Jul 15, 2021 at 08:07:52PM -0400, Bill Cole wrote: > On 2021-07-15 at 19:44:41 UTC-0400 (Fri, 16 Jul 2021 09:44:41 +1000) > raf > is rumored to have said: > > > SPF by itself would have checked the envelope address > > (owner-postfix-us...@postfix.org), but DMARC's > > reinterpretation of SPF is not the same as actual SPF. > > It checks the From: address (@raf.org) instead of the > > envelope address (@postfix.org). > > Not exactly. > > SPF always checks the envelope sender. DMARC only considers SPF if the > envelope sender domain aligns with the From header address domain. Thanks. I had misunderstood that. It's strange then that I'm receiving DMARC+SPF failure reports. If DMARC isn't considering SPF, then DMARC+SPF shouldn't be passing or failing. The failure reports caused me to conclude that DMARC checks SPF when the From: address domain has an SPF record, not just when it aligns with the envelope domain. I guess the absence of a check counts as a failure. > > That's why the DMARC+SPF check failed (even though a > > plain SPF check (which didn't happen) would have > > passed). > > No, postfix.org has no TXT record, so mail from a postfix.org address can > neither pass nor fail a SPF test. Yes, I just realised that and was about to correct it. Thanks for both corrections. > -- > Bill Cole > b...@scconsult.com or billc...@apache.org > (AKA @grumpybozo and many *@billmail.scconsult.com addresses) > Not Currently Available For Hire cheers, raf
Re: Conditional milter_header_checks?
On 2021-07-16 02:07, Bill Cole wrote: No, postfix.org has no TXT record, so mail from a postfix.org address can neither pass nor fail a SPF test. spf none is a valid test in mail::spf its not same as spf neutral as a spamassassin pmc member you should know
