Re: Amavis and OpenDMARC

2023-12-06 Thread Noel Butler

On 03/12/2023 00:54, Matus UHLAR - fantomas wrote:


DMARC doesn't say that SPF must be aligned with From:.
It only says that SPF can only be used if envelope from is aligned with 
header From:.


if you use _relaxed_ only _one_ need pass so why if you use _relaxed_ 
would you expect it to mail you if they dont match, if you want full 
alignment I guess trying _simple_ :)


Incorrect.
"relaxed" in DMARC allows subdomains matching, "strict" does not.

Neither is related to different domain in envelope vs. headers.

And neither says if both SPF and DKIM must match.


(thats fo=0) but...

I was talking about S P F matching

Thats my final word on the subject because again repeating repeating, my 
reading/interpretation works as I read and expect over a great number of 
years, if yours differs, well your network is your network not mine so 
do as you please, you've been round many years too so I'm sure you have 
your systems running happily the way you want it, if you want a 
definitive response on whats what go ask the current RFC authors.


I am on leave as of tonight and since I've already answered the rest in 
this drawn out thread I will be enjoying family company and not those of 
lists (this is a lists-only email & not "personal" addy)/forums/irc/nor 
usenet for next four weeks unless that damn cyclone interferes with my 
plans :)


Happy Holidays

--
Regards,
Noel Butler

Re: Amavis and OpenDMARC

2023-12-02 Thread Matus UHLAR - fantomas

On 21.11.23 12:06, Noel Butler wrote:
But they are inter-twined, 
DMARC just does what DKIM and SPF declare, so any perceived DMARC 
issues *do* include DKIM and SPF



On 28/11/2023 19:45, Matus UHLAR - fantomas wrote:
but this is irelevant here.


On 02.12.23 13:25, Noel Butler wrote:

We will have to agree to disagree


okay...


Not "a pass and a failure". A DKIM pass and SPF pass.

But when the SPF is not aligned, DMARC wording requires sending 
report for "fo=1", because of RFC something other than an 
aligned "pass" result.


I think this thread is coming to an end as we seem to be going round 
in circle


...all the time I'm trying to find out whether my claim is valid or not.

Unfortunately, they're different claims brought instead all the time.


SPF _alignment_ is governed by your DMARC policy


DMARC doesn't say that SPF must be aligned with From:.
It only says that SPF can only be used if envelope from is aligned with 
header From:.


if you 
use _relaxed_ only _one_ need pass so why if you use _relaxed_ would 
you expect it to mail you if they dont match, if you want full 
alignment I guess trying _simple_ :)


Incorrect.
"relaxed" in DMARC allows subdomains matching, "strict" does not.

Neither is related to different domain in envelope vs. headers.

And neither says if both SPF and DKIM must match.


So, generally do you recommend us not to follow RFC and risk 
possible issues that are currently unseen?

I prefer fixing the RFC instead.


I think the RFC overall is fine maybe some wording could be changed 
but its really cosmetic, and Scott K posted what to do if you think it 
needs changing, but for that you will need an abundance of evidence to 
support any changes I think.


--
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.
BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease


Re: Amavis and OpenDMARC

2023-12-01 Thread Noel Butler

On 28/11/2023 19:45, Matus UHLAR - fantomas wrote:

On 21.11.23 12:06, Noel Butler wrote: But they are inter-twined, DMARC 
just does what DKIM and SPF declare, so any perceived DMARC issues *do* 
include DKIM and SPF


but this is irelevant here.

We will have to agree to disagree


Not "a pass and a failure". A DKIM pass and SPF pass.

But when the SPF is not aligned, DMARC wording requires sending report 
for "fo=1", because of RFC something other than an aligned "pass" 
result.


I think this thread is coming to an end as we seem to be going round in 
circles, SPF _alignment_ is governed by your DMARC policy, if you use 
_relaxed_ only _one_ need pass so why if you use _relaxed_ would you 
expect it to mail you if they dont match, if you want full alignment I 
guess trying _simple_ :)


So, generally do you recommend us not to follow RFC and risk possible 
issues that are currently unseen?

I prefer fixing the RFC instead.


I think the RFC overall is fine maybe some wording could be changed but 
its really cosmetic, and Scott K posted what to do if you think it needs 
changing, but for that you will need an abundance of evidence to support 
any changes I think.


--
Regards,
Noel Butler

Re: Amavis and OpenDMARC

2023-11-28 Thread Matus UHLAR - fantomas

I agree that DKIM designers messed this up quite much.
But again, we are here talking about DMARC.



On 21.11.23 12:06, Noel Butler wrote:
But they are inter-twined, DMARC just does what DKIM and SPF declare, 
so any perceived DMARC issues *do* include DKIM and SPF


but this is irelevant here.


On 21/11/2023 20:08, Matus UHLAR - fantomas wrote:

I believe the issue lies in bad formulation of condition for fo:


The problem I see is that with "fo=1" it should be reported, even if 
everything is okay.


On 28.11.23 10:36, Noel Butler wrote:

Well, if there is a pass and a failure not "everything" is OK.


Not "a pass and a failure". A DKIM pass and SPF pass.

But when the SPF is not aligned, DMARC wording requires sending report for 
"fo=1", because of RFC 
	something other than an aligned "pass" result.


reporting 2 passes but inaligned is non-sense and quite common for mail 
forwarding, and mailing lists, including this one.


Perhaps RFC 7489 needs clarification of what exactly needs to be 
reported and what not.


7489  makes fo=1|s|d clear, perhaps fo=0 could be worded differently, 


most of us, or perhaps just many of us,  understand 0 means only if 


I did a mistake before and corrected it:

Wording of fo=0 is fine, report is only send for failed DMARC check.
The unaligned SPF is only issue when DKIM fails.


everything fails then send a report because thats how I see it and how 
it seemed to work when first ran DMARC until I moved fo=1 because I 
want to get failure reports - remember, not all failure reports go to 
humans ;)


Generally people who halve some idea of what they are doing don't 
bother with RFC's, perhaps the problem is with the software 
documentation as that's what they tend to go for.


So, generally do you recommend us not to follow RFC and risk possible issues 
that are currently unseen?

I prefer fixing the RFC instead.

--
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.
My mind is like a steel trap - rusty and illegal in 37 states.


Re: Amavis and OpenDMARC

2023-11-27 Thread Scott Kitterman



On November 28, 2023 12:36:11 AM UTC, Noel Butler  
wrote:
>On 21/11/2023 20:08, Matus UHLAR - fantomas wrote:
>
>> On 21.11.23 12:06, Noel Butler wrote:
>> 
>>> This also depends on how you set DKIM's canonicalization
>> 
>> this is a (known) problem of DKIM and playing with DMARC will not solve it.
>> 
>>> Anyone using simple/simple should have a DKIM fail and plenty use that 
>>> setting, prior to July this year - when I was using this address on file 
>>> with Federal Law Enforcement agencies for receiving shall we say certain 
>>> formal requests ;) I used fully strict with simple/simple - as earlier 
>>> posts on this list would show
>> 
>> I agree that DKIM designers messed this up quite much.
>> But again, we are here talking about DMARC.
>
>But they are inter-twined, DMARC just does what DKIM and SPF declare, so any 
>perceived DMARC issues *do* include DKIM and SPF
>
>> I believe the issue lies in bad formulation of condition for fo:
>
>> The problem I see is that with "fo=1" it should be reported, even if 
>> everything is okay.
>
>Well, if there is a pass and a failure not "everything" is OK.
>Of all DMARC notices I've had its because DKIM failed, and thankfully for me 
>at least all of them are list based, its when I start seeing them for non list 
>posts that I'll sit up and take notice.
>
>> Perhaps RFC 7489 needs clarification of what exactly needs to be reported 
>> and what not.
>
>7489  makes fo=1|s|d clear, perhaps fo=0 could be worded differently, most of 
>us, or perhaps just many of us,  understand 0 means only if everything fails 
>then send a report because thats how I see it and how it seemed to work when 
>first ran DMARC until I moved fo=1 because I want to get failure reports - 
>remember, not all failure reports go to humans ;)
>
>Generally people who halve some idea of what they are doing don't bother with 
>RFC's, perhaps the problem is with the software documentation as that's what 
>they tend to go for.
>
An IETF revision to RFC 7489 is pretty far advanced.  Anyone can contribute to 
the work if you think it needs improvement:

https://datatracker.ietf.org/wg/dmarc/documents/

Scott K


Re: Amavis and OpenDMARC

2023-11-27 Thread Noel Butler

On 21/11/2023 20:08, Matus UHLAR - fantomas wrote:


On 21.11.23 12:06, Noel Butler wrote:


This also depends on how you set DKIM's canonicalization


this is a (known) problem of DKIM and playing with DMARC will not solve 
it.


Anyone using simple/simple should have a DKIM fail and plenty use that 
setting, prior to July this year - when I was using this address on 
file with Federal Law Enforcement agencies for receiving shall we say 
certain formal requests ;) I used fully strict with simple/simple - as 
earlier posts on this list would show


I agree that DKIM designers messed this up quite much.
But again, we are here talking about DMARC.


But they are inter-twined, DMARC just does what DKIM and SPF declare, so 
any perceived DMARC issues *do* include DKIM and SPF



I believe the issue lies in bad formulation of condition for fo:


The problem I see is that with "fo=1" it should be reported, even if 
everything is okay.


Well, if there is a pass and a failure not "everything" is OK.
Of all DMARC notices I've had its because DKIM failed, and thankfully 
for me at least all of them are list based, its when I start seeing them 
for non list posts that I'll sit up and take notice.


Perhaps RFC 7489 needs clarification of what exactly needs to be 
reported and what not.


7489  makes fo=1|s|d clear, perhaps fo=0 could be worded differently, 
most of us, or perhaps just many of us,  understand 0 means only if 
everything fails then send a report because thats how I see it and how 
it seemed to work when first ran DMARC until I moved fo=1 because I want 
to get failure reports - remember, not all failure reports go to humans 
;)


Generally people who halve some idea of what they are doing don't bother 
with RFC's, perhaps the problem is with the software documentation as 
that's what they tend to go for.


--
Regards,
Noel Butler

Re: Amavis and OpenDMARC

2023-11-21 Thread Matus UHLAR - fantomas

On 16/11/2023 18:47, Matus UHLAR - fantomas wrote:
Keeping header From: and DKIM signatures is perfectly fine, if ML 
does not modify the mail, which afaik is the default setting.


On 21.11.23 12:06, Noel Butler wrote:

This also depends on how you set DKIM's canonicalization


this is a (known) problem of DKIM and playing with DMARC will not solve it.

Anyone using simple/simple should have a DKIM fail and plenty use that 
setting, prior to July this year - when I was using this address on 
file with Federal Law Enforcement agencies for receiving shall we say 
certain formal requests ;) I used fully strict with simple/simple - as 
earlier posts on this list would show


I agree that DKIM designers messed this up quite much.
But again, we are here talking about DMARC.


I believe the issue lies in bad formulation of condition for fo:

1: Generate a DMARC failure report if any underlying
authentication mechanism produced something other than an
aligned "pass" result.


I've never had an fo=1 SPF failure report, because DKIM would pass, 


Do you think the part of RFC as different meaning as I described?
Or do people/SW simply ignore the "fo=1" setting when DKIM passes and don't 
report unaligned SPF, thus ignore it?



...I understand this as SPF unaligned with header From: should be 
reported for domain in header From:.


SPF should only check and report on envelope-sender/return-path, if 
and only if that does not exist it should use the EHLO domain, it 
should not care about From, last time I looked - a decade or so ago - 
it never did, but lets try something...


"aligned" in the DMARC meaning that envelope from: and header from: is the 
same.  If it's not the same, it's called "unaligned".

Unaligned SPF is not important if the DKIM passes.

The problem I see is that with "fo=1" it should be reported, even if 
everything is okay.



It makes sense to report missing/unaligned DKIM.


Then set fo=d  :)


with "fo=d" SPF failure is not to be reported, only invalid DKIM.

with "fo=s" SPF failure is to be reported, not DKIM 



with "fo=1" DKIM failure is reported, but also unaligned SPF pass.

Generally that means, that with "fo=1" not only failures, but even successes 
would be reported, if the SPF is not aligned.




Perhaps this could be avoided by using "fo=d; fo=s;" in DMARC record, which 
I'm not sure if correct (quick




Perhaps RFC 7489 needs clarification of what exactly needs to be reported 
and what not.




--
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.
You have the right to remain silent. Anything you say will be misquoted,
then used against you.


Re: Amavis and OpenDMARC

2023-11-20 Thread Noel Butler

On 16/11/2023 18:47, Matus UHLAR - fantomas wrote:

Keeping header From: and DKIM signatures is perfectly fine, if ML does 
not modify the mail, which afaik is the default setting.


This also depends on how you set DKIM's canonicalization

there is also a mailman setting to remove existing DKIM sigs, so when 
you get the post, you should not see the OP sigs, which should have 
been verified by the mailing list server upon receipt of that message.
This makes sense if ML modifies body and then replaced original From: 
with its own. In such case new signature for ML domain has to be 
created.


I'd like to repeat that *this* list does the former and it's perfectly 
OK.


I repeat depends upon canonicalization, like only if you set c = 
relaxed/relaxed.
The fact this list does not modify the body by adding a footer also 
helps those who use relaxed/simple.


Anyone using simple/simple should have a DKIM fail and plenty use that 
setting, prior to July this year - when I was using this address on file 
with Federal Law Enforcement agencies for receiving shall we say certain 
formal requests ;) I used fully strict with simple/simple - as earlier 
posts on this list would show


dkim=fail reason="signature verification failed" (2048-bit key) 
header.d=ausics.net



I believe the issue lies in bad formulation of condition for fo:

1: Generate a DMARC failure report if any underlying
authentication mechanism produced something other than an
aligned "pass" result.


I've never had an fo=1 SPF failure report, because DKIM would pass, even 
when used on lists, I don't get them, my weekly reports do say we get 
plenty of DKIM unaligned, but no forensic reports, I used to get them 
when I posted to dovecot users, but I think Aki's fixed the settings as 
last couple posts I never got any forensic reports.


...I understand this as SPF unaligned with header From: should be 
reported for domain in header From:.


SPF should only check and report on envelope-sender/return-path, if and 
only if that does not exist it should use the EHLO domain, it should not 
care about From, last time I looked - a decade or so ago - it never did, 
but lets try something...


telnet mail.ausics.net 25
Trying 120.88.115.158...
Connected to mail.ausics.net.
Escape character is '^]'.
220 mail.ausics.net ESMTP Postfix - Hello, is there anybody in there, 
just nod if you can hear me, is there anyone at home

ehlo roswell.ausics.net
250-mail.ausics.net
250-PIPELINING
250-SIZE 5120
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 CHUNKING
mail from:r...@ns2.ausics.net
250 2.1.0 Ok
rcpt to: noel.but...@ausics.net
250 2.1.5 Ok
data
354 End data with .
From: mickeymo...@mi6.gov
To: noel.but...@ausics.net
Subject: rattrap

test
.
250 2.0.0 Ok: queued as 20350200097

.  Message passed, of course it got a rather high spam score for 
missing Date and a few other impersonate gov rules SA rules lol



It makes sense to report missing/unaligned DKIM.


Then set fo=d  :)

--
Regards,
Noel Butler

This Email, including attachments, may contain legally privileged 
information, therefore at all times remains confidential and subject to 
copyright protected under international law. You may not disseminate 
this message without the authors express written authority to do so.   
If you are not the intended recipient, please notify the sender then 
delete all copies of this message including attachments immediately. 
Confidentiality, copyright, and legal privilege are not waived or lost 
by reason of the mistaken delivery of this message.

Re: Amavis and OpenDMARC

2023-11-16 Thread Matus UHLAR - fantomas
On 11/14/23 22:03, Noel Butler wrote: I would understand if those 
reports were required for DKIM fail or SPF fail, but missing aligned 
SPF pass is something common with mailing lists.
You only get them on failures not every message, and no, not all 
mailing lists fail on DKIM, those who take the time to configure 
mailman properly should be fine.



On 15/11/2023 13:59, Dave McGuire wrote:
 Please pardon me for jumping in.  Is there a good reference article 
for this that you could point me to?


On 16.11.23 12:13, Noel Butler wrote:
fo=1:  a DMARC failure/forensic report is sent to you when your email 
fails either SPF or DKIM alignment - Contrary to belief of some, no 
you don't get bombarded with failures, perhaps this is because many 
don't honour this.


I believe you can drop the "perhaps" part.

[...]

Forwarding and for all intents and purposes, that includes mailing lists, 
should rewrite sender and envelope sender addresses, this is what happens 
with mailman when its settings are checked to do so (sadly, that is NOT 
default settings),


Which "sender" do you mean here?

Keeping header From: and DKIM signatures is perfectly fine, if ML 
does not modify the mail, which afaik is the default setting.


there is also a mailman 
setting to remove existing DKIM sigs, so when you get the post, you 
should not see the OP sigs, which should have been verified by the 
mailing list server upon receipt of that message.


This makes sense if ML modifies body and then replaced original From: with 
its own. In such case new signature for ML domain has to be created.


I'd like to repeat that *this* list does the former and it's perfectly OK.

[...]

Also SPF related, a non mailing list type service that forwards, 
should receive, test and if pass, rewrite to its domain/hostname to 
send onto where ever the forward address is, jesus people these things 
were discovered and addressed a decade ago :)


This is commonly done for SPF using SRS, where envelope sender is changed 
but headers are kept, so anyone can verify and validate the original DKIM 
signature. SPF will also pass, but not align with header From:.



I believe the issue lies in bad formulation of condition for fo:

  1: Generate a DMARC failure report if any underlying
 authentication mechanism produced something other than an
 aligned "pass" result.


...I understand this as SPF unaligned with header From: should be reported 
for domain in header From:.



It makes sense to report missing/unaligned DKIM.

Due to forwarding the SPF can be correct and unaligned, it makes no sense to 
report this case.



The funny part is that the latter definition of "fo=s" describes SPF 
reporting differently:


  s: Generate an SPF failure report if the message failed SPF
 evaluation, regardless of its alignment.  SPF-specific
 reporting is described in [AFRF-SPF].


...I understand this as SPF failures for "your domain" in envelope from 
should be reported, independently proper alignment with header From:.



If your understanding of mentioned parts of RFC 7489 is different, please 
explain how.


--
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.
A day without sunshine is like, night.


Re: Amavis and OpenDMARC

2023-11-15 Thread Dave McGuire

On 11/15/23 21:13, Noel Butler wrote:

On 15/11/2023 13:59, Dave McGuire wrote:


On 11/14/23 22:03, Noel Butler wrote:
I would understand if those reports were required for DKIM fail or 
SPF fail, but missing aligned SPF pass is something common with 
mailing lists.


You only get them on failures not every message, and no, not all 
mailing lists fail on DKIM, those who take the time to configure 
mailman properly should be fine.


  Please pardon me for jumping in.  Is there a good reference article 
for this that you could point me to?


   Thanks,
   -Dave


fo=0:  a DMARC failure/forensic report is sent to you if your email 
fails both SPF and DKIM alignment - This is the default if unspecified.


fo=1:  a DMARC failure/forensic report is sent to you when your email 
fails either SPF or DKIM alignment - Contrary to belief of some, no you 
don't get bombarded with failures, perhaps this is because many don't 
honour this.


fo=d: a DKIM failure report is sent if the email’s DKIM signature fails 
validation, regardless of the alignment


fo=s: an SPF failure report is sent if the email fails SPF evaluation, 
irrespective of the alignment.



fo=1  is in fact the most heavily used, don't take my word for it, do 
your own homework.



Forwarding and for all intents and purposes, that includes mailing 
lists, should rewrite sender and envelope sender addresses, this is what 
happens with mailman when its settings are checked to do so (sadly, that 
is NOT  default settings), there is also a mailman setting to remove 
existing DKIM sigs, so when you get the post, you should not see the OP 
sigs, which should have been verified by the mailing list server upon 
receipt of that message.


So it gets it, if it passes, it removes it and adds its own sig details, 
likewise with SPF, the OP is no longer sending the message, the domain 
of the list server is, so THAT is the only tests that should be performed.


Also SPF related, a non mailing list type service that forwards, should 
receive, test and if pass, rewrite to its domain/hostname to send onto 
where ever the forward address is, jesus people these things were 
discovered and addressed a decade ago :)


  Thanks for the info.  I know about the fo= settings; the mailing 
lists that I run (using Mailman) are working ok.  Most of the other 
mailing lists that I'm subscribed to that I do not run, though, generate 
lots of DMARC failures.  I'm just trying to see if there's a gap in my 
understanding.


  Again thank you for the description.

  -Dave

--
Dave McGuire, AK4HZ
New Kensington, PA



Re: Amavis and OpenDMARC

2023-11-15 Thread Noel Butler

On 15/11/2023 13:59, Dave McGuire wrote:

On 11/14/23 22:03, Noel Butler wrote: I would understand if those 
reports were required for DKIM fail or SPF fail, but missing aligned 
SPF pass is something common with mailing lists.
You only get them on failures not every message, and no, not all 
mailing lists fail on DKIM, those who take the time to configure 
mailman properly should be fine.


  Please pardon me for jumping in.  Is there a good reference article 
for this that you could point me to?


   Thanks,
   -Dave

fo=0:  a DMARC failure/forensic report is sent to you if your email 
fails both SPF and DKIM alignment - This is the default if unspecified.


fo=1:  a DMARC failure/forensic report is sent to you when your email 
fails either SPF or DKIM alignment - Contrary to belief of some, no you 
don't get bombarded with failures, perhaps this is because many don't 
honour this.


fo=d: a DKIM failure report is sent if the email's DKIM signature fails 
validation, regardless of the alignment


fo=s: an SPF failure report is sent if the email fails SPF evaluation, 
irrespective of the alignment.


fo=1  is in fact the most heavily used, don't take my word for it, do 
your own homework.


Forwarding and for all intents and purposes, that includes mailing 
lists, should rewrite sender and envelope sender addresses, this is what 
happens with mailman when its settings are checked to do so (sadly, that 
is NOT  default settings), there is also a mailman setting to remove 
existing DKIM sigs, so when you get the post, you should not see the OP 
sigs, which should have been verified by the mailing list server upon 
receipt of that message.


So it gets it, if it passes, it removes it and adds its own sig details, 
likewise with SPF, the OP is no longer sending the message, the domain 
of the list server is, so THAT is the only tests that should be 
performed.


Also SPF related, a non mailing list type service that forwards, should 
receive, test and if pass, rewrite to its domain/hostname to send onto 
where ever the forward address is, jesus people these things were 
discovered and addressed a decade ago :)


--
Regards,
Noel Butler

This Email, including attachments, may contain legally privileged 
information, therefore at all times remains confidential and subject to 
copyright protected under international law. You may not disseminate 
this message without the authors express written authority to do so.   
If you are not the intended recipient, please notify the sender then 
delete all copies of this message including attachments immediately. 
Confidentiality, copyright, and legal privilege are not waived or lost 
by reason of the mistaken delivery of this message.

Re: Amavis and OpenDMARC

2023-11-15 Thread Matus UHLAR - fantomas

On 15.11.23 10:46, Damian wrote:
If there is anything hostile to mailing lists in DMARC 
specification, it's this.

...
The mailing list has nothing to do with that.


Seems contradictory to me.


Not a tiniest little bit.
This is problem of forwarding, not problem of mailing lists.

Mailing lists is just one of examples which make the problem worse, they do 
not cause the problem.



If you fo=1 on your domain:

You will get bombed ...


Those are the same `you`s, are they not? `you` get what `you` wished 
for. If someone sets `$log_level = 5`, will they complain about a 
large log file?


I am explaining why "fo=1" is useless and broken by design.


--
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.
The early bird may get the worm, but the second mouse gets the cheese.


Re: Amavis and OpenDMARC

2023-11-15 Thread Damian
If there is anything hostile to mailing lists in DMARC specification, 
it's this.

...
The mailing list has nothing to do with that.


Seems contradictory to me.


If you fo=1 on your domain:

You will get bombed ...
Those are the same `you`s, are they not? `you` get what `you` wished 
for. If someone sets `$log_level = 5`, will they complain about a large 
log file?

Re: Amavis and OpenDMARC

2023-11-15 Thread Matus UHLAR - fantomas
This in my understanding generates failure reports for any forwarded 
mail including any mail to lists that do not completely rewrite 
From:

(including this one mailing list)

- even if DKIM is preserved and valid, such mail won't generate 
aligned SPF   pass


unless you have better explanation of that section...


On 15.11.23 09:13, Damian wrote:
fo is for debugging. If someone defines fo for their domain and gets a 
bunch of failure reports, they get what they wished for. The mailing 
list itself does not have to process those failure reports, nor is the 
mailing list penalized for it.


You seem to repeatedly misunderstand what I am talking about.
The mailing list has nothing to do with that.

If you fo=1 on your domain:

- one of your users will mail to his friend who set up forward to gmail.
- friend's mail server forwards the mail to gmail.com servers
- gmail will send you report that the forwarded mail did not pass aligned SPF.

It does not mater whether friend's mail server does SRS (which will make SPF 
pass but not be aligned), or does NOT SRS (which will make SPF not pass).


The same happens if one of your users will send mail to any mailing list, 
which preserves DKIM (your domain) but can not preserve SPF.


You will get bombed for reports about mails forwarded by recipients of 
forwarded mail from your users, or by recipients of any mail sent by your 
users into mailing lists.



...and I repeat that this will happen for each mail to this mailing list, 
because mail from it comes to me with:

- envelope from: amavis-users-bounces+uhlar=fantomas...@amavis.org
- header From: Damian 


--
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.
Posli tento mail 100 svojim znamim - nech vidia aky si idiot
Send this email to 100 your friends - let them see what an idiot you are


Re: Amavis and OpenDMARC

2023-11-15 Thread Damian
This in my understanding generates failure reports for any forwarded 
mail including any mail to lists that do not completely rewrite From:

(including this one mailing list)

- even if DKIM is preserved and valid, such mail won't generate 
aligned SPF   pass


unless you have better explanation of that section... 


fo is for debugging. If someone defines fo for their domain and gets a 
bunch of failure reports, they get what they wished for. The mailing 
list itself does not have to process those failure reports, nor is the 
mailing list penalized for it.


Re: Amavis and OpenDMARC

2023-11-15 Thread Matus UHLAR - fantomas

On 14/11/2023 23:00, Matus UHLAR - fantomas wrote:

That's not what I was talking about.

If anyone sets fo=0 in dmarc record of a domain, they will get 
notification for every mail from their domain that gets forwarded 
through a mailing list


(or via other means)

I would understand if those reports were required for DKIM fail or 
SPF fail, but missing aligned SPF pass is something common with 
mailing lists.


On 15.11.23 13:03, Noel Butler wrote:
You only get them on failures not every message, and no, not all 
mailing lists fail on DKIM, those who take the time to configure 
mailman properly should be fine.


sorry, mistake was supposed write fo=1
By RFC 7489, section 6.3:

   fo:  Failure reporting options (plain-text; OPTIONAL; default is "0")
[...]
  1: Generate a DMARC failure report if any underlying
 authentication mechanism produced something other than an
 aligned "pass" result.

This in my understanding generates failure reports for any forwarded mail 
including any mail to lists that do not completely rewrite From:

(including this one mailing list)

- even if DKIM is preserved and valid, such mail won't generate aligned SPF 
  pass


unless you have better explanation of that section...
--
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.
42.7 percent of all statistics are made up on the spot.


Re: Amavis and OpenDMARC

2023-11-14 Thread Dave McGuire

On 11/14/23 22:03, Noel Butler wrote:
I would understand if those reports were required for DKIM fail or SPF 
fail, but missing aligned SPF pass is something common with mailing lists.


You only get them on failures not every message, and no, not all mailing 
lists fail on DKIM, those who take the time to configure mailman 
properly should be fine.


  Please pardon me for jumping in.  Is there a good reference article 
for this that you could point me to?


   Thanks,
   -Dave

--
Dave McGuire, AK4HZ
New Kensington, PA



Re: Amavis and OpenDMARC

2023-11-14 Thread Noel Butler

On 14/11/2023 23:00, Matus UHLAR - fantomas wrote:


That's not what I was talking about.

If anyone sets fo=0 in dmarc record of a domain, they will get 
notification for every mail from their domain that gets forwarded 
through a mailing list


(or via other means)

I would understand if those reports were required for DKIM fail or SPF 
fail, but missing aligned SPF pass is something common with mailing 
lists.


You only get them on failures not every message, and no, not all mailing 
lists fail on DKIM, those who take the time to configure mailman 
properly should be fine.


--
Regards,
Noel Butler

This Email, including attachments, may contain legally privileged 
information, therefore at all times remains confidential and subject to 
copyright protected under international law. You may not disseminate 
this message without the authors express written authority to do so.   
If you are not the intended recipient, please notify the sender then 
delete all copies of this message including attachments immediately. 
Confidentiality, copyright, and legal privilege are not waived or lost 
by reason of the mistaken delivery of this message.

Re: Amavis and OpenDMARC

2023-11-14 Thread Matus UHLAR - fantomas
Looking at it, fo=0 should generate dmarc report for each individual 
mail forwarded, either through mailing list or via other ways.


If there is anything hostile to mailing lists in DMARC 
specification, it's this.


On 13.11.23 10:00, Damian wrote:

Why would someone pick a mailing list address as their ruf?


That's not what I was talking about.

If anyone sets fo=0 in dmarc record of a domain, they will get notification 
for every mail from their domain that gets forwarded through a mailing list


(or via other means)

I would understand if those reports were required for DKIM fail or SPF fail, 
but missing aligned SPF pass is something common with mailing lists.

--
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.
"They say when you play that M$ CD backward you can hear satanic messages."
"That's nothing. If you play it forward it will install Windows."


Re: Amavis and OpenDMARC

2023-11-13 Thread Damian
Looking at it, fo=0 should generate dmarc report for each individual 
mail forwarded, either through mailing list or via other ways.


If there is anything hostile to mailing lists in DMARC specification, 
it's this. 


Why would someone pick a mailing list address as their ruf?


Re: Amavis and OpenDMARC

2023-11-13 Thread Matus UHLAR - fantomas

On 12/11/23 15:10, Noel Butler wrote:
DMARC (thus OpenDMARC) makes its decision based on the senders DMARC 
fo policy -


if policy uses fo=0  then yes, both SPF and DKIM must exist, and 
both must pass.


if policy uses fo=1  then no, as a minimum /either/ SPF or DKIM must 
exist, and pass, so DMARC will work with only SPF or only DKIM, it 
will also work with both, which has the advantage that only one of 
these must pass, eg: SPF passes but DKIM fails, DMARC usinng fo=1 
will pass.


I recommend fo=1 for general use but fo=0 for critical areas, like 
govts, legal and finance sectors, or those who deal with them on a 
very regular basis, in which case they wouldn't be authorised to use 
there govt/corp email for private use so if ill-configured mailing 
lists for example rejected them, then that's acceptable collateral 
damage.


On 12.11.23 16:03, Nick Tait wrote:
My understanding of the "fo" option is that it is only used for 
reporting. i.e. It doesn't control whether the received email is 
accepted or not, which is always based on /either/ SPF or DKIM checks 
passing.


From RFC 7489:

  fo:  Failure reporting options (plain-text; OPTIONAL; default is "0")
 Provides requested options for generation of failure reports.
 Report generators MAY choose to adhere to the requested options.
 This tag's content MUST be ignored if a "ruf" tag (below) is not
 also specified...


Looking at it, fo=0 should generate dmarc report for each individual mail 
forwarded, either through mailing list or via other ways.


If there is anything hostile to mailing lists in DMARC specification, it's 
this.


--
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.
Remember half the people you know are below average.


Re: Amavis and OpenDMARC

2023-11-13 Thread Matus UHLAR - fantomas

On 11.11.23 10:55, Dino Edwards wrote:

to be more precise: OpenDMARC running as milter only sees output from

milters applied before it.


Milter is run pre-queue and content_filter is run after queue, so opendmarc

does not see that amavis produced, because it was added later.


If you used amavisd-milter at SMTP port, opendmarc could see its output.



I run amavisd-milter at SMTP port, so it can reject spam/viruses

immediately and amavis as content-filter by default (local and trusted
submission).

So it looks like I can run amavis as content_filter AND milter. This sounds
like a good solution. Do you mind sharing your postfix config for amavis
milter? I'm assuming I need a separate program called amavis-milter?


amavisd config - Debian's /etc/amavis/conf.d/50-user

$final_virus_destiny= D_REJECT;
$final_banned_destiny   = D_REJECT;
$final_spam_destiny = D_PASS;

$interface_policy{'SOCK'} = 'AM.PDP-SOCK';  # milter
$policy_bank{'AM.PDP-SOCK'} = {
protocol => 'AM.PDP',   # select Amavis policy delegation protocol
spam_kill_level_maps=> 10,
final_spam_destiny  => D_REJECT,
final_virus_destiny => D_REJECT,
final_banned_destiny=> D_REJECT,
};


I have experimented with final_*_destiny
- D_REJECT in content_filter causes bouce back to sender which should be safe 
with local senders.
- D_BOUNCE Does the same but it's amavis who creates the notification. 
Perhaps it'd be better.


main.cf:

content_filter=amavisfeed:[127.0.0.1]:10024

master.cf:

smtp  inet  n   -   y   -   1   postscreen
smtpd pass  -   -   y   -   -   smtpd
  -o content_filter=
  -o smtpd_milters=unix:/amavis/amavisd-milter.sock


Where 'amavisfeed' and '127.0.0.1:10025' are set up according to amavisd-new 
README.Postfix (lmtp version)


--
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.
The 3 biggets disasters: Hiroshima 45, Tschernobyl 86, Windows 95


Re: Amavis and OpenDMARC

2023-11-12 Thread Damian

if policy uses fo=0  then yes, both SPF and DKIM must exist, and both must pass.

if policy uses fo=1  then no, as a minimum /either/ SPF or DKIM must exist, and pass, so DMARC will work with only SPF or only 
DKIM, it will also work with both, which has the advantage that only one of these must pass, eg: SPF passes but DKIM fails, 
DMARC usinng fo=1 will pass.


I recommend fo=1 for general use but fo=0 for critical areas, like govts, legal and finance sectors, or those who deal with 
them on a very regular basis, in which case they wouldn't be authorised to use there govt/corp email for private use so if 
ill-configured mailing lists for example rejected them, then that's acceptable collateral damage.



[...]
My understanding of the "fo" option is that it is only used for reporting. i.e. It doesn't control whether the received email is 
accepted or not, which is always based on /either/ SPF or DKIM checks passing.

[...]

Ahhh you're right, my very bad, I was confusing r/s ...


Would the above finetuning of (DKIM || SPF) vs. (DKIM && SPF) have been achieved in some early draft version? I cannot place "r/s" 
in any other context than relaxed vs. strict alignment.


Re: Amavis and OpenDMARC

2023-11-11 Thread Noel Butler

On 12/11/2023 14:04, Noel Butler wrote:

My understanding of the "fo" option is that it is only used for 
reporting. i.e. It doesn't control whether the received email is 
accepted or not, which is always based on _either_ SPF or DKIM checks 
passing.


From RFC 7489:

fo:  Failure reporting options (plain-text; OPTIONAL; default is "0")
Provides requested options for generation of failure reports.
Report generators MAY choose to adhere to the requested options.
This tag's content MUST be ignored if a "ruf" tag (below) is not
also specified...

Nick.


Ahhh you're right, my very bad, I was confusing r/s ...

/slap shouldnt do email first thing early Sunday morning after being up 
till 3am watching Cricket :)


You know the scary part...

I only recently, after being pestered by people whining how hard it is 
to do these things, published blog article series on DNSSEC, SPF, DKIM 
and DMARC, and even made that very point of fo's purpose...


time for my "scan"

(senior citizen afternoon nap :P )

--
Regards,
Noel Butler

This Email, including attachments, may contain legally privileged 
information, therefore at all times remains confidential and subject to 
copyright protected under international law. You may not disseminate 
this message without the authors express written authority to do so.   
If you are not the intended recipient, please notify the sender then 
delete all copies of this message including attachments immediately. 
Confidentiality, copyright, and legal privilege are not waived or lost 
by reason of the mistaken delivery of this message.

Re: Amavis and OpenDMARC

2023-11-11 Thread Noel Butler

On 12/11/2023 13:03, Nick Tait wrote:


On 12/11/23 15:10, Noel Butler wrote:

DMARC (thus OpenDMARC) makes its decision based on the senders DMARC 
fo policy -


if policy uses fo=0  then yes, both SPF and DKIM must exist, and both 
must pass.


if policy uses fo=1  then no, as a minimum _either_ SPF or DKIM must 
exist, and pass, so DMARC will work with only SPF or only DKIM, it 
will also work with both, which has the advantage that only one of 
these must pass, eg: SPF passes but DKIM fails, DMARC usinng fo=1 will 
pass.


I recommend fo=1 for general use but fo=0 for critical areas, like 
govts, legal and finance sectors, or those who deal with them on a 
very regular basis, in which case they wouldn't be authorised to use 
there govt/corp email for private use so if ill-configured mailing 
lists for example rejected them, then that's acceptable collateral 
damage.


Hi Noel.

My understanding of the "fo" option is that it is only used for 
reporting. i.e. It doesn't control whether the received email is 
accepted or not, which is always based on _either_ SPF or DKIM checks 
passing.


From RFC 7489:

fo:  Failure reporting options (plain-text; OPTIONAL; default is "0")
Provides requested options for generation of failure reports.
Report generators MAY choose to adhere to the requested options.
This tag's content MUST be ignored if a "ruf" tag (below) is not
also specified...

Nick.


Ahhh you're right, my very bad, I was confusing r/s ...

/slap shouldnt do email first thing early Sunday morning after being up 
till 3am watching Cricket :)


--
Regards,
Noel Butler

This Email, including attachments, may contain legally privileged 
information, therefore at all times remains confidential and subject to 
copyright protected under international law. You may not disseminate 
this message without the authors express written authority to do so.   
If you are not the intended recipient, please notify the sender then 
delete all copies of this message including attachments immediately. 
Confidentiality, copyright, and legal privilege are not waived or lost 
by reason of the mistaken delivery of this message.

Re: Amavis and OpenDMARC

2023-11-11 Thread Nick Tait

On 12/11/23 15:10, Noel Butler wrote:


DMARC (thus OpenDMARC) makes its decision based on the senders DMARC 
fo policy -


if policy uses fo=0  then yes, both SPF and DKIM must exist, and both 
must pass.


if policy uses fo=1  then no, as a minimum /either/ SPF or DKIM must 
exist, and pass, so DMARC will work with only SPF or only DKIM, it 
will also work with both, which has the advantage that only one of 
these must pass, eg: SPF passes but DKIM fails, DMARC usinng fo=1 will 
pass.


I recommend fo=1 for general use but fo=0 for critical areas, like 
govts, legal and finance sectors, or those who deal with them on a 
very regular basis, in which case they wouldn't be authorised to use 
there govt/corp email for private use so if ill-configured mailing 
lists for example rejected them, then that's acceptable collateral damage.



Hi Noel.

My understanding of the "fo" option is that it is only used for 
reporting. i.e. It doesn't control whether the received email is 
accepted or not, which is always based on /either/ SPF or DKIM checks 
passing.


From RFC 7489:

   fo:  Failure reporting options (plain-text; OPTIONAL; default is "0")
  Provides requested options for generation of failure reports.
  Report generators MAY choose to adhere to the requested options.
  This tag's content MUST be ignored if a "ruf" tag (below) is not
  also specified...

Nick.



Re: Amavis and OpenDMARC

2023-11-11 Thread Noel Butler

On 12/11/2023 02:02, Dino Edwards wrote:

That's correct, if you're using  only opendmarc just the 
inet:127.0.0.1:54321 is needed, thats all you need, are you sure it 
>is adding sigs on sending? send an email to check-a...@verifier.port25.com wait a minute then  check its results email.


If opendmarc requires dkim signature verification before it makes a 
decision, I will need something that checks dkim first, right? I did 
send an e-mail to the e-mail address you suggested and everything looks 
good:


DMARC (thus OpenDMARC) makes its decision based on the senders DMARC fo 
policy -


if policy uses fo=0  then yes, both SPF and DKIM must exist, and both 
must pass.


if policy uses fo=1  then no, as a minimum _either_ SPF or DKIM must 
exist, and pass, so DMARC will work with only SPF or only DKIM, it will 
also work with both, which has the advantage that only one of these must 
pass, eg: SPF passes but DKIM fails, DMARC usinng fo=1 will pass.


I recommend fo=1 for general use but fo=0 for critical areas, like 
govts, legal and finance sectors, or those who deal with them on a very 
regular basis, in which case they wouldn't be authorised to use there 
govt/corp email for private use so if ill-configured mailing lists for 
example rejected them, then that's acceptable collateral damage.


--
Regards,
Noel Butler

This Email, including attachments, may contain legally privileged 
information, therefore at all times remains confidential and subject to 
copyright protected under international law. You may not disseminate 
this message without the authors express written authority to do so.   
If you are not the intended recipient, please notify the sender then 
delete all copies of this message including attachments immediately. 
Confidentiality, copyright, and legal privilege are not waived or lost 
by reason of the mistaken delivery of this message.

RE: Amavis and OpenDMARC

2023-11-11 Thread Dino Edwards
>the domain you're using now has quarantine policy :)

 

It sure does, but I don’t have a problem with outgoing e-mail. Only incoming 
unless I’m not understanding what you are saying.

>That's correct, if you're using  only opendmarc just the inet:127.0.0.1:54321 
>is needed, thats all you need, are you sure it >is adding sigs on sending? 
>send an email to check-a...@verifier.port25.com 
>  wait a minute then  check its results 
>email.

If opendmarc requires dkim signature verification before it makes a decision, I 
will need something that checks dkim first, right? I did send an e-mail to the 
e-mail address you suggested and everything looks good:

Thank you for using the verifier,

 

The Port25 Solutions, Inc. team

 

==

Summary of Results

==

SPF check:  pass

"iprev" check:  pass

DKIM check: pass

 

 



RE: Amavis and OpenDMARC

2023-11-11 Thread Dino Edwards


>to be more precise: OpenDMARC running as milter only sees output from
milters applied before it.

>Milter is run pre-queue and content_filter is run after queue, so opendmarc
does not see that amavis produced, because it was added later.

>If you used amavisd-milter at SMTP port, opendmarc could see its output.

>I run amavisd-milter at SMTP port, so it can reject spam/viruses
immediately and amavis as content-filter by default (local and trusted
submission).

So it looks like I can run amavis as content_filter AND milter. This sounds
like a good solution. Do you mind sharing your postfix config for amavis
milter? I'm assuming I need a separate program called amavis-milter?

Thanks







Re: Amavis and OpenDMARC

2023-11-11 Thread Noel Butler

On 11/11/2023 23:03, Dino Edwards wrote:

most DMARC's I find still use quarantine, what responses are you 
seeing for them?


I don't have any p=quarantine examples right now.


the domain you're using now has quarantine policy :)


o dont need to setup amavisd as a milter if its working fine already.

Well, I can see Damien's point here. Originally with OpenDKIM the 
Postfix milter was setup in the following  order where 8891 is OpenDKIM 
and 54321 is OpenDMARC:


smtpd_milters = inet:127.0.0.1:8891, inet:127.0.0.1:54321

So OpenDKIM would insert the authentication headers and OpenDMARC would 
parse them. By using the amavis as content_filter i.e. post-queue, 
OpenDMARC never sees the authentication headers so it always fails but 
in the case of p=none it doesn't make a difference and it passes 
anyway.


Unless I'm thinking about it wrong.


That's correct, if you're using  only opendmarc just the 
inet:127.0.0.1:54321 is needed, thats all you need, are you sure it is 
adding sigs on sending? send an email to check-a...@verifier.port25.com 
wait a minute then  check its results email.


--
Regards,
Noel Butler

This Email, including attachments, may contain legally privileged 
information, therefore at all times remains confidential and subject to 
copyright protected under international law. You may not disseminate 
this message without the authors express written authority to do so.   
If you are not the intended recipient, please notify the sender then 
delete all copies of this message including attachments immediately. 
Confidentiality, copyright, and legal privilege are not waived or lost 
by reason of the mistaken delivery of this message.

Re: Amavis and OpenDMARC

2023-11-11 Thread Matus UHLAR - fantomas

So Amavis is setup as an smtpd_milter as well?



No, Amavis is setup as a content_filter (content_filter = 
amavis:[127.0.0.1]:10021)


On 11.11.23 11:34, Damian wrote:

You can't do that. OpenDMARC needs to see Authentication-Results for DKIM.


to be more precise: OpenDMARC running as milter only sees output from 
milters applied before it.


Milter is run pre-queue and content_filter is run after queue, so opendmarc 
does not see that amavis produced, because it was added later.


If you used amavisd-milter at SMTP port, opendmarc could see its output.

I run amavisd-milter at SMTP port, so it can reject spam/viruses immediately 
and amavis as content-filter by default (local and trusted submission).



--
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.
Eagles may soar, but weasels don't get sucked into jet engines.


RE: Amavis and OpenDMARC

2023-11-11 Thread Dino Edwards
 

On 11/11/2023 18:07, Damian wrote:

Also, since they allude to "some passing", I guess they did remember to set 
enable_dkim_verification=1 ?


"Some passing OpenDMARC" might mean that they pass SPF-based only.

>true if using fo=1

To be clear, Amavis is setup like below:

$enable_dkim_verification = 1;

$enable_dkim_signing = 1;

 

 

 



RE: Amavis and OpenDMARC

2023-11-11 Thread Dino Edwards
>most DMARC's I find still use quarantine, what responses are you seeing for 
>them?

I don’t have any p=quarantine examples right now.

>You also dont need to setup amavisd as a milter if its working fine already.

 

Well, I can see Damien’s point here. Originally with OpenDKIM the Postfix 
milter was setup in the following  order where 8891 is OpenDKIM and 54321 is 
OpenDMARC:

smtpd_milters = inet:127.0.0.1:8891, inet:127.0.0.1:54321

So OpenDKIM would insert the authentication headers and OpenDMARC would parse 
them. By using the amavis as content_filter i.e. post-queue, OpenDMARC never 
sees the authentication headers so it always fails but in the case of p=none it 
doesn’t make a difference and it passes anyway.

Unless I’m thinking about it wrong.

 



Re: Amavis and OpenDMARC

2023-11-11 Thread Noel Butler

On 11/11/2023 18:07, Damian wrote:

Also, since they allude to "some passing", I guess they did remember 
to set enable_dkim_verification=1 ?


"Some passing OpenDMARC" might mean that they pass SPF-based only.


true if using fo=1

--
Regards,
Noel Butler

This Email, including attachments, may contain legally privileged 
information, therefore at all times remains confidential and subject to 
copyright protected under international law. You may not disseminate 
this message without the authors express written authority to do so.   
If you are not the intended recipient, please notify the sender then 
delete all copies of this message including attachments immediately. 
Confidentiality, copyright, and legal privilege are not waived or lost 
by reason of the mistaken delivery of this message.

Re: Amavis and OpenDMARC

2023-11-11 Thread Noel Butler

On 11/11/2023 21:28, Dino Edwards wrote:

You can't do that. OpenDMARC needs to see Authentication-Results for 
DKIM.


It looks like you might be on to something. The e-mails that pass have 
a p=none and the e-mails that fail have a p=reject. So, I need to setup 
amavis as a milter in Postfix instead of a content_filter that I have 
now? How would that affect spam with SA if at all? As I understand 
milter is pre-queue where content_filter is post-queue. Does the milter 
require a separate package called amavisd-milter?


Thanks


most DMARC's I find still use quarantine, what responses are you seeing 
for them?


You also dont need to setup amavisd as a milter if its working fine 
already.


--
Regards,
Noel Butler

This Email, including attachments, may contain legally privileged 
information, therefore at all times remains confidential and subject to 
copyright protected under international law. You may not disseminate 
this message without the authors express written authority to do so.   
If you are not the intended recipient, please notify the sender then 
delete all copies of this message including attachments immediately. 
Confidentiality, copyright, and legal privilege are not waived or lost 
by reason of the mistaken delivery of this message.

Re: Amavis and OpenDMARC

2023-11-11 Thread Noel Butler

On 11/11/2023 20:44, Dino Edwards wrote:

I've seen no problems with mail from MS, so how about you elaborate on 
your problems and what version of OD are you using?


Here's the exact issue that I just ran into with o365 mail and note 
this issue was reported 3 years ago. No fix yet.


https://github.com/trusteddomainproject/OpenDKIM/issues/73

Granted, is it Microsoft omitting ADMD on DKIM signatures but it's not 
like we cannot not do business with o365 customers. This particular 
issue was with one of my e-mail customers doing business with the 
secret service and that's the issue. You have high profile 
organizations using o365 and your customers don't want to hear that the 
problem is on their end. "What do you mean the problem is on their end? 
This is the secret service!. It's got to be your problem!".


Here's my OpenDKIM version and related info:

opendkim -V

opendkim: OpenDKIM Filter v2.11.0

Compiled with OpenSSL 1.1.1f  31 Mar 2020

SMFI_VERSION 0x101

libmilter version 1.0.1

Supported signing algorithms:

rsa-sha1

rsa-sha256

ed25519-sha256

Supported canonicalization algorithms:

relaxed

simple

Active code options:

QUERY_CACHE

USE_DB

USE_LDAP

USE_LUA

USE_ODBX

USE_UNBOUND

_FFR_ATPS

_FFR_RBL

_FFR_REPLACE_RULES

_FFR_SENDER_MACRO

_FFR_STATS

_FFR_VBR

libopendkim 2.11.0: atps query_cache


OK, 2.10.3 is what we use, if you can try that? or maybe you have?

But Microsoft should be doing this correctly, try NANOG  there are a few 
MS guys I know on there, or if no response there used to be a MS guy on 
the mailop list, no idea if he's still there, that list is run by self 
important power tripping dictators so it should be a last resort port of 
call if your desperate, if it was google I could help much deeper :)


--
Regards,
Noel Butler

This Email, including attachments, may contain legally privileged 
information, therefore at all times remains confidential and subject to 
copyright protected under international law. You may not disseminate 
this message without the authors express written authority to do so.   
If you are not the intended recipient, please notify the sender then 
delete all copies of this message including attachments immediately. 
Confidentiality, copyright, and legal privilege are not waived or lost 
by reason of the mistaken delivery of this message.

RE: Amavis and OpenDMARC

2023-11-11 Thread Dino Edwards


> You can't do that. OpenDMARC needs to see Authentication-Results for DKIM.

It looks like you might be on to something. The e-mails that pass have a p=none 
and the e-mails that fail have a p=reject. So, I need to setup amavis as a 
milter in Postfix instead of a content_filter that I have now? How would that 
affect spam with SA if at all? As I understand milter is pre-queue where 
content_filter is post-queue. Does the milter require a separate package called 
amavisd-milter?

Thanks










RE: Amavis and OpenDMARC

2023-11-11 Thread Dino Edwards
> I've seen no problems with mail from MS, so how about you elaborate on your 
> problems and what version of OD are you using?

Here’s the exact issue that I just ran into with o365 mail and note this issue 
was reported 3 years ago. No fix yet.

https://github.com/trusteddomainproject/OpenDKIM/issues/73

Granted, is it Microsoft omitting ADMD on DKIM signatures but it’s not like we 
cannot not do business with o365 customers. This particular issue was with one 
of my e-mail customers doing business with the secret service and that’s the 
issue. You have high profile organizations using o365 and your customers don’t 
want to hear that the problem is on their end. “What do you mean the problem is 
on their end? This is the secret service!. It’s got to be your problem!”. 

Here’s my OpenDKIM version and related info:

opendkim -V

opendkim: OpenDKIM Filter v2.11.0

Compiled with OpenSSL 1.1.1f  31 Mar 2020

SMFI_VERSION 0x101

libmilter version 1.0.1

Supported signing algorithms:

rsa-sha1

rsa-sha256

ed25519-sha256

Supported canonicalization algorithms:

relaxed

simple

Active code options:

QUERY_CACHE

USE_DB

USE_LDAP

USE_LUA

USE_ODBX

USE_UNBOUND

_FFR_ATPS

_FFR_RBL

_FFR_REPLACE_RULES

_FFR_SENDER_MACRO

_FFR_STATS

_FFR_VBR

libopendkim 2.11.0: atps query_cache

 



Re: Amavis and OpenDMARC

2023-11-11 Thread Damian

So Amavis is setup as an smtpd_milter as well?

No, Amavis is setup as a content_filter (content_filter = 
amavis:[127.0.0.1]:10021)


You can't do that. OpenDMARC needs to see Authentication-Results for DKIM.


Re: Amavis and OpenDMARC

2023-11-11 Thread Matus UHLAR - fantomas

OpenDMARC is setup as a smtpd_milter in Postfix.


So Amavis is setup as an smtpd_milter as well?


Can someone maybe shed some light on why this would be happening 
or is there a different way to handle DMARC?



On 11/11/2023 05:04, Damian wrote:
Do you see DKIM-related Authentication-Results headers in incoming 
mails?



On 11.11.23 14:41, Noel Butler wrote:
I'm betting its dkim_minimum_key_bits set to 2048 (great - except some 
who setup DKIM 10 years ago haven't redone keys are probably still 
scarily using 1024 bit keys,


when I set up DKIM on a few domains a few years ago, I've read this article
https://crypto.stackexchange.com/questions/72297/recommended-key-size-for-dkim#72298
and I don't think it would be obsolete by now.

I recall reading a post once that said those keys would soon be considered 
a fail.


if you find it, let me know.

Also, since they allude to "some passing", I guess they did remember 
to set enable_dkim_verification=1 ? since from memory that explicitly 
must be set to 0 for opendkim.


opendmarc can resolve SPF by itself, despite what its description says.  
other thing is, it's not recommended.


But it can't verify DKIM. So it's possible that SPF passes were okay, other 
mail was not.


The OP needs to do more testing of such things and if still stumped 
report back here,  it's very overcast here today, so my ESP link can't 
connect ;)



--
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.
I intend to live forever - so far so good.


RE: Amavis and OpenDMARC

2023-11-11 Thread Dino Edwards


> So Amavis is setup as an smtpd_milter as well?

No, Amavis is setup as a content_filter (content_filter = 
amavis:[127.0.0.1]:10021)

> Do you see DKIM-related Authentication-Results headers in incoming mails?

Yes, please see below at an example e-mail from gmail:

Authentication-Results: smtp.domain.tld (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com



Re: Amavis and OpenDMARC

2023-11-11 Thread Damian

Also, since they allude to "some passing", I guess they did remember to set 
enable_dkim_verification=1 ?


"Some passing OpenDMARC" might mean that they pass SPF-based only.


Re: Amavis and OpenDMARC

2023-11-10 Thread Noel Butler

On 11/11/2023 05:04, Damian wrote:


OpenDMARC is setup as a smtpd_milter in Postfix.


So Amavis is setup as an smtpd_milter as well?

Can someone maybe shed some light on why this would be happening or is 
there a different way to handle DMARC?


Do you see DKIM-related Authentication-Results headers in incoming 
mails?


I'm betting its dkim_minimum_key_bits set to 2048 (great - except some 
who setup DKIM 10 years ago haven't redone keys are probably still 
scarily using 1024 bit keys, I recall reading a post once that said 
those keys would soon be considered a fail.


Also, since they allude to "some passing", I guess they did remember to 
set enable_dkim_verification=1 ? since from memory that explicitly must 
be set to 0 for opendkim.


The OP needs to do more testing of such things and if still stumped 
report back here,  it's very overcast here today, so my ESP link can't 
connect ;)


--
Regards,
Noel Butler

This Email, including attachments, may contain legally privileged 
information, therefore at all times remains confidential and subject to 
copyright protected under international law. You may not disseminate 
this message without the authors express written authority to do so.   
If you are not the intended recipient, please notify the sender then 
delete all copies of this message including attachments immediately. 
Confidentiality, copyright, and legal privilege are not waived or lost 
by reason of the mistaken delivery of this message.

Re: Amavis and OpenDMARC

2023-11-10 Thread Noel Butler

On 11/11/2023 00:34, Dino Edwards wrote:


Hello,

In the past I used OpenDKIM to sign and verify DKIM signatures. However 
considering the fact that it hasn't been updated in a very long time 
and constant issues with e-mails from O365 senders,


Thanks in advance.


The fact a program hasn't been updated in years is not necessarily a 
sign of " time to find something else "...


I've seen no problems with mail from MS, so how about you elaborate on 
your problems and what version of OD are you using?


--
Regards,
Noel Butler

This Email, including attachments, may contain legally privileged 
information, therefore at all times remains confidential and subject to 
copyright protected under international law. You may not disseminate 
this message without the authors express written authority to do so.   
If you are not the intended recipient, please notify the sender then 
delete all copies of this message including attachments immediately. 
Confidentiality, copyright, and legal privilege are not waived or lost 
by reason of the mistaken delivery of this message.

Re: Amavis and OpenDMARC

2023-11-10 Thread Damian

OpenDMARC is setup as a smtpd_milter in Postfix.


So Amavis is setup as an smtpd_milter as well?


Can someone maybe shed some light on why this would be happening or is there a 
different way to handle DMARC?


Do you see DKIM-related Authentication-Results headers in incoming mails?