Re: Stopping backscatter spam to a specific domain
On Jul 11, 2021, at 1:06 PM, Claus R. Wickinghoff wrote: I think this can be achieved with reject_unverified_recipient to query dovecot via lmtp but I've no practical experience with this. Probably you've to do some googling... On 12.07.21 10:19, Ron Garret wrote: That turned out to be the Right Answer. I simply added reject_unverified_recipient to smtpd_recipient_restrictions and that fixed the problem. The chain of events that led to this problem is kind of interesting. What happened was that I migrated my email server from one machine, where it had been running with no problem for many years, to a new machine at a new provider. I had simply copied the main.cf file from the old machine to the new one, but changed the delivery mechanism from direct delivery (i.e. postfix as LDA) to LMTP (i.e. dovecot as LDA). So what was happening before (I think) is that postfix was looking up users in the user DB, not because of smtpd_recipient_restrictions (because I didn’t have that set) but because it had to in order to deliver local messages. When I switched to LMTP that was no longer the case. Postfix now thought it was possible to deliver to non-existent users, and that’s what resulted in the backscatter. it MAY still be possible to set up postfix to read local recipients from database dovecot uses. Look at local_recipient_maps directive if it's possible, depends on your dovecot setup. reject_unverified_recipient requires verifying each recipient and keep track of them (deliverable or not) which is useful for cases where you can not use local_recipient_maps -- 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. Micro random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0...
warning: too many reverse jump records
I am getting "too many reverse jump records" messages. Couldn't find any information about this message and looking at the source code (record.c) it seems to be related with adding recipients and/or headers, but I am not adding that many (1) of either. There is a milter application before queue that adds a couple of headers but that is it. Between start and the final delivery there were 509 of these warnings (delays=3548/4125/0.24/0.49). This is a very active server and usually there are a few thousand mails in the queue. 2021-07-13T15:26:14.777532+00:00 server01 postfix/smtpd[912469]: 4GPKc12345z6n5pV: client=unknown[10.11.22.33], sasl_method=XCLIENT, sasl_username=u...@redacted.com 2021-07-13T15:26:14.827403+00:00 server01 postfix/cleanup[910108]: 4GPKc12345z6n5pV: message-id= 2021-07-13T15:26:15.769603+00:00 server01 postfix/showq[785453]: warning: incoming/4GPKc12345z6n5pV: too many reverse jump records 2021-07-13T15:26:30.822828+00:00 server01 postfix/showq[785453]: warning: incoming/4GPKc12345z6n5pV: too many reverse jump records 2021-07-13T15:26:45.635767+00:00 server01 postfix/showq[785453]: warning: incoming/4GPKc12345z6n5pV: too many reverse jump records ... 2021-07-13T16:25:29.736077+00:00 server01 postfix/showq[1285034]: warning: active/4GPKc12345z6n5pV: too many reverse jump records 2021-07-13T16:25:44.793480+00:00 server01 postfix/showq[1285484]: warning: active/4GPKc12345z6n5pV: too many reverse jump records 2021-07-13T16:25:59.764867+00:00 server01 postfix/showq[1285034]: warning: active/4GPKc12345z6n5pV: too many reverse jump records ... 2021-07-13T17:34:06.914021+00:00 server01 postfix/smtp[1788437]: 4GPKc12345z6n5pV: to=, relay=rcpt.server.com[10.12.23.34]:25, delay=7673, delays=3548/4125/0.24/0.49, dsn=2.0.0, status=sent (250 2.0.0 Message accepted for delivery) 2021-07-13T17:34:06.915500+00:00 server01 postfix/qmgr[1283513]: 4GPKc12345z6n5pV: removed Thank you -- Mehmet
Conditional milter_header_checks?
Is there a way to have header checks happen as a condition during smtpd_recipient_restrictions but not happen other times? Something like assign the header check to a restriction class which can be called on during a check_recipient_access? End goal is to conditionally run header matching/action based on recipient checked against mysql:/lookup
Re: Conditional milter_header_checks?
Is there a way to have header checks happen as a condition during smtpd_recipient_restrictions but not happen other times? Something like assign the header check to a restriction class which can be called on during a check_recipient_access? End goal is to conditionally run header matching/action based on recipient checked against mysql:/lookup I guess i should elaborate on that more, the real real end goal is per-recipient kdim enforcement. Since it's impossible to control if milter/dkim runs or not based on recipient, my next option to explore is allowing dkim to run passive to just create the headers, then during smtpd_recipient_restrictions based on recipient decide whether or not to take action on the information in the dkim header to reject or allow the mail.
Re: Conditional milter_header_checks?
On 2021-07-13 at 12:14:50 UTC-0400 (Tue, 13 Jul 2021 12:14:50 -0400) is rumored to have said: > Is there a way to have header checks happen as a condition during > smtpd_recipient_restrictions but not happen other times? > Something like assign the header check to a restriction class which can be > called on during a check_recipient_access? > > End goal is to conditionally run header matching/action based on recipient > checked against mysql:/lookup Logically impossible. You don't have the headers yet when smtpd_recipient_restrictions directives are evaluated. -- 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 07-13-2021 12:29 pm, Bill Cole wrote: Logically impossible. You don't have the headers yet when smtpd_recipient_restrictions directives are evaluated. If i move the "operation" to another stage like data or end_of_data is there a way to invoke header checks based on recipient?
Re: Conditional milter_header_checks?
On 2021-07-13 at 12:47:35 UTC-0400 (Tue, 13 Jul 2021 12:47:35 -0400) is rumored to have said: >> On 07-13-2021 12:29 pm, Bill Cole wrote: >> >> Logically impossible. You don't have the headers yet when >> smtpd_recipient_restrictions directives are evaluated. > > If i move the "operation" to another stage like data or end_of_data is there > a way to invoke header checks based on recipient? No. All of the restriction lists are named 'smtpd_*_restrictions' which is a clue that they are used by the smtpd process. The header_checks are a function of the cleanup daemon, not smtpd. If you need to handle message content differently on a per-recipient basis before queueing, you need to do the selection inside a milter which also handles exploding any multi-recipient messages into a unique message for each recipient. Another approach is described in the FILTER_README file. -- 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 07-13-2021 1:27 pm, Bill Cole wrote: No. All of the restriction lists are named 'smtpd_*_restrictions' which is a clue that they are used by the smtpd process. The header_checks are a function of the cleanup daemon, not smtpd. If you need to handle message content differently on a per-recipient basis before queueing, you need to do the selection inside a milter which also handles exploding any multi-recipient messages into a unique message for each recipient. Another approach is described in the FILTER_README file. Thank you.
Re: warning: too many reverse jump records
Mehmet Avcioglu: > I am getting "too many reverse jump records" messages. Couldn't find > any information about this message and looking at the source code > (record.c) it seems to be related with adding recipients and/or > headers, but I am not adding that many (1) of either. > > There is a milter application before queue that adds a couple of > headers but that is it. Between start and the final delivery there > were 509 of these warnings (delays=3548/4125/0.24/0.49). This is a > very active server and usually there are a few thousand mails in the > queue. When this is logged, the record reader returns an error and the program stops reading the file. > 2021-07-13T15:26:14.777532+00:00 server01 postfix/smtpd[912469]: > 4GPKc12345z6n5pV: client=unknown[10.11.22.33], sasl_method=XCLIENT, > sasl_username=u...@redacted.com > 2021-07-13T15:26:14.827403+00:00 server01 postfix/cleanup[910108]: > 4GPKc12345z6n5pV: > message-id= > 2021-07-13T15:26:15.769603+00:00 server01 postfix/showq[785453]: > warning: incoming/4GPKc12345z6n5pV: too many reverse jump records The postfix/showq logging repeats the same error for the same file, every 15 seconds, presumably because you are running 'posqeueue -p" or "mailq" repeatedly. Eventually, the Postfix SMTP client readds the file without error. > 2021-07-13T17:34:06.914021+00:00 server01 postfix/smtp[1788437]: > 4GPKc12345z6n5pV: to=, > relay=rcpt.server.com[10.12.23.34]:25, delay=7673, > delays=3548/4125/0.24/0.49, dsn=2.0.0, status=sent (250 2.0.0 Message > accepted for delivery) Now, Postfix queue files don't repair themselves spontaneously. Before I go off with speculation, I have a few questions to narrow the search: - Is only the showq process affected or other programs, too? - Is this reproducible? - Are you using a special malloc library? I'm suspecting code that I wrote in 20060903 for record loop detection, and the way that it resets the reverse jump counter when it switches queue files. But that would not be the cause if other programs also report "too many reverse jumps". Wietse
Re: Conditional milter_header_checks?
On 07-13-2021 1:27 pm, Bill Cole wrote: No. All of the restriction lists are named 'smtpd_*_restrictions' which is a clue that they are used by the smtpd process. The header_checks are a function of the cleanup daemon, not smtpd. If you need to handle message content differently on a per-recipient basis before queueing, you need to do the selection inside a milter which also handles exploding any multi-recipient messages into a unique message for each recipient. Another approach is described in the FILTER_README file. On 13.07.21 13:32, post...@ptld.com wrote: Thank you. btw, as always: what are you trying to achieve? -- 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. Silvester Stallone: Father of the RISC concept.
Re: Conditional milter_header_checks?
On 07-13-2021 2:47 pm, Matus UHLAR - fantomas wrote: btw, as always: what are you trying to achieve? The end goal is per-recipient kdim enforcement. Since it's impossible to control if milter/dkim runs or not based on recipient, my next option to explore is allowing dkim to run passive to just create the headers, then during smtpd_*_restrictions based on recipient decide whether or not to take action on the information in the dkim header to reject or allow the mail.
Re: Conditional milter_header_checks?
On Tue, Jul 13, 2021 at 03:29:42PM -0400, post...@ptld.com wrote: > > On 07-13-2021 2:47 pm, Matus UHLAR - fantomas wrote: > > btw, as always: what are you trying to achieve? > > The end goal is per-recipient kdim enforcement. Since it's impossible to > control if milter/dkim runs or not based on recipient, my next option to > explore is allowing dkim to run passive to just create the headers, then > during smtpd_*_restrictions based on recipient decide whether or not to > take action on the information in the dkim header to reject or allow the > mail. FWIW, there is no such thing as "DKIM enforcement", you're probably thinking of DMARC. The sensible thing to do with DMARC is to add an Authentication-Results (https://datatracker.ietf.org/doc/html/rfc7601) header to the message, and then file into the spam folder on delivery for users who want to opt-in into DMARC enforcement. The policy decision is then outside the edge MTA, implemented in the LDA. -- Viktor.
Re: Conditional milter_header_checks?
On 07-13-2021 3:34 pm, Viktor Dukhovni wrote: FWIW, there is no such thing as "DKIM enforcement", you're probably thinking of DMARC. Maybe its technically called DMARC, but what im referring to is the opendkim verification mode with a On-BadSignature reject policy. My layman's term of "DKIM enforcement" is in reference to opendkim enforcing dkim signatures to be valid to have mail accepted. Since message forwarding can break signatures i wanted to give people the choice to enforce dkim or not without the drama of teaching them how to manage sieve scripts. Plus id prefer a rejected delivery vs mail being discarded into the void. I will continue to explore options.
Re: Conditional milter_header_checks?
> On 13 Jul 2021, at 3:59 pm, post...@ptld.com wrote: > >> FWIW, there is no such thing as "DKIM enforcement", you're probably >> thinking of DMARC. > > Maybe its technically called DMARC, but what im referring to is the opendkim > verification mode with a On-BadSignature reject policy. My layman's term of > "DKIM enforcement" is in reference to opendkim enforcing dkim signatures to > be valid to have mail accepted. Since message forwarding can break signatures > i wanted to give people the choice to enforce dkim or not without the drama > of teaching them how to manage sieve scripts. Plus id prefer a rejected > delivery vs mail being discarded into the void. I will continue to explore > options. The DKIM standards are quite emphatically clear that bad signature == no signature, and that receiving systems MUST NOT reject a message just because a signature is missing or fails to match. The treatment of messages that lack a signature is covered by DMARC (and ARC). It is a really bad idea to reject messages whose DKIM signature is invalid. DO NOT DO THIS. If opendkim supports "On-BadSignature reject", that's a disservice to its users. -- Viktor.
Re: warning: too many reverse jump records
Wietse Venema: > > Mehmet Avcioglu: > > I am getting "too many reverse jump records" messages. Couldn't find > > any information about this message and looking at the source code > > The postfix/showq logging repeats the same error for the same file, > every 15 seconds, presumably because you are running 'posqeueue -p" > or "mailq" repeatedly. I don't think we are running postqueue or mailq, not intentionally. There is a prometheus exporter that monitors the queue but uses 'find' in the spool directory to do so. I see a few 'showq' processes that are childs of 'master' running all the time though. > Now, Postfix queue files don't repair themselves spontaneously. > Before I go off with speculation, I have a few questions to narrow > the search: > > - Is only the showq process affected or other programs, too? Yes, only the 'showq' logs this message. > - Is this reproducible? Multiple servers are running and keep logging these lines. Restarting postfix or the server does not change, so I continue to see it with new mails. So I am able to reproduce it, now sure how or why though :) > - Are you using a special malloc library? This is with stock RHEL 8.2 running postfix-3.3.1-12.el8 without many additions or changes. Thank you -- Mehmet
Re: Conditional milter_header_checks?
On 07-13-2021 4:14 pm, Viktor Dukhovni wrote: The DKIM standards are quite emphatically clear that bad signature == no signature, and that receiving systems MUST NOT reject a message just because a signature is missing or fails to match. The treatment of messages that lack a signature is covered by DMARC (and ARC). It is a really bad idea to reject messages whose DKIM signature is invalid. DO NOT DO THIS. If opendkim supports "On-BadSignature reject", that's a disservice to its users. So it's unacceptable for dkim software to reject a message for a failed dkim signature. But its okay for dmarc software to reject the message for a failed dkim signature? At the end of the day, does it matter at which step a rejected message was rejected? Thank you for informing me on the "specs". I tend to roll my eyes at some of the RFC's such as helo MUST be a valid FQDN *AND* no one is allowed to reject mail for helo not being FQDN. Then why MUST there be a rule that MUST not be enforced? But this is why i want to leave the choice with the end user, just as they could setup sieve to do the same thing, im just trying to make it more user friendly. Or you going to tell me there is an RFC forbidding end users from also discarding emails with a failed SPF or DKIM?
Re: Conditional milter_header_checks?
On Tue, Jul 13, 2021 at 05:33:35PM -0400, post...@ptld.com wrote: > > If opendkim supports "On-BadSignature reject", that's a disservice to > > its users. > > So it's unacceptable for dkim software to reject a message for a failed > dkim signature. Yes. > But its okay for dmarc software to reject the message for a failed dkim > signature? That's because DMARC (which I don't use or recommed) at least conveys a sender domain policy that specifies the requested handling of messages with missing or invalid signatures. DKIM does not convey any policy, and the correct default policy is to treat invalid signatures the same way as you would treat missing signatures. > At the end of the day, does it matter at which step a rejected message > was rejected? Yes, it does. A DKIM signature does not imply any expectation that all messages will have valid signatures. > Thank you for informing me on the "specs". I tend to roll my eyes at > some of the RFC's such as helo MUST be a valid FQDN *AND* no one is > allowed to reject mail for helo not being FQDN. Then why MUST there be a > rule that MUST not be enforced? You can break your system if you wish. For the record, nobody else should follow your example. -- Viktor.
Re: Conditional milter_header_checks?
I am not meaning to confrontational, i want to develop a deeper understanding and educate myself. A DKIM signature does not imply any expectation that all messages will have valid signatures. Why does DKIM signature exist if not to provide a way to know if an email has been altered after someone sent it? Why can't someone expect a signature to be valid? I assume computers are capable of creating a valid signature 100% of the time. That's because DMARC (which I don't use or recommed) Why don't you recommend DMARC? What is wrong with it? Do you accept *ALL* mail sent to you in your inbox spam or not? Other than SPF records and DMARC what other tools exist to verify if mail came from the domain they purport to? DKIM does not convey any policy, and the correct default policy is to treat invalid signatures the same way as you would treat missing signatures. Yes, DKIM is a signature, and DMARC is the policy that says if the signature is invalid you are allowed to p=reject that mail. But you're telling me at no time are you allowed to reject a message for an invalid signature. Im wondering if that is the case why does DKIM or DMARC exist? Maybe i read it wrong but within DMARC policy isn't it allowed for mail servers to have local policies that override the policy request of what to do with invalid DKIM signatures? You can break your system if you wish. For the record, nobody else should follow your example. How is giving end users the choice, the control, over what happens with their email "breaking" my system? Do you work for Apple? :) that was a joke. But seriously how is that breaking things? Isn't that what sieve was created for?
Re: warning: too many reverse jump records
Mehmet Avcioglu:
> > Now, Postfix queue files don't repair themselves spontaneously.
> > Before I go off with speculation, I have a few questions to narrow
> > the search:
> >
> > - Is only the showq process affected or other programs, too?
>
> Yes, only the 'showq' logs this message.
>
> > - Is this reproducible?
>
> Multiple servers are running and keep logging these lines. Restarting
> postfix or the server does not change, so I continue to see it with new
> mails. So I am able to reproduce it, now sure how or why though :)
>
> > - Are you using a special malloc library?
>
> This is with stock RHEL 8.2 running postfix-3.3.1-12.el8 without many
> additions or changes.
Then I suspect that the code reaches the 1 limit because
there are ~1 files in the queue.
The rec_get routine uses bad code to determine that the program has
switched to a new file, and thus it thinks that there is one file
with 1 backward jumps, instead of 1 files with one backwards
jump. It compares memory addresses instead of pathnames. That works
because typical malloc() implementations don't return the same
addresses all the time.
Below is a patch that should fix this.
Wietse
diff -ur /var/tmp/postfix-3.7-20210707/src/global/record.c src/global/record.c
--- /var/tmp/postfix-3.7-20210707/src/global/record.c 2021-01-13
18:54:42.0 -0500
+++ src/global/record.c 2021-07-13 16:20:47.540814072 -0400
@@ -338,8 +338,10 @@
*/
#define REVERSE_JUMP_LIMIT 1
-if (saved_path != VSTREAM_PATH(stream)) {
- saved_path = VSTREAM_PATH(stream);
+if (saved_path == 0 || strcmp(saved_path, VSTREAM_PATH(stream)) != 0) {
+ if (saved_path)
+ myfree(saved_path);
+ saved_path = mystrdup(VSTREAM_PATH(stream));
reverse_count = 0;
saved_offset = 0;
}
Re: Conditional milter_header_checks?
On 7/13/21 6:06 PM, post...@ptld.com wrote: I am not meaning to confrontational, i want to develop a deeper understanding and educate myself. your issues are not with Postfix, & likely won't be further addressed/solved here they're with your understanding of DMARC policy/usage, and the parts that DKIM, SPF, etc play might be useful to read up on DMARC policy https://dmarc.org/ https://powerdmarc.com/what-is-dmarc-policy/ https://www.dmarcanalyzer.com/what-is-a-dmarc-policy/ and usage, Set Up OpenDMARC with Postfix on Ubuntu to Block Spam/Email Spoofing https://www.linuxbabe.com/mail-server/opendmarc-postfix-ubuntu
Re: Conditional milter_header_checks?
On Tue, Jul 13, 2021 at 06:06:16PM -0400, post...@ptld.com wrote: > > A DKIM signature does not imply any expectation that > > all messages will have valid signatures. > > Why does DKIM signature exist if not to provide a way to know if an > email has been altered after someone sent it? Why can't someone expect a > signature to be valid? I assume computers are capable of creating a > valid signature 100% of the time. DKIM authenticates the message origin (domain rather than a specific sender in most cases). The primary intent is to support whitelisting, and to allow contracted providers to leverage your sender reputation when sending messages on your behalf. Email transits multiple hops from sender to recipient, possibly undergoing various transformations en route. DKIM signatures are fragile, and can break for many reasons. Not all legitimate senders always send via a relay that is capable of signing their message. > > That's because DMARC (which I don't use or recommend) > > Why don't you recommend DMARC? What is wrong with it? DMARC does not solve any problem I care to have solved. IMHO its primary utility was to externalise Yahoo's abuse desk costs onto the community. > Do you accept *ALL* mail sent to you in your inbox spam or not? I reject some email from IP addresses with poor reputations, missing PTR records, ... but otherwise, yes all mail is delivered, and is then classified as junk or not by the mail client. I delete a dozen or so spam messages a day. > Other than SPF records and DMARC what other tools exist to verify if > mail came from the domain they purport to? Have you had previous contact with the sender? Is this the sort of message you expected from them? Does its timing or content raise any alarms? I don't care what path legitimate messages took to get to me, but for suspect messages, the path may confirm their lack of legitimacy. If I were to use SPF, DKIM, DMARC, ... I might then sometimes look at the Authentication-Results header for further clues, but presently I don't have any use for these. > > DKIM does not convey any policy, and the correct default policy is > > to treat invalid signatures the same way as you would treat missing > > signatures. > > Yes, DKIM is a signature, and DMARC is the policy that says if the > signature is invalid you are allowed to p=reject that mail. But you're > telling me at no time are you allowed to reject a message for an invalid > signature. Barring a DMARC policy, or some specific out-of-band knowledge about the sender domain, yes you should not reject mail either for lack of a signature or the presence of an invalid signature. https://datatracker.ietf.org/doc/html/rfc6376#page-51 > Im wondering if that is the case why does DKIM or DMARC exist? It makes it possible to assign a message reputation by origin domain. This facilitates delivery of legitimate bulk mail that users of large email systems actually signed up for, making it possible to allow in some mail that would otherwise be deemed junk when sent by a less scrupulous outfit. > Maybe i read it wrong but within DMARC policy isn't it allowed for > mail servers to have local policies that override the policy request > of what to do with invalid DKIM signatures? Sure, but a blaket reject on signature mismatch is specifically called out as a bad idea by the DKIM specification. > > You can break your system if you wish. For the record, nobody else > > should follow your example. > > How is giving end users the choice, the control, over what happens with > their email "breaking" my system? The choice you're offering them is a bad choice, and they're typically not well enough informed to make it wisely. You can implement DMARC, and then reject mail from domains that have "p=reject", at the cost of breaking some mailing lists, ... but absent such a DMARC policy, you should not apply a blanket "p=reject" for apparently signed DKIM messages with signatures that became invalid en-route. Valid DKIM signatures can make it easier to apply greater scrutiny to messages that lack a positive reputation, without incurring an excessive false positive rate. But you still need some real evidence that a message is likely junk before it is rejected. Mere DKIM "failure" isn't such evidence. -- Viktor.
Re: Conditional milter_header_checks?
The DKIM standards are quite emphatically clear that bad signature == no signature, and that receiving systems MUST NOT reject a message just because a signature is missing or fails to match. The treatment of messages that lack a signature is covered by DMARC (and ARC). It is a really bad idea to reject messages whose DKIM signature is invalid. DO NOT DO THIS. Why exactly is it a really bad idea :) ? Could you give us some more practical details/examples? It is true that DKIM does not convey a sender domain policy, but that should not limit or impose decision restriction on the receiving end. I don't see why should the receiver base its decisions of how to handle bad signatures on the wishes of the sender domain. By the way, I don't use DMARC. In my opinion if a signature is present is should be valid. Always. Otherwise it loses it's whole purpose. I wold even go so far as to require DKIM signatures from everybody. But unfortunately that is not quite possible since there are still many who, for various reasons, can't provide a DKIM signature at all :) . If a mail handling software, such as a mailing list one, changes a message in a way that breaks a signature, it should instead encapsulate the original message in a completely new message with a valid signature. If opendkim supports "On-BadSignature reject", that's a disservice to its users. Yes, OpenDKIM does support this and I find that to be perfectly fine since it gives the user an option to decide how to handle this kind of situations. By default the action is set to "accept" anyway. Cheers, K.
Re: Bypass postscreen
> 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 mail# vi access.cidr 10.0.1.0/24 permit 23.242.169.27/32permit 206.248.190.153/32 reject 123.108.97.201/32 reject 91.238.134.134/32 reject ~ mynetworks = 10.0.1.205, 10.0.1.230, 10.0.1.250, 10.0.1.200, 10.0.1.235, 127.0.0 .0/8 I figured the postscreen_access_List was the place, but I added the needed address with permit and did a postfix reload. It still blocked the desired email. Perhaps there was a typo somewhere, so I will run another set of tests and see what I get. -- Doug
Re: Conditional milter_header_checks?
On Tue, Jul 13, 2021 at 06:32:17PM -0400, Viktor Dukhovni wrote: > Valid DKIM signatures can make it easier to apply greater scrutiny to > messages that lack a positive reputation, without incurring an excessive > false positive rate. But you still need some real evidence that a > message is likely junk before it is rejected. Mere DKIM "failure" isn't > such evidence. > > -- > Viktor. And mere DKIM "success" on its own isn't much evidence of anything either. The other day, I received a surprisingly competent phishing email. All of the sender/reply addresses in the email itself were no-re...@amazon.ca but the DKIM header had: d=rks-cryptomining.com I assume it was validly signed with rks-cryptomining.com's key. But that has nothing to do with the sender email address as seen by the recipient. Not very reassuring. DMARC is supposed to solve that by requiring that the DKIM domain actually matches the sender email address domain. Neither DKIM nor SPF actually do that on their own. DKIM is only concerned with the DKIM domain (I think), and SPF is only concerned with the envelope sender domain. Neither say anything about the From: header which the recipient sees. Even if they did, many recipients probably only see the comment in the From: header, not the address itself. I don't know if DMARC tries to help with that. Note: I might be wrong about some of the above (haven't read the RFCs yet!) but it's what I've read elsewhere. Corrections are always welcome. I'm beginning to think that DKIM headers might be getting added just to improve spam detection scores. Perhaps I'm getting too cynical. :-) amazon.ca's DMARC policy only asks for a report when both DKIM and SPF fail. So maybe they wouldn't even get a report for such emails (not sure, I have to read the RFC). I strongly expect that it would constitute a DMARC+DKIM failure, even if it's a DKIM success. cheers, raf
Re: Conditional milter_header_checks?
On 2021-07-13 at 21:18:46 UTC-0400 (Wed, 14 Jul 2021 11:18:46 +1000) raf is rumored to have said: I'm beginning to think that DKIM headers might be getting added just to improve spam detection scores. Perhaps I'm getting too cynical. :-) That would not be very effective. For example: in Apache SpamAssassin, the presence of a valid DKIM signature has a net zero score. If it is valid and aligns with both the envelope sender and the From header address, it can net only -0.2 in a scoring system with a standard spam threshold of 5.0. That's not quite a meaningless benefit, but it is not substantial. -- 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 Tue, Jul 13, 2021 at 06:06:16PM -0400, post...@ptld.com wrote: > > A DKIM signature does not imply any expectation that > > all messages will have valid signatures. > > Why does DKIM signature exist if not to provide a way to know if an email > has been altered after someone sent it? That's not what it is for. There are ways to detect alteration in transit, but DKIM is not one of them. If alteration occurred, and part of the alteration was the removal of the DKIM header, you wouldn't know that it had been altered. So it's no good for that purpose. According to RFC6376: "(DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message" According to https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail: "(DKIM) is an email authentication method designed to detect forged sender addresses in email (email spoofing" But that doesn't sound correct to me. The "sender address" and the "signing domain" are not necessarily the same thing. The "signing domain" is the value of the "d" tag in the DKIM header. The "sender address" is the envelope sender and/or the address in the From: header. Even if the From: header is covered by the signature (which it will be), that's just saying that the signing domain is taking responsibility for the From: header. The signing domain can lie about the From: header, and then sign that lie. I've seen it done in phishing emails. But I think you might have misinterpreted the intent of the statement above (or I might have misinterpreted it). Saying that "A DKIM signature does not imply any expectation that all messages will have valid signatures" (to me) means that just because an email from a domain has a valid DKIM signature, that does not mean that all emails from that domain will or should have a DKIM header. DKIM doesn't make that claim. It's only DMARC that enables the sending domain to make that claim. > Why can't someone expect a signature to be valid? I assume computers > are capable of creating a valid signature 100% of the time. One example would be when an email with a DKIM header is sent to a mailing list. The mailing list distributes that message to its members, possibly leaving the existing DKIM header in place, rather than removing it or replacing it with a new DKIM header of its own. The mailing list members would then receive a DKIM header that might contain an invalid signature (depending on which headers the mailing list alters). Auto-forwarding of emails from one email account to another could conceivably also break the DKIM signature (depending on what headers are covered by the signature). It definitely breaks SPF validation. But in general, not all mail servers have been configured to produce DKIM headers at all. Those that haven't are not (yet) capable of producing a valid DKIM signature. Assuming that every mail server on the planet be configured for DKIM is presumptuous. Anything involving private keys is complicated, especially looking after them properly (See NIST SP 800-57 Parts 1-3). It's an onerous undertaking. > > That's because DMARC (which I don't use or recommed) > > Why don't you recommend DMARC? What is wrong with it? Do you accept *ALL* > mail sent to you in your inbox spam or not? Other than SPF records and DMARC > what other tools exist to verify if mail came from the domain they purport > to? I'm not an expert, but one thing I don't like about DMARC is not DMARC's fault. It's the way that it is mis-used by some corporate mail providers. At work, we were having our outgoing emails treated as spam by one client's third-party mail provider just because we didn't have SPF or DMARC. I refuse to believe that that's a correct implementation of either. :-) > > DKIM does not convey any policy, and the correct default policy is > > to treat invalid signatures the same way as you would treat missing > > signatures. > > Yes, DKIM is a signature, and DMARC is the policy that says if the signature > is invalid you are allowed to p=reject that mail. Not quite. You (the recipient mail server administrator) are only allowed to p=reject that mail if the sender's DMARC policy says to do that. If it says to q=quarantine that mail, then you can't reject it. You have to add an indication that it should be quarantined and deliver it to the actual recipient. If the DMARC policy does not say to reject or quarantine it, or if there is no DMARC policy at all, then you just deliver it as usual. It's not the recipient mail server's administrator's decision to reject the email. It's the sending domain's mail administrator's decision. The recipient mail server's administrator can ignore that decision if they want, but ignoring it should mean just delivering the mail. Otherwise, you'll have to deal with user complaints about where there mail has gone. The point is that DKIM on its own, and therefore OpenDKIM, is not the correct place to be reject
Re: Conditional milter_header_checks?
On Tue, Jul 13, 2021 at 10:35:15PM -0400, Bill Cole wrote: > On 2021-07-13 at 21:18:46 UTC-0400 (Wed, 14 Jul 2021 11:18:46 +1000) > raf > is rumored to have said: > > > I'm beginning to think that DKIM headers might be > > getting added just to improve spam detection scores. > > Perhaps I'm getting too cynical. :-) > > That would not be very effective. > > For example: in Apache SpamAssassin, the presence of a valid DKIM signature > has a net zero score. If it is valid and aligns with both the envelope > sender and the From header address, it can net only -0.2 in a scoring system > with a standard spam threshold of 5.0. That's not quite a meaningless > benefit, but it is not substantial. > > -- > Bill Cole > b...@scconsult.com or billc...@apache.org > (AKA @grumpybozo and many *@billmail.scconsult.com addresses) > Not Currently Available For Hire Thanks. That's good to know. I wonder why it was there, then. Could it really be to thwart a DMARC policy that only reports on SPF and DKIM both failing (which amazon.ca's does)? That can't work. My understanding is that for DMARC, the DKIM signing domain needs to match the sender domain (relaxed or strict). I really need to read the RFC. :-) Maybe it's just to fool human observers. That hardly seems worthwhile. I'm mystified. cheers, raf
Re: Conditional milter_header_checks?
On Wed, Jul 14, 2021 at 01:48:21AM +0300, Kevin N. wrote: > > It is a really bad idea to reject messages whose DKIM signature is invalid. > > DO NOT DO THIS. > > Why exactly is it a really bad idea :) ? > Could you give us some more practical details/examples? The point is that absent DMARC policy that promises DKIM signatures aligned with the RFC2822.From domain, there is no sane threat model in which rejecting invalid DKIM signatures yields any security benefit. An attacker (spammer if you like), can always sign the mail with some throw-away domain, or not sign it at all. So a failed DKIM signature conveys nothing other than perhaps an operator error on the legitimate sending system, or an unexpected message transformation in transit. No spammer wastes bandwidth sending messages with broken DKIM signatures, they either sign correctly, or don't sign at all. > In my opinion if a signature is present is should be valid. Always. > Otherwise it loses it's whole purpose. You can certainly take a pedantic view, that's contrary to the DKIM RFCs and common sense, there's no Internet police to stop you. Just keep in mind that rejecting failed DKIM signatures has no security benefit. Spammers are often early adopters of various email security standards. On some receiving systems there's a positive correlation between a message having a valid DKIM signature and the message being spam! > I wold even go so far as to require DKIM signatures from everybody. But > unfortunately that is not quite possible since there are still many who, > for various reasons, can't provide a DKIM signature at all :) . Your network, your rules. I am just trying to give rational advice. -- Viktor.
Re: policy_service protocol_state with smtpd_delay_reject
On Fri, Jul 09, 2021 at 02:07:02AM +0300, Kevin N. wrote: > > Is there a way to reuse the same instance of the script, not spawn two > > instances, and some how have the script know which restriction it was > > called from? > > Not sure if this helps, but maybe you could try to implement your policy > server as a standalone network server instead of calling it through the > spawn service. Agreed, this would be the appropriate implementation change. -- Viktor.
