Re: delay all email to a defined sender list
Viktor Dukhovni: > > > > On Sep 14, 2018, at 5:41 PM, Viktor Dukhovni > > wrote: > > > > Postfix 2.3-20051202 introduced conditionally compiled code for a "DELAY" > > access(5) action, but this never became a default-enabled feature. You'd > > need to compile Postfix with "-DDELAY_ACTION" to get it, and I don't know > > how recently this was last tested. It may no longer work, and perhaps was > > never ready for prime-time (otherwise might have made it as a standard > > feature into some release). > > The pertinent comment in the code is: > > +/* > + * The DELAY feature is disabled because it has too many problems. 1) It > + * does not work on some remote file systems; 2) mail will be delivered > + * anyway with "sendmail -q" etc.; 3) while the mail is queued it bogs > + * down the deferred queue scan with huge amounts of useless disk I/O > + * operations. > + */ > > These concerns are not insurmountable if the file-system is not uncooperative, > and the volume of delayed mail is small, but they do stand in the way of this > being a mainstream Postfix feature as-is. Would it be a problem to execute a 'HOLD' action, and this avoid the queue pollution problem? Wietse
Re: delay all email to a defined sender list
> On Sep 14, 2018, at 5:41 PM, Viktor Dukhovni > wrote: > > Postfix 2.3-20051202 introduced conditionally compiled code for a "DELAY" > access(5) action, but this never became a default-enabled feature. You'd > need to compile Postfix with "-DDELAY_ACTION" to get it, and I don't know > how recently this was last tested. It may no longer work, and perhaps was > never ready for prime-time (otherwise might have made it as a standard > feature into some release). The pertinent comment in the code is: +/* + * The DELAY feature is disabled because it has too many problems. 1) It + * does not work on some remote file systems; 2) mail will be delivered + * anyway with "sendmail -q" etc.; 3) while the mail is queued it bogs + * down the deferred queue scan with huge amounts of useless disk I/O + * operations. + */ These concerns are not insurmountable if the file-system is not uncooperative, and the volume of delayed mail is small, but they do stand in the way of this being a mainstream Postfix feature as-is. -- Viktor.
Re: delay all email to a defined sender list
> On Sep 14, 2018, at 4:51 PM, Bill Cole > wrote: > >> It happened just one time too many today, in a rushed moment >> sending the wrong email to the wrong person. >> >> Is it possible to exclusively delay sending mail to specific >> recipients that appear on in a list? > > That is logically a feature that belongs in a mail client, not a mail server. > Postfix offers no direct way to do anything like it. > > An indirect way to implement something like that would be to add a > check_recipient_access restriction with a list of addresses mapped to HOLD. > You could then either manually or in an automated way run "postsuper -H ALL" > to release the held mail or write something more complicated to selectively > un-hold messages based on age. Postfix 2.3-20051202 introduced conditionally compiled code for a "DELAY" access(5) action, but this never became a default-enabled feature. You'd need to compile Postfix with "-DDELAY_ACTION" to get it, and I don't know how recently this was last tested. It may no longer work, and perhaps was never ready for prime-time (otherwise might have made it as a standard feature into some release). -- Viktor.
Re: delay all email to a defined sender list
On 14 Sep 2018, at 16:00, Eric Smith wrote: Hi List, It happened just one time too many today, in a rushed moment sending the wrong email to the wrong person. Is it possible to exclusively delay sending mail to specific recipients that appear on in a list? That is logically a feature that belongs in a mail client, not a mail server. Postfix offers no direct way to do anything like it. An indirect way to implement something like that would be to add a check_recipient_access restriction with a list of addresses mapped to HOLD. You could then either manually or in an automated way run "postsuper -H ALL" to release the held mail or write something more complicated to selectively un-hold messages based on age. This way I suspected such an error of an email to one the special recipients, then I could still delete the email from the queue.
delay all email to a defined sender list
Hi List, It happened just one time too many today, in a rushed moment sending the wrong email to the wrong person. Is it possible to exclusively delay sending mail to specific recipients that appear on in a list? This way I suspected such an error of an email to one the special recipients, then I could still delete the email from the queue. Best Eric
Re: reject_unverified_recipient and /ect/aliases delay/issue
Wietse Venema: > Stefan Bauer: > > Am Freitag, 14. September 2018 schrieb Wietse Venema : > > > Stefan Bauer: > > >> verify_cache.db seems to get corrupted or at least not updated properly > > as > > >> new/updated entries do not get correctly verified and postfix logs: > > >> > > >> close database /var/lib/postfix/verify_cache.db: No such file or > > directory > > >> > (possible Berkeley DB bug > > > > > > That is logged after 'postfix reload", and until now has not been > > > a problem. The warnming is logged just to be sure, because people > > > keep imprving Berkeley DB. > > > > > >> only a postfix stop, rm verify_cache* , postfix start helps. > > > > > > That is complete and utter overkill. > > > > so what else is recommended to update the db to have recent data? > > Perhaps use the configurable features to control caching of 'negative' > results: > > address_verify_negative_cache = yes > address_verify_negative_expire_time = 3d > address_verify_negative_refresh_time = 3h > > The 'negative' results are cached to avoid overloading the server > with address verify messages. > > I guess that some people can wait for 5 minutes until the negative > cache result has expired? Note that there is a subtle difference between _expire_time and _refresh_time. The verify daemon will return the cached result, and if a refresh is needed, it will request new address verify probe for the email address. The probe completes in the background, and will at some time later overwrite the cached negative result. Wietse
Re: reject_unverified_recipient and /ect/aliases delay/issue
Stefan Bauer: > Am Freitag, 14. September 2018 schrieb Wietse Venema : > > Stefan Bauer: > >> verify_cache.db seems to get corrupted or at least not updated properly > as > >> new/updated entries do not get correctly verified and postfix logs: > >> > >> close database /var/lib/postfix/verify_cache.db: No such file or > directory > >> > (possible Berkeley DB bug > > > > That is logged after 'postfix reload", and until now has not been > > a problem. The warnming is logged just to be sure, because people > > keep imprving Berkeley DB. > > > >> only a postfix stop, rm verify_cache* , postfix start helps. > > > > That is complete and utter overkill. > > so what else is recommended to update the db to have recent data? Perhaps use the configurable features to control caching of 'negative' results: address_verify_negative_cache = yes address_verify_negative_expire_time = 3d address_verify_negative_refresh_time = 3h The 'negative' results are cached to avoid overloading the server with address verify messages. I guess that some people can wait for 5 minutes until the negative cache result has expired? Wietse
Re: reject_unverified_recipient and /ect/aliases delay/issue
On 9/14/2018 12:41 PM, Stefan Bauer wrote: > > > Am Freitag, 14. September 2018 schrieb Wietse Venema : >> Stefan Bauer: >>> verify_cache.db seems to get corrupted or at least not updated > properly as >>> new/updated entries do not get correctly verified and postfix logs: >>> >>> close database /var/lib/postfix/verify_cache.db: No such file or > directory >>> > (possible Berkeley DB bug >> >> That is logged after 'postfix reload", and until now has not been >> a problem. The warnming is logged just to be sure, because people >> keep imprving Berkeley DB. >> >>> only a postfix stop, rm verify_cache* , postfix start helps. >> >> That is complete and utter overkill. > > so what else is recommended to update the db to have recent data? You don't need to do anything other than run newaliases. Postfix will automatically use the changed the aliases map, so reload is unnecessary. The error on closing the database (caused by postfix reload) is an artifact of Berkeley DB and can be ignored; it does no harm. With your environment, you'll likely see that message every time postfix stops or reloads. -- Noel Jones
Re: reject_unverified_recipient and /ect/aliases delay/issue
Am Freitag, 14. September 2018 schrieb Wietse Venema : > Stefan Bauer: >> verify_cache.db seems to get corrupted or at least not updated properly as >> new/updated entries do not get correctly verified and postfix logs: >> >> close database /var/lib/postfix/verify_cache.db: No such file or directory >> > (possible Berkeley DB bug > > That is logged after 'postfix reload", and until now has not been > a problem. The warnming is logged just to be sure, because people > keep imprving Berkeley DB. > >> only a postfix stop, rm verify_cache* , postfix start helps. > > That is complete and utter overkill. so what else is recommended to update the db to have recent data?
Re: reject_unverified_recipient and /ect/aliases delay/issue
Stefan Bauer: > verify_cache.db seems to get corrupted or at least not updated properly as > new/updated entries do not get correctly verified and postfix logs: > > close database /var/lib/postfix/verify_cache.db: No such file or directory > > (possible Berkeley DB bug That is logged after 'postfix reload", and until now has not been a problem. The warnming is logged just to be sure, because people keep imprving Berkeley DB. > only a postfix stop, rm verify_cache* , postfix start helps. That is complete and utter overkill. By the same reasoning you could claim that it was necessary to reboot the machine, reinstall the OS, and order new hardware. Wietse
reject_unverified_recipient and /ect/aliases delay/issue
Hi, we use reject_unverified_recipient and have alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases after changes in aliases and issuing postalias /etc/aliases verify_cache.db seems to get corrupted or at least not updated properly as new/updated entries do not get correctly verified and postfix logs: close database /var/lib/postfix/verify_cache.db: No such file or directory > (possible Berkeley DB bug only a postfix stop, rm verify_cache* , postfix start helps. are there known limitations?
Re: Stop sasl mail submission on port 25
Hi Fantomas, It's very kind of you for all the details of your answer. I would like just a bit more information. 1. If I change "smtpd_sasl_auth_enable=yes" in main.cf, Is there any issue with "smtpd_sasl_security_options = noanonymous" ? This option will be apply to submission and smtps in master.cf ? 2. In master.cf, what "-o milter_macro_daemon_name=ORIGINATING" is ? Is it with my postfix 2.5.5 compatible ? Best regards -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
FW: RE: Double-Bounce
In order of messages. ( i got 11 message for 1 postfix list mail ). I only see this these when . 1) someone tries to mail out of my domainname. 2) when i mail the postfix list. I never figured this out, why this happens at the postfix list. This is an authentication failure report for an email message received from IP 168.100.1.3 on Fri, 14 Sep 2018 11:11:03 +0200 (CEST). This is a spf/dkim authentication-failure report for an email message received from IP 2604:8d00:0:1::3 on Fri, 14 Sep 2018 11:10:56 +0200. This is an authentication failure report for an email message received from IP 168.100.1.3 on Fri, 14 Sep 2018 05:11:04 -0400 (EDT). This is an authentication failure report for an email message received from IP 168.100.1.3 on Fri, 14 Sep 2018 11:11:19 +0200 (CEST). This is a spf/dkim authentication-failure report for an email message received from IP 168.100.1.3 on Fri, 14 Sep 2018 11:11:32 +0200. This is an authentication failure report for an email message received from IP 168.100.1.3 on Fri, 14 Sep 2018 05:11:41 -0400 (EDT). This is an authentication failure report for an email message received from IP 168.100.1.3 on Fri, 14 Sep 2018 09:11:40 + (UTC). This is an authentication failure report for an email message received from IP 168.100.1.3 on Fri, 14 Sep 2018 05:11:47 -0400 (EDT). This is an authentication failure report for an email message received from IP 129.97.167.82 on Fri, 14 Sep 2018 05:11:56 -0400 (EDT). This is an authentication failure report for an email message received from IP 129.97.167.82 on Fri, 14 Sep 2018 05:11:56 -0400 (EDT). This is a spf/dkim authentication-failure report for an email message received from IP 2604:8d00:0:1::3 on Fri, 14 Sep 2018 11:10:56 +0200. This is a spf/dkim authentication-failure report for an email message received from IP 168.100.1.3 on Fri, 14 Sep 2018 11:11:32 +0200.
Re: Double-Bounce
On 2018-09-14 11:11, Benny Pedersen wrote: B. Reino skrev den 2018-09-14 10:52: So in a way this message is just a test, but hopefully also a clarification :) Authentication-Results: linode.junc.eu; dkim=fail reason="signature verification failed" (1024-bit key) header.d=bbmk.org header.i=@bbmk.org header.b=I6ED3eZq; do not sign all headers :) I was just using the default in rspamd. After failing this time and removing the Sender header I think my messages to the list are now being validated OK. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbmk.org; s=default; t=1536915126; h=from:from:sender:subject:subject:date:date:to:to:cc: in-reply-to:in-reply-to:references:references; 2 header lines with from ? 2 header lines with subject ? 2 header lines with references ? DKIM Oversigning (https://tools.ietf.org/html/rfc6376#section-5.4.2) Should not hurt, but I might remove that as well.. Cheers and thanks a lot.
Re: Double-Bounce
B. Reino skrev den 2018-09-14 11:02: Well I guess the above test failed :( Authentication-Results: linode.junc.eu; dmarc=pass (p=none dis=none) header.from=bbmk.org Authentication-Results: linode.junc.eu; dkim=pass (1024-bit key) header.d=bbmk.org header.i=@bbmk.org header.b=sOJs04Hw; dkim-atps=neutral I forgot to exclude the "Sender:" header as well. +1 This is however my last test. I don't want to spam the list. no need to sorry, dont fix it now :=)
Re: Double-Bounce
B. Reino skrev den 2018-09-14 10:52: So in a way this message is just a test, but hopefully also a clarification :) Authentication-Results: linode.junc.eu; dkim=fail reason="signature verification failed" (1024-bit key) header.d=bbmk.org header.i=@bbmk.org header.b=I6ED3eZq; do not sign all headers :) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbmk.org; s=default; t=1536915126; h=from:from:sender:subject:subject:date:date:to:to:cc: in-reply-to:in-reply-to:references:references; 2 header lines with from ? 2 header lines with subject ? 2 header lines with references ? bugs
RE: Double-Bounce
I had a simular things. .. Waiting for the bounce... Greetz, Louis > -Oorspronkelijk bericht- > Van: rei...@bbmk.org [mailto:owner-postfix-us...@postfix.org] > Namens B. Reino > Verzonden: vrijdag 14 september 2018 10:52 > Aan: postfix-users@postfix.org > Onderwerp: Re: Double-Bounce > > On 2018-09-14 10:36, Dominic Raferd wrote: > > > On Fri, 14 Sep 2018 at 07:14, Benny Pedersen wrote: > > > >> Benny Pedersen skrev den 2018-09-14 08:08: > >>> Dominic Raferd skrev den 2018-09-14 07:33: > On Fri, 14 Sep 2018 at 00:29, Julian Opificius > > wrote: > > > > Why is it that my system marks everything from you as > spam, Benny? > > Is > > it > > your tld? I've added you to my address book, but my server keeps > > spitting you out. > > Because the domain that he uses to send emails through > this mailing > list has DMARC p=quarantine setting: > # dig +short _dmarc.junc.eu TXT > "v=DMARC1; p=quarantine; > rua=mailto:report_...@dmarc.junc.eu; fo=d; > adkim=r; aspf=r; sp=none" > >>> > >>> postfix maillist is dkim safe, so if it breaks, show the link that > >>> breaks it, whitelist postfix maillist so it does not go into > >>> quarantine > >>> > >>> can i help more ? > >>> > >>> i get dmarc pass back on my post here > >> > >> DMARC-Filter: OpenDMARC Filter v1.3.2 linode.junc.eu 2C5B31BE06F > >> Authentication-Results: linode.junc.eu; dmarc=pass (p=quarantine > >> dis=none) header.from=junc.eu > >> Authentication-Results: linode.junc.eu; > >> dkim=pass (1024-bit key) header.d=junc.eu header.i=@junc.eu > >> header.b=Aedk3uHj; > >> dkim-atps=neutral > >> Received-SPF: none (postfix.org: No applicable sender policy > >> available) > >> receiver=localhost.junc.eu; identity=mailfrom; > >> envelope-from="owner-postfix-us...@postfix.org"; > >> helo=russian-caravan.cloud9.net; client-ip="2604:8d00:0:1::4" > > > > Sorry you are right: your emails pass DKIM and also, when > going through > > postfix mailing list (but not all others), pass DKIM > alignment, so they > > pass DMARC. However, when sent through mailing lists, they > fail SPF, > > and (for DMARC) SPF alignment, so servers that make decisions based > > only on this (which is not the DMARC way) may choose to > treat them as > > spam. Mine don't, but I have seen your emails quarantined (or, > > previously, blocked) on other mailing lists, hence my > original comment. > > I think the postfix ML is not so "DKIM safe". In my case, it > causes my > DKIM signature to fail. I have now compared a message sent by > me against > other messages sent e.g. by Benny Pedersen, and concluded that my > configuration (using rspamd) was signing way too many fields. > I have now > reduced the number of fields and hopefully this message > should now come > back from the postfix ML with a valid DKIM signature. > > So in a way this message is just a test, but hopefully also a > clarification :) > > Cheers, > Bernardo Reino. > >
Re: Double-Bounce
On 2018-09-14 10:52, B. Reino wrote: I think the postfix ML is not so "DKIM safe". In my case, it causes my DKIM signature to fail. I have now compared a message sent by me against other messages sent e.g. by Benny Pedersen, and concluded that my configuration (using rspamd) was signing way too many fields. I have now reduced the number of fields and hopefully this message should now come back from the postfix ML with a valid DKIM signature. So in a way this message is just a test, but hopefully also a clarification :) Cheers, Bernardo Reino. Well I guess the above test failed :( I forgot to exclude the "Sender:" header as well. This is however my last test. I don't want to spam the list. Sorry and cheers, -- Bernardo Reino.
Re: Double-Bounce
On 2018-09-14 10:36, Dominic Raferd wrote: On Fri, 14 Sep 2018 at 07:14, Benny Pedersen wrote: Benny Pedersen skrev den 2018-09-14 08:08: Dominic Raferd skrev den 2018-09-14 07:33: On Fri, 14 Sep 2018 at 00:29, Julian Opificius wrote: Why is it that my system marks everything from you as spam, Benny? Is it your tld? I've added you to my address book, but my server keeps spitting you out. Because the domain that he uses to send emails through this mailing list has DMARC p=quarantine setting: # dig +short _dmarc.junc.eu TXT "v=DMARC1; p=quarantine; rua=mailto:report_...@dmarc.junc.eu; fo=d; adkim=r; aspf=r; sp=none" postfix maillist is dkim safe, so if it breaks, show the link that breaks it, whitelist postfix maillist so it does not go into quarantine can i help more ? i get dmarc pass back on my post here DMARC-Filter: OpenDMARC Filter v1.3.2 linode.junc.eu 2C5B31BE06F Authentication-Results: linode.junc.eu; dmarc=pass (p=quarantine dis=none) header.from=junc.eu Authentication-Results: linode.junc.eu; dkim=pass (1024-bit key) header.d=junc.eu header.i=@junc.eu header.b=Aedk3uHj; dkim-atps=neutral Received-SPF: none (postfix.org: No applicable sender policy available) receiver=localhost.junc.eu; identity=mailfrom; envelope-from="owner-postfix-us...@postfix.org"; helo=russian-caravan.cloud9.net; client-ip="2604:8d00:0:1::4" Sorry you are right: your emails pass DKIM and also, when going through postfix mailing list (but not all others), pass DKIM alignment, so they pass DMARC. However, when sent through mailing lists, they fail SPF, and (for DMARC) SPF alignment, so servers that make decisions based only on this (which is not the DMARC way) may choose to treat them as spam. Mine don't, but I have seen your emails quarantined (or, previously, blocked) on other mailing lists, hence my original comment. I think the postfix ML is not so "DKIM safe". In my case, it causes my DKIM signature to fail. I have now compared a message sent by me against other messages sent e.g. by Benny Pedersen, and concluded that my configuration (using rspamd) was signing way too many fields. I have now reduced the number of fields and hopefully this message should now come back from the postfix ML with a valid DKIM signature. So in a way this message is just a test, but hopefully also a clarification :) Cheers, Bernardo Reino.
Re: Double-Bounce
On Fri, 14 Sep 2018 at 07:14, Benny Pedersen wrote: > Benny Pedersen skrev den 2018-09-14 08:08: > > Dominic Raferd skrev den 2018-09-14 07:33: > >> On Fri, 14 Sep 2018 at 00:29, Julian Opificius > >> wrote: > >>> > >>> Why is it that my system marks everything from you as spam, Benny? Is > >>> it > >>> your tld? I've added you to my address book, but my server keeps > >>> spitting you out. > >> > >> Because the domain that he uses to send emails through this mailing > >> list has DMARC p=quarantine setting: > >> # dig +short _dmarc.junc.eu TXT > >> "v=DMARC1; p=quarantine; rua=mailto:report_...@dmarc.junc.eu; fo=d; > >> adkim=r; aspf=r; sp=none" > > > > postfix maillist is dkim safe, so if it breaks, show the link that > > breaks it, whitelist postfix maillist so it does not go into > > quarantine > > > > can i help more ? > > > > i get dmarc pass back on my post here > > DMARC-Filter: OpenDMARC Filter v1.3.2 linode.junc.eu 2C5B31BE06F > Authentication-Results: linode.junc.eu; dmarc=pass (p=quarantine > dis=none) header.from=junc.eu > Authentication-Results: linode.junc.eu; > dkim=pass (1024-bit key) header.d=junc.eu header.i=@junc.eu > header.b=Aedk3uHj; > dkim-atps=neutral > Received-SPF: none (postfix.org: No applicable sender policy available) > receiver=localhost.junc.eu; identity=mailfrom; > envelope-from="owner-postfix-us...@postfix.org"; > helo=russian-caravan.cloud9.net; client-ip="2604:8d00:0:1::4" > Sorry you are right: your emails pass DKIM and also, when going through postfix mailing list (but not all others), pass DKIM alignment, so they pass DMARC. However, when sent through mailing lists, they fail SPF, and (for DMARC) SPF alignment, so servers that make decisions based only on this (which is not the DMARC way) may choose to treat them as spam. Mine don't, but I have seen your emails quarantined (or, previously, blocked) on other mailing lists, hence my original comment.
Re: Stop sasl mail submission on port 25
On 13.09.18 17:51, edg973 wrote: Unfortunatly, in my config, there is in main.cf: smtpd_sasl_auth_enable = yes change this to "no" In master.cf, there is : smtp inet n - - - - smtpd -o content_filter=spamassassin smtps inetn - n - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes 1. where is "submission"? 2. you should modify this according to what Wietse sent: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING smtps inet n - n - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING note the leading spaces in the "-o" lines. The proposed smtps service contains the same options as you already have so you won't lose anything. Also note that both services here require encryption (good) and disable sending mail without authentication (good). My goal would be to get : port 25 : normal internet mail reception (no sasl authentication) port 465 : smtps with sasl authentication port 587 : submission with sasl authentication Why "smtpd_sasl_auth_enable settings in main.cf" could not allowing this ? "smtpd_sasl_auth_enable=yes" in main.cf enables sasl authentication globally, which you don't want. That's why you should turn it off and only enable it explicitly for submission and smtps services. It's better to configure postfix according to proposed config, so you don't have too many changes when upgrading later. -- 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. Nothing is fool-proof to a talented fool.
Re: Double-Bounce
Benny Pedersen skrev den 2018-09-14 08:08: Dominic Raferd skrev den 2018-09-14 07:33: On Fri, 14 Sep 2018 at 00:29, Julian Opificius wrote: Why is it that my system marks everything from you as spam, Benny? Is it your tld? I've added you to my address book, but my server keeps spitting you out. Because the domain that he uses to send emails through this mailing list has DMARC p=quarantine setting: # dig +short _dmarc.junc.eu TXT "v=DMARC1; p=quarantine; rua=mailto:report_...@dmarc.junc.eu; fo=d; adkim=r; aspf=r; sp=none" postfix maillist is dkim safe, so if it breaks, show the link that breaks it, whitelist postfix maillist so it does not go into quarantine can i help more ? i get dmarc pass back on my post here DMARC-Filter: OpenDMARC Filter v1.3.2 linode.junc.eu 2C5B31BE06F Authentication-Results: linode.junc.eu; dmarc=pass (p=quarantine dis=none) header.from=junc.eu Authentication-Results: linode.junc.eu; dkim=pass (1024-bit key) header.d=junc.eu header.i=@junc.eu header.b=Aedk3uHj; dkim-atps=neutral Received-SPF: none (postfix.org: No applicable sender policy available) receiver=localhost.junc.eu; identity=mailfrom; envelope-from="owner-postfix-us...@postfix.org"; helo=russian-caravan.cloud9.net; client-ip="2604:8d00:0:1::4"
Re: Double-Bounce
Dominic Raferd skrev den 2018-09-14 07:33: On Fri, 14 Sep 2018 at 00:29, Julian Opificius wrote: Why is it that my system marks everything from you as spam, Benny? Is it your tld? I've added you to my address book, but my server keeps spitting you out. Because the domain that he uses to send emails through this mailing list has DMARC p=quarantine setting: # dig +short _dmarc.junc.eu TXT "v=DMARC1; p=quarantine; rua=mailto:report_...@dmarc.junc.eu; fo=d; adkim=r; aspf=r; sp=none" postfix maillist is dkim safe, so if it breaks, show the link that breaks it, whitelist postfix maillist so it does not go into quarantine can i help more ? i get dmarc pass back on my post here
