Re: [mailop] Invalid format and contents of DMARC reports

[Alessandro Vesely via mailop]

On Fri 26/Jul/2024 14:02:43 +0200 Tobias Herkula via mailop wrote:

the empty mail-from is on purpose, it's fire and forget, if you don't
want the reports remove the RUA entry in the DMARC TXT-RR or remove RUA
Address Validation TXT-RRs and we will stop sending them, but we have no
  interest in any Bounces or Responses.



An alternative is to use RFC 3461 NOTIFY=NEVER.

Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Help with handling backscatter

[Alessandro Vesely via mailop]

Il 11/07/24 23:23, Slavko via mailop ha scritto:

Dňa 11. júla 2024 20:01:17 UTC používateľ Jesse Hathaway via mailop 
 napísal:


1.  Why are the non-delivery notifications sent to
 rather than to ?


NDR have to be send to Return-Path of original message, thus it depends
what was in its MAIL FROM. IMO including foreign (google) IP range opens
big hole in SPF.



The bounced message had:

Return-Path: 
To: 

Neither of those seem to have anything to do with the Received: from 
shopify.com line and with the diagnostic (which mentions 
ebuerg...@sbcglobal.net).  I doubt the From: 
_𝐀𝐟𝐟𝐨𝐫𝐝𝐚𝐛𝐥𝐞_𝐖𝐢𝐧𝐝𝐨𝐰𝐬_ (in MATHEMATICAL BOLD) is real, 
and the Subject: doesn't seem to match the content of the message.


Did ARC seals verify?

Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Cloud hosts for responsible mail servers?

[Alessandro Vesely via mailop]

Il 10/07/24 02:18, Lyndon Nerenberg (VE7TFX/VE6BBM) via mailop ha scritto:

I publish SPF records, but refuse to participate in DKIM or DMARC.
By avoiding the latter two, I don't have to navigate all their
associated stupidity, and my mail goes through just fine.



Stupid as it is, DMARC is the best attempt we have at shifting 
reputation gathering from IP numbers to domain names.


Best
Ale
--



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: AT&T Block

[Alessandro Vesely via mailop]

On Sat 06/Jul/2024 18:22:15 +0200 Scott Mutter via mailop wrote:
If we're all tired of seeing "Anyone from BLANK able to help with the IP BLANK 
being blocked?"  Then perhaps this is a nod to BLANK that they need to do 
better at handling these inquiries or that their means of blocking IPs is too 
liberal.



It seems to me that large operators don't care a tinker's cuss about blocking 
small operators.  If I'm unable to send to Outlook users, it is my fault by 
definition, certainly not Outlook's.


Some restrict the audience of possible complainants to the first RIR's 
delegates.  That way a small operator can try to convince its ISP to either 
deal with such questions, or do a RIR registration in its name, neither of 
which is an available option to small customers.


All in all, there is a school of thought which considers email to be a 
convention among gorillas rather than an open standard.


Is that anyhow related to democracy?


Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] envelope or header address?

[Alessandro Vesely via mailop]

On Fri 05/Jul/2024 23:21:17 +0200 Jeff Pang via mailop wrote:

OT question, can return-path be customized by sender MTA/MUA? Or must it  be 
envelope?



Return-path, envelop sender, bounce address and MAIL FROM are all synonyms for 
the same thing.


Mailing lists always change it when they forward a message.  Mass mailers do so 
as well.


Some plain forwarders, à la dot-forward, change it, either to satisfy SPF (SRS) 
or in order to have bounces reach someone who can remove the relevant 
forwarding recipe when its target is removed at the other end.  Some others 
keep it intact, in order to let the original sender become aware of bounces 
(and thus reveal the final destination.)



Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] envelope or header address?

[Alessandro Vesely via mailop]

On Fri 05/Jul/2024 15:00:45 +0200 Jaroslaw Rafa wrote:

Dnia  5.07.2024 o godz. 19:45:10 Jeff Pang via mailop pisze:


When an user requests to join mailing list, which address should we
take? The envelope address, or the header From address?


I think you should follow the best practice, ie. how it is implemented in
the predominant mailing list software (eg. mailman).



That's right.  It is incredible how little standardization exists about mailing 
lists.  For Mailman 3, there are sentences like this:

While configurable, the sender addresses by default are those named
in the From:, Sender:, and Reply-To: headers, as well as the envelope
sender (though we won’t worry about the latter).

https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/runners/docs/incoming.html#sender-addresses

The complicate setup can work around several problems at the crossroads of 
various standards, but there is no standard.


Best
Ale
--






___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Request: UTF-8 email address?

[Alessandro Vesely via mailop]

On Sat 29/Jun/2024 21:04:35 +0200 John Levine via mailop wrote:

PS: before you tell me I don't know what I'm talking about, you might take
a look at this:

https://uasg.tech/download/uasg-030-evaluation-of-eai-support-in-email-software-and-services-report-en/



Contrary to all publishing traditions, the paper exhibits no author names. 
Only in the last page, as part of the Github URL of the tools, the string 
jrlevine appears.



Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Why an SPF hard bounce on ~all ?

[Alessandro Vesely via mailop]

On Thu 27/Jun/2024 21:41:39 +0200 Adam D. Barratt via mailop wrote:

On Thu, 2024-06-27 at 14:50 -0400, Ted Smith via mailop wrote:

That conbined with the hard fail indicated could account for the
rejection of the message, except that I don't understand why the SPF
check would be done for the helo hostname of the forwarding server,
and why that result would take precidence over the SPF result for the
actual sender domain.
 
 Since SPF is supposed to verify that the senders, why would postfix-

policyd-spf-python be looking up the SPF record for the helo hostname
of the forwarding mailserver and determining what to do based on
that?  If my explanation is correct there is clearly something I'm
missing about SPF enforcement, or is there some other possible
explanation I'm unaware of?


The usual case where the HELO becomes involved in SPF checks would be
when the mail is a bounce, i.e. has a NULL envelope sender.



That is the restricted use of SPF promoted by DMARC.  The SPF spec recommends 
to preferably use HELO, if available.  Full wording:


   It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM"
   identity but also separately check the "HELO" identity by applying
   the check_host() function (Section 4) to the "HELO" identity as the
   .  Checking "HELO" promotes consistency of results and can
   reduce DNS resource usage.  If a conclusive determination about the
   message can be made based on a check of "HELO", then the use of DNS
   resources to process the typically more complex "MAIL FROM" can be
   avoided.  Additionally, since SPF records published for "HELO"
   identities refer to a single host, when available, they are a very
   reliable source of host authorization status.  Checking "HELO" before
   "MAIL FROM" is the RECOMMENDED sequence if both are checked.
   https://datatracker.ietf.org/doc/html/rfc7208#section-2.3


Best
Ale
--






___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Large Volume of Emails in Violation of Acceptable Use Policies

[Alessandro Vesely via mailop]

On Fri 28/Jun/2024 11:34:13 +0200 Richard Clayton via mailop wrote:

Finally, you may be seeing X emails per time period from Y people.



Messages sent from Y machines are a different matter, methinks.  Except for 
expressly requested monitoring services, automatically generated messages 
should not be allowed.  AI machines willing to exercise their generative power 
had better talk to other AI machines.



Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] reverse proxy for smtp client

[Alessandro Vesely via mailop]

On Mon 24/Jun/2024 12:16:32 +0200 Marco Moock via mailop wrote:

Am 24.06.2024 um 12:03:49 Uhr schrieb Alessandro Vesely via mailop:


IME, large sending times are often caused by IMAP.  Most clients
operate by first sending the message and then saving it in the Sent
IMAP folder.  Just changing that method to Bcc: halves the time
required.


Why should using Bcc: change that the client saves the message in
Draft/Sent via IMAP?



I meant if the client is able to send to Bcc: /instead/ of saving the message 
via IMAP.  Otherwise it can be done on the server, but you need to synchronize 
start adding Bcc: with the user telling the client not to save any more (and 
vice versa).


I automatically prepare a -sent (or +sent) alias to the 
Sent folder of every new user.  Some can setup their clients to use it.


Draft saving usually is not a worry, as the client does it while-U-type, and 
thus you don't have to wait for it.



HTH
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] reverse proxy for smtp client

[Alessandro Vesely via mailop]

IME, large sending times are often caused by IMAP.  Most clients operate by 
first sending the message and then saving it in the Sent IMAP folder.  Just 
changing that method to Bcc: halves the time required.



Best
Ale

On Sat 22/Jun/2024 09:45:36 +0200 Jeff Pang wrote:


Hello

that's b/c the attachment can be sent as 100MB between users.
some users said they are hard sending large mail, so I am asking the question.

Thanks.


Although, I am interested in how much the latency affects the
submission and how much that impacts your users.



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] too many bad IP blocked

[Alessandro Vesely via mailop]

On Fri 21/Jun/2024 18:12:13 +0200 Ralph Seichter via mailop wrote:

* Jeff Pang via mailop:


given currently I have 3000+ block IPs, every normal client requests
to submission, the ip will be checked through those 3000+ list, which
slow down the normal client's connection certainly.


I consider this is a case "measure, don't guess". I am right now logged
into at a none-too-fancy server moving terabytes of data per day, with
thousands of iptables entries -- without breaking a sweat. Some RAM and
CPU cycles are of course required, but unless you have concrete evidence
of your server struggling, you may be jumping at shadows.



That's still more of a moral judgment than a measure.  Setting up the system 
takes time, and when you feel satisfied of how it works under the current load, 
you certainly don't want to change it.

Research[*] shows that thousands of rules are fine, but hundreds of thousands 
bring it on its knees.  I attach a picture.


Best
Ale
--

[*] 
https://kinvolk.io/blog/2020/09/performance-benchmark-analysis-of-egress-filtering-on-linux

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] too many bad IP blocked

[Alessandro Vesely via mailop]

On Fri 21/Jun/2024 14:55:16 +0200 Slavko via mailop wrote:

Dňa 21. júna 2024 11:50:23 UTC používateľ Alessandro Vesely via mailop 
 napísal:


That db currently holds 2,014,973 records.  Rather than ipset or single 
iptables rules, the IPs are stored on a Berkeley DB.  They get blocked by a few 
iptables rules ending in -j NFQUEUE.  That passes the packet to a userspace 
daemon which consults the database and decides whether to drop the packet or 
not.  See https://savannah.nongnu.org/projects/ipqbdb/

It's much more do-it-yourself than fail2ban.


I use fail2ban's bantime increment to incremental bantime with custom
action, which on configured repeat count adds IP to "permanent" ipset
(currently when bantime reach 60 days). That permanent ipset is daily
inspected (by cron job), its counters are stored in sqlite DB and removed
after (configurable -- currently 120 days) time of inactivity. Ipset itself
allows to process IPv6 in /64 manner, thus no need to worry.

While fighting with Submission/IMAP logins i found, that max ipset's
timeout (~24 days) is not enough to catch botnet repeating - common
repeat interval was ~50-60 days.



I keep them short.  I track "good" IPs and don't report their failed logins. 
However, it's still possible for real users to flunk their password.  This kind 
of bans have to rehabilitate rather quickly.


Login attempts don't seem to follow any kind of decent dictionary attack 
strategy, as they try random userid/ password combinations, and repeat failed ones.


Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] too many bad IP blocked

[Alessandro Vesely via mailop]

On Fri 21/Jun/2024 10:55:53 +0200 Jeff Pang wrote:

Here is the drop list by iptables,
https://cloud.hostcache.com/drop.list

can you help take a look?



Of those 2805 addresses, 2726 are also on my block db, 79 are not.

That db currently holds 2,014,973 records.  Rather than ipset or single 
iptables rules, the IPs are stored on a Berkeley DB.  They get blocked by a few 
iptables rules ending in -j NFQUEUE.  That passes the packet to a userspace 
daemon which consults the database and decides whether to drop the packet or 
not.  See https://savannah.nongnu.org/projects/ipqbdb/


It's much more do-it-yourself than fail2ban.

It would be instructive to find a way to measure the server's slackening before 
changing method.  It is a memory vs. disk question.



Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Debugging fwd issue meta.com to zoho.com (Help from user under meta.com needed)

[Alessandro Vesely via mailop]

On Sun 16/Jun/2024 16:38:48 +0200 Tobias Fiebig via mailop wrote:


You'd need several domains, all having a rua= pointing to you.  I'd 
donate a (sub) domain to that effort.  I'm donating a couple of 
domains to Project Honey Pot.  Unlike that project, however, in this 
case donated domains will have to actively send replies.


Actually LUA records with powerdns should suffice; Similar to what is 
already being done for the DNS tests:


dig MX sometext.uniq.measurement.email-security-scans.org \
 @dns.measurement.email-security-scans.org

So, creating something like
_dmarc..dmarcfail.measurement.email-security-scans.org, and
only sending the mails after at least N mails for the test have been
successfully received.



In theory, that's correct.  However, we'd need both domains matching the PSL as 
well as domains matching tree walks.  I'm not familiar with PowerDNS, but 
clients will query their usual DNS servers and resolve.  Setting up domains 
correctly won't be easy.

_dmarc.sometext.uniq.measurement.email-security-scans.org -> v=spf1 mx 
ip4:195.191.197.88 ip6:2a06:d1c0:dead:3::88 -all
_dmarc.uniq.measurement.email-security-scans.org -> v=spf1 mx 
ip4:195.191.197.88 ip6:2a06:d1c0:dead:3::88 -all
_dmarc.measurement.email-security-scans.org -> v=spf1 mx ip4:195.191.197.88 
ip6:2a06:d1c0:dead:3::88 -all
_dmarc.email-security-scans.org -> v=DMARC1; p=reject; 
rua=mailto:dm...@aperture-labs.org

There will also be confirmation RRs for rua= at external domains (some will 
have to not be confirmed, to check for that check).

Some subdomains will have DMARC records, some not.  Perhaps, some mails can be 
sent from real IPs, if their owners are not afraid to be blacklisted.

I agree the same effect can be obtained by creating lots of subdomains, but 
that wont work for filters still using the PSL.

In addition, having domain donors might boost cooperation.


Best
Ale
--



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Debugging fwd issue meta.com to zoho.com (Help from user under meta.com needed)

[Alessandro Vesely via mailop]

On Sat 15/Jun/2024 18:27:15 +0200 Tobias Fiebig via mailop wrote:


Do reports received at dm...@aperture-labs.org contribute to the 
output of email-security-scans?


No, of course not; esec.o is tests-are-atomic. Technically I _could_ 
(or rather: should) try to implement something similar to what I am 
already doing for the TLS-RPT test for DMARC _sending_ as well 
(currently, I am only testing deliverability of RUA/RUF).



TLS-RPT reports seem to be more useful than DMARC ones.  I, for one, forward 
them to a daily-seen folder when they contain failed connections, which doesn't 
happen every day.  (In some cases, I remove the blocked IP from the firewall.)


DMARC reports have a plethora of failures every day, due to mailing lists. 
Sporadically, I take a look at them, but not always, and never sum them up.




However, I skipped on that initially, because:
- It is more about receiving than sending (and esec.o was initially
   sending focused)
- It is difficult to fill in an identifier there; Technically, I could,
   e.g., send from unique domains (difficult, as some large domains are
   now blocked for the startup mail and have a web-only-flow; Also,
   deliverability for that is likely low(er)), or add something where
   you can request the DMARC test in addition when you submitted the
   some test results. Sending DKIM&SPF invalid mails for the test should
   further reduce the noise (while still triggering reports). However,
   that would have to be implemented, and I am currently struggling with
   the very stupid idea somebody had some when that a day should just
   have 24h.



Some hold DKIM reports are to be delivered just around midnight.

You'd need several domains, all having a rua= pointing to you.  I'd donate a 
(sub) domain to that effort.  I'm donating a couple of domains to Project Honey 
Pot.  Unlike that project, however, in this case donated domains will have to 
actively send replies.




Similarly, it would kind of make sense to maybe tie in the internet.nl
suite and display/integrate those results as well. But again, time.

So, somewhat related: If somebody suffers from an abundance of time, is
kind of good with python, mail, and PHP... and would like to work on
what is objectively likely some of the worst code they have ever
seen... drop me a line. ;-)



I'm tempted, although Python is not my forté.


Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Debugging fwd issue meta.com to zoho.com (Help from user under meta.com needed)

[Alessandro Vesely via mailop]

On Thu 13/Jun/2024 11:14:04 +0200 Tobias Fiebig via mailop wrote:


What if spamd, while authenticating a malformed signature, notifies 
the error in DMARC report?  Would that "fix" spamd?


Would be somewhat pointless, though; From the top of my head I am not 
sure whether there is a fitting field; And apart from that, I doubt 
anyone would read those mails (or, rather, parse it into the DMARC 
webif in use and display it in a way anyone would notice).


Also, there should be enough implementations out there that do not 
verify DKIM there; So you _should_ already see the spike in non-passing 
DKIM messages, incl. from your own senders.



There is a /human_result/ in DMARC reports.  It would be a good idea to check 
whether there are (new) messages there, and bring it to human attention in 
case.  Not doing so deprives the field of its /human/ attribute.


Yes, bounces are certainly more noticeable.  However, they only happen on 
p=reject.  Otherwise, failure spikes being more noticeable than human results 
just bespeaks the quality of report consumer software.


Do reports received at dm...@aperture-labs.org contribute to the output of 
email-security-scans?



Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Debugging fwd issue meta.com to zoho.com (Help from user under meta.com needed)

[Alessandro Vesely via mailop]

On Sun 09/Jun/2024 02:43:38 +0200 Tobias Fiebig via mailop wrote:

On Sat, 2024-06-08 at 12:36 +0200, Alessandro Vesely via mailop wrote:

... (unless bugs in email-security-scans are just decorative.)


Which ones exactly?



What if spamd, while authenticating a malformed signature, notifies the error 
in DMARC report?  Would that "fix" spamd?



Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Debugging fwd issue meta.com to zoho.com (Help from user under meta.com needed)

[Alessandro Vesely via mailop]

On Sat 08/Jun/2024 13:28:30 +0200 Slavko via mailop wrote:

Dňa 8. júna 2024 10:36:44 UTC používateľ Alessandro Vesely via mailop 
 napísal:


Yes, as it seems Tobias is going to file a bug against rspamd, I presume you 
are going to somehow fix it (unless bugs in email-security-scans are just 
decorative.)


I have nothing to do with email-security-scans, and very little to do
with rspamd (i only use it)...

Thus no, i will not (be able to) fix anything about this ;-)



Oops, I must have meant Vsevolod.  Sorry, these Slavic names confused me...


Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Debugging fwd issue meta.com to zoho.com (Help from user under meta.com needed)

[Alessandro Vesely via mailop]

On Fri 07/Jun/2024 17:03:00 +0200 Slavko via mailop wrote:

Dňa 7. júna 2024 14:37:24 UTC používateľ Alessandro Vesely via mailop 
 napísal:


If I were Slavko I'd fix rspamd by adding bug reporting (if it's not already 
there) rather than removing 2047-decoding.


Are you sure, that you did mean me?



Yes, as it seems Tobias is going to file a bug against rspamd, I presume you 
are going to somehow fix it (unless bugs in email-security-scans are just 
decorative.)  The fix I propose requires they to also consider DMARC reports, 
which would be cool.



I was just curious about IDNA syntax in this case...



Just got this:

Authentication-Results: mx.google.com;
   dkim=pass header.i=@foà.it header.s=gamma header.b=Akp+6zYW;
   spf=pass (google.com: domain of postmaster@foà.it designates 
94.198.96.74 as permitted sender)


Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Debugging fwd issue meta.com to zoho.com (Help from user under meta.com needed)

[Alessandro Vesely via mailop]

On Wed 05/Jun/2024 11:58:53 +0200 John Levine via mailop wrote:

It appears that Tobias Fiebig via mailop  said:
Well, that would then be rspamd and the python email parser; Question 
is whether that would qualify as a bug, i.e., 'should not validate'; My 
understanding would be more in a 'be liberal in what you accept and 
conservative and what you send'-sense, though; I.e., even though not 
technically allowed no harm in validating.


That's a common misunderstanding of the robustness principle. You 
should be liberal in what you accept *when the spec is ambiguous.* 
Other than that you should be prepared for people to send you any 
arbitrary garbage so you can reject it.


In this case, if DKIM validators correctly rejected the invalid 
signatures, this mistake would have been caught and fixed more 
quickly.



Would it?  That certainly depends on the ability of the signer to understand 
the reason a message bounced (assuming that a "fail" would have triggered a 
bounce.)  Unlikely.


There is a field in DMARC report where a generator can put a human readable 
sentence to describe DKIM verification results.  If I were Slavko I'd fix 
rspamd by adding bug reporting (if it's not already there) rather than removing 
2047-decoding.  Still, I wonder whether any report consumer highlights messages 
containing (new) human readable fields...



Best
Ale
--



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [STATE OF THE UNION] Tales from the Trenches..

[Alessandro Vesely via mailop]

On Fri 31/May/2024 14:59:24 +0200 Slavko via mailop wrote:

Dňa 31. 5. o 11:51 Alessandro Vesely via mailop napísal(a):


What RBLs do you configure?


Beside my own RBLs i use DROP & AuthBL from SpamHaus, BIP from 
virusfree.cz, and multiple codes from dronebl.org. They are queried 
in paralel, thus count doesn't have big inpact.



Lots of queries, aren't they?  I only use Smpamhaus zen and DNSWL for 
whitelisting, for receiving SMTP.  My own RBL blocks via iptables.


At the end of the day I check all login addresses against abuseIPDB, which is 
not an RBL; it has a web interface.



But rejects based on RBL are tiny part of rejects, almost all are (was) 
by GeoIP here, namely (from my head, without order) AR, BR, US, ID, 
RU and some others. You can see some monthly cartographs here: 
https://foto.slavino.sk/index.php?/category/msa_blok



Nice graphics!

I don't block based on country, because users sometimes travel.

I only use GeoIP to skip sending complaints to some countries.  Most of them 
are password guessing attempts.



(I stop to generate them, as attempts count significantly decreased 
in last months)



The opposite for me.  They doubled in the last three weeks.


Best
Ale
--






___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [STATE OF THE UNION] Tales from the Trenches..

[Alessandro Vesely via mailop]

On Thu 30/May/2024 23:12:17 +0200 Slavko via mailop wrote:

Dňa 30. mája 2024 19:56:01 UTC používateľ Michael Peddemors via mailop 
 napísal:


However, it isn't as simple as blocking every IP that bangs on your door.  If 
you block large CGNAT IP's for instance, one compromised IoT device behind that 
IP can stop hundreds of legitimate users.


Yes, that is a problem and i am aware of it. Fortunately 
i needn't to bother with it yet.



What RBLs do you configure?



But, of course, IPs can be white listed, as partial solution in it...



I'd be curious how you have your users whitelisting IPs or domain names...


Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Alessandro Vesely via mailop]

On Sat 18/May/2024 19:37:44 +0200 Dave Crocker via mailop wrote:

On 5/17/2024 7:12 AM, Taavi Eomäe via mailop wrote:


We hope that with some cooperation from mail operators improved defense 
measures can be implemented to strengthen DKIM for everyone.


As I recall, the original intent was to permit successful use of DKIM in spite 
of mailing lists' addition of footer text.



Ironically, to verify a DKIM signature after MLM transformation is more 
difficult, IME, if the original signature had l= than otherwise.  The reason is 
that using l= implies signing Content-Type:, which is a technical field that 
MLMs /need/ to change, and recovering its original value requires too much 
guesswork.


Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Doesn't ARC substitute DKIM at Gmail inbound?

[Alessandro Vesely via mailop]

On Mon 06/May/2024 19:00:24 +0200 Brandon Long wrote:

On Mon, May 6, 2024 at 12:41 AM Alessandro Vesely via mailop 
 wrote:

The question is, since Gmail seems to require a DKIM signature just to 
make sure some domain is responsible for the message, doesn't an ARC seal 
cover the same requirement? >

[...]

The challenge with Gmail's new rules and forwarding is that they want you to 
provide an authentication signal (spf or dkim), but you also don't really 
know what you're sending, so doing so can result in a negative effect on 
your reputation.  How to square that circle is left as an exercise to the 
reader.  DKIM signing or using SPF would potentially solve that.


Fair enough, thank you.  I replace the bounce address (because in case of 
problems I need to inform the recipient rather than the author) so they're 
authenticated, albeit unwillingly and unaligned.


For reputation, I skip forwarding messages with SA score >= 9.

ARC seems to be a useless exercise, for the time being.


The flip-side is if the Gmail "dkim required for major senders" message 
could be talking about the actual source before forwarding, in which case 
adding dkim or spf at the forwarder won't help.  The request then is more 
like DMARC, looking for some level of alignment between the source and 
authentication.  ARC was designed to help for that case, assuming the 
message was DKIM signed in by the sender in the first place. Unfortunately, 
one of the reasons that ARC is experimental is that solving the "trust" part 
on forwarding is non-trivial well, sorta, explicit opt-in of forwarders 
would work fine.  In the case of someone forwarding their mailbox from a to 
b, having that specific account say "I'm forwarding from A, accept forwarded 
mail from them" would solve the issue,at the challenge of requiring user 
opt-in.



Yeah, I briefly discussed with your colleague Wei Chuang about experimenting 
that way to fix forwarding...  But that's another topic.



Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Doesn't ARC substitute DKIM at Gmail inbound?

[Alessandro Vesely via mailop]

On Sun 05/May/2024 19:44:57 +0200 Benny Pedersen via mailop wrote:

Andrew C Aitchison via mailop skrev den 2024-05-05 18:49:

On Sat, 4 May 2024, Alessandro Vesely via mailop wrote:


The last URL in the response says something about ARC:

   ARC checks the previous authentication status of forwarded messages.
   If a forwarded message passes SPF or DKIM authentication, but ARC
   shows it previously failed authentication, Gmail treats the message as
   unauthenticated.

Isn't it overkill to put both DKIM /and/ ARC if you know the receiver 
implements both?


I don't think so.

DKIM proves that you did send it.
ARC proves that you forwarded what you received ?


without trustness ?



An ARC-Signature is very much the same thing as a DKIM signature.  They both 
prove that a message went through the signing server.  Then, ARC additionally 
conveys authentication results, which is what makes it suited to forwarding.




ARC-signer/ARC-Sealers have to be trusted, to make any different



Trust is required if you're going to make decisions based on that seal, such as 
overriding DMARC policy.  In the case at hand, the author domain DKIM signature 
was not valid and the DMARC record said p=none, so trust was not needed.




is arc btw ensure tested in dmarc ?, trustness or ?



DMARC adds policy. It requires the From: domain to be aligned with DKIM or SPF. 
 When you forward you don't rewrite From:, so it's not aligned, and a DKIM 
signature wouldn't help getting a dmarc=pass.  There's no requirement that 
ARC's d= be aligned with anything.  (Should forwarders rewrite the bounce address?)


The question is, since Gmail seems to require a DKIM signature just to make 
sure some domain is responsible for the message, doesn't an ARC seal cover the 
same requirement?



Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail has a thing about dots

[Alessandro Vesely via mailop]

On Thu 02/May/2024 21:02:28 +0200 John Levine via mailop wrote:

While debugging something else, I've been trying to send messages to myself
from the address a...@m.jl.ly.  RFC 5321 says two dots in a row need to be
quoted, and I have checked that my mail system does indeed put in the quotes
and it says

MAIL FROM:<"a..b"@m.jl.ly>



Useless to recall the famous sentence of RFC 5321, where it defines the address 
syntax (Section 4.1.2):


   While the above definition for Local-part is relatively permissive,
   for maximum interoperability, a host that expects to receive mail
   SHOULD avoid defining mailboxes where the Local-part requires (or
   uses) the Quoted-string form or where the Local-part is case-
   sensitive.


Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Doesn't ARC substitute DKIM at Gmail inbound?

[Alessandro Vesely via mailop]

Hi,

I sometimes get this response:

   421-4.7.30 This mail has been rate limited because DKIM does not pass. Gmail
   421-4.7.30 requires all large senders to authenticate with DKIM.
   421-4.7.30
   421-4.7.30 Authentication results:
   421-4.7.30 DKIM = did not pass
   421-4.7.30 For instructions on setting up DKIM authentication, go to
   421-4.7.30 https://support.google.com/a/answer/180504
   421-4.7.30 To learn more about Gmail's sender policy, go to
   421 4.7.30 https://support.google.com/mail/answer/81126. (token) - gsmtp

It was a forwarded message, so it might happen something went wrong, albeit I 
try and avoid applying changes on forwarded messages.  (Besides, I'm no large 
sender.)


Since I implemented ARC, I don't add a DKIM signature to forwarded messages any 
more, and apply an ARC set instead.  Unfortunately, I get no feedback about 
that, as ARC is missing a reporting part.  I guess Google does verify ARC.


I know that any DKIM or ARC signature has no DMARC relevance on forwarded 
messages, where d= doesn't match the From: domain.  However, the above response 
doesn't mention DMARC, so I wonder whether that message would have passed if I 
had put DKIM instead or ARC.


The last URL in the response says something about ARC:

ARC checks the previous authentication status of forwarded messages.
If a forwarded message passes SPF or DKIM authentication, but ARC
shows it previously failed authentication, Gmail treats the message as
unauthenticated.

Isn't it overkill to put both DKIM /and/ ARC if you know the receiver 
implements both?



Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailop and DKIM signatures

[Alessandro Vesely via mailop]

On Fri 22/Mar/2024 18:04:44 +0100 John Levine wrote:

It appears that Alessandro Vesely via mailop  said:
IME, my heuristic algorithm fails more often because senders "oversign", by 
signing technical such as Content-Type: or Content-Transfer-Encoding: than 
because it meets an unknown transformation, albeit I only see a limited number 
of mailing lists.


I would guess you mostly see lists run by mailman.



Yup, mostly.  A few ones don't have an X-Mailman-Version: field, so they're 
probably not Mailman, but I don't know what tool runs them.



Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailop and DKIM signatures

[Alessandro Vesely via mailop]

On Thu 21/Mar/2024 23:38:22 +0100 Andrew C Aitchison wrote:

On Sat, 16 Mar 2024, Gellner, Oliver via mailop wrote:


Depending on the kind of changes which have been applied to the
message you can reverse the transformations and verify the original
DKIM signatures. A member of this list developed a software to do
this programmatically.


Where can I learn more about this software ?



https://www.tana.it/sw/zdkimfilter/


Best
Ale
--






___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailop and DKIM signatures

[Alessandro Vesely via mailop]

On Thu 21/Mar/2024 15:23:59 +0100 Dave Crocker via mailop wrote:

On 3/21/2024 3:47 AM, Alessandro Vesely wrote:

Mailing lists modify messages in a de-facto standard way.


actually, they don't.  or rather, there is more than one de-facto set of 
modifications and therefore efforts to reverse the modifications is in the 
realm of heuristics, which means sometimes they will work and sometimes they 
won't.



IME, my heuristic algorithm fails more often because senders "oversign", by 
signing technical such as Content-Type: or Content-Transfer-Encoding: than 
because it meets an unknown transformation, albeit I only see a limited number 
of mailing lists.


It's obviously unreliable.  In the cases where it works, it just restores the 
original From: field and renames the other one to Munged-From:.  No accept/ 
reject decisions based on it.



Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailop and DKIM signatures

[Alessandro Vesely via mailop]

On Sun 17/Mar/2024 14:02:23 +0100 Dave Crocker wrote:

On 3/16/2024 1:31 PM, Slavko via mailop wrote:

And the same RCF clearly suggests to leave other (even invalid)
signatures untouched.


Which text in RFC 6376 says that?

Perhaps you are thinking of Section 6.1 which includes:


INFORMATIVE NOTE: The rationale of this requirement is to permit
   messages that have invalid signatures but also a valid signature
   to work.  For example, a mailing list exploder might opt to leave
   the original submitter signature in place even though the exploder
   knows that it is modifying the message in some way that will break
   that signature, and the exploder inserts its own signature.  In
   this case, the message should succeed even in the presence of the
   known-broken signature.


which notes it might be done, but certainly is not advice to do it.  (Also note 
the paragraph is informative rather than normative.  Also note the reference to 
mailing lists, as being discussed here.



Mailing lists modify messages in a de-facto standard way.  It is possible to 
automatically undo such changes and verify the original signature, if it is 
left intact.  For Dave's message I had:


Authentication-Results: wmail.tana.it;
  spf=pass smtp.mailfrom=mailop.org;
  dkim=pass reason="Original-From: transformed" header.d=dcrocker.net;
  dmarc=pass header.from=mailop.org;
  arc=fail (1 set(s)) smtp.remote-ip=91.132.147.157


Best
Ale
--






___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Love how people use SPF records.. Just for a chuckle..

[Alessandro Vesely via mailop]

Further than trimming, they should consider using neutral qualifiers for 
generic mail sites.  "include:spf.protection.outlook.com" can allow 
office users to fully impersonate the save.ca domain.  Setting 
"?include:spf.protection.outlook.com" provides for not rejecting due to 
-all, while not granting "pass".


Best
Ale

On 12/03/2024 03:01, Suresh Ramasubramanian wrote:
This looks more like they’ve been testing several providers and ended up 
with a large spf record that they might want to consider trimming.


--srs

*From:* mailop  on behalf of Michael 
Peddemors via mailop 

*Sent:* Tuesday, March 12, 2024 4:24:03 AM
*To:* mailop@mailop.org 
*Subject:* [mailop] Love how people use SPF records.. Just for a chuckle..
host -t TXT save.ca

save.ca descriptive text "v=spf1 ip4:70.33.236.0/25  mx a
include:sendgrid.net include:thestar.ca include:thestar.com
include:spf.google.com include:spf.protection.outlook.com
include:spf.yahoo.com include:spf.aol.com include:amazonses.com -all"

... so.. basically hard block everything except 1/2 the internet..

I assume someone that likes spamming set THAT one up.. there is a good
reason that SPF have a maximum DNS amount of queries..

#   69.39.224.72   2   serviciodeestudios.bbva.com
#   69.39.224.73   2
materialsresearchinstitute.northwestern.edu
#   69.39.224.75   3   serviciodeestudios.bbva.com
#   69.39.224.77   2   email.save.ca
#   69.39.224.78   2   libetwitt.liberation.fr
#   69.39.224.79   1   producteursdici.intermarche.com
69.39.224.72/29

No need to comment more of course..



--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com  
@linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca 


"LinuxMagic" a Reg. TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop 



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] % in SRS ?

[Alessandro Vesely via mailop]

On 09/03/2024 12:21, Lena--- via mailop wrote:

You will still run into a fair number of systems that still see % as
an attempt to do source routing and reject the message.


Including default Exim config:

https://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_default_configuration_file.html

denydomains   = !+local_domains
 local_parts   = ^[./|] : ^.*[@%!] : ^.*/\\.\\./
 message   = Restricted characters in address




Exim, like Postfix, Courier and others calls it "percent hack".


Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Filter out emoji from email adresses

[Alessandro Vesely via mailop]

On 06/03/2024 20:18, Slavko via mailop wrote:

Dňa 6. marca 2024 18:13:34 UTC používateľ Bill Cole via mailop 
 napísal:


support for SMTPUTF8 *in MTAs operating as MXs* is not widespread enough to be 
useful


Only exim (+ Python and ClawsMail) is usable in that...



Courier-MTA + Thunderbird work fine as well, for another one.


Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Why is mail forwarding such a mess?

[Alessandro Vesely via mailop]

On Sat 10/Feb/2024 13:10:19 +0100 Archange via mailop wrote:

Le 10 février 2024 15:12:29 GMT+04:00, Hal Murray via mailop 
 a écrit :


I was picturing something like:
   user goes to final MTA and says I want you to accept forwarded mail for me 
from example.com
   then he goes to example.com and says "please forward my mail to 
m...@final.com"
   example.com would then contact final.com and say "OK if I forward me's mail to 
you?"
If yes, then example.com says "Here are the IP addresses I use for 
forwarding"


I had a similar idea but much more simple: we just keep the part where the user 
says to the final MTA with which they have u...@domain.org that they are 
“forwading from m...@forwarder.org”.

Then, when receiving an email SRS rewritten from forwarder.org to that 
u...@domain.org, the final MTA could check DKIM against the original domain but 
SPF and ARC against the forwarder domain since it is expecting mail to be 
forwarded that way for that user. Kind of a new domain alignment.



That would work indeed!  And it matches the intended use of ARC, so it would 
work for mailing lists as well.


The difficult part is having the user do the liaison correctly, but then it has 
to work only for the class of users who are able to set up forwarding and/or 
subscribe to mailing lists.


I even wrote a draft[*] for a protocol whereby a forwarder can ask the final 
MTA to get its own user's confirmation.  The user would then receive something 
that looks like a (second) opt-in confirmation message, pointing to her mailbox 
provider's.


I asked Gmail if they would experiment with it, but they found it overly 
complicated, and after a brief discussion don't seem to be interested.  I 
should look for some other receiver(s)...



Best
Ale
--

[*] https://datatracker.ietf.org/doc/html/draft-vesely-fix-forwarding






___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DKIM validity period

[Alessandro Vesely via mailop]

On Thu 21/Dec/2023 22:26:34 +0100 Gellner, Oliver wrote:
If Google would have published their DKIM private key after it was rotated in 
2016, checking the DKIM signature in 2020 would have proven nothing.



Yet, if the message was ARC-sealed on forwarding and the forwarder didn't 
rotate and publish its keys, repudiation would still be unavailable.



Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] ECDSA DKIM validation?

[Alessandro Vesely via mailop]

My point is not cryptographic merit.  FWIW, any DKIM algorithm is way more 
secure than what we need to authenticate emails, even RSA-SHA1 with 700bytes 
keys (oh well, 512b keys were broken as a proof of concept some time ago.)  As 
Oliver pointed out, all those algorithms are more than enough good for our purpose.


I understand ed25519 can be skipped with minor inconveniences.  However, for 
compliance, I'd have expected major mail sites to conform to the standard, 
while small servers possibly lagged behind.  Instead, the opposite happens.


There was a period when OpenSSL didn't fully support an algorithm, but that's 
now over.  The path is well paved.


John wrote:

If there's two signatures for the same domain, one is good and one is bad, 
which do you believe?


The choice between SHA-1 and SHA-256 has been there for years, and no one had 
troubles wondering what to do with two sigs by the same domain using different 
hashes one of which verifies while the other does not.  It's trivial.  How does 
an elliptic curve put a wholly different problem?


I don't think Google have budget problems either...


On Thu 21/Dec/2023 17:38:01 +0100 Slavko via mailop wrote:

Dňa 21. decembra 2023 15:05:08 UTC používateľ Alessandro Vesely via mailop 
 napísal:


It seems only (few) small servers dare implementing ed25519.

I don't understand why.


Do you really don't understand that or do you afraid of what is
comming into mind?

AFAIK:

+ collaboration of NSA & RSA (and results) is known
+ question about selection of EC curves are unanswered
+ no known doubts about Ed curves

It seems, that Edward curves are not as good for some parties
as are for others, thus they want to preserve current state as
long as possible. Perhaps once new Snowden will reveal reason...

regards



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] ECDSA DKIM validation?

[Alessandro Vesely via mailop]

On Thu 21/Dec/2023 14:53:55 +0100 Mike Hillyer via mailop wrote:

John Said:

I'm sure that Google has code somewhere that can validate ED25519 
signatures.  But that does not mean that it would be a good idea for them 
to use that code in production today and try to update their reputation 
systems to deal with the dual signing that implies.


With the number of messages already arriving with multiple DKIM signatures I 
can't imagine their reputation systems don't already handle dual signing just 
fine.



Google keep reporting fail for ed25519 signatures.  Ditto for 
Comcast.  Yahoo say permerror, like Verizon.  Microsoft don't 
even mention that selector...


It seems only (few) small servers dare implementing ed25519.

I don't understand why.  The meaning of signatures is not altered by the a= 
tag, so updating a reputation system in order to accomodate a different 
verification algorithm should only require a small, localized change.  Not a 
staggering defeat.


What am I missing?


Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] ECDSA DKIM validation?

[Alessandro Vesely via mailop]

On Thu 21/Dec/2023 10:37:52 +0100 John Levine via mailop wrote:

It appears that Alessandro Vesely via mailop  said:

RFC 8463 still reads out:

   Signers SHOULD implement and verifiers MUST implement the
   Ed25519-SHA256 algorithm.


Implement is not a synonym for use.

Yes, your code should handle them.  No, that doesn't mean you should sign with 
them.



Yup.  The question was why Gmail doesn't /verify/ ed25519 signatures. 
Answering that they do so because it's not necessary to use them doesn't sound 
real.  That way, they are damaging the halo of steady innovators that their 
pushing on authentication might evoke...



Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] ECDSA DKIM validation?

[Alessandro Vesely via mailop]

On Tue 19/Dec/2023 22:12:28 +0100 Gellner, Oliver via mailop wrote:

On 19.12.2023 at 12:19 Alessandro Vesely via mailop wrote:
On Tue 19/Dec/2023 09:21:55 +0100 Taavi Eomäe wrote:

Considering how Gmail and quite a few widespread DKIM implementations still 
don't support EdDSA DKIM, I wouldn't get my hopes too high.


Won't any Google insider shred some lite on why a generally technically sound 
company lags like that?


I‘m not an insider but I could imagine that DKIM signatures which use EdDSA and ECDSA are solutions to a problem that has not yet been discovered. 
2048 bit RSA keys are small *enough* and fast *enough*. As long as they can be considered secure it’s a waste of resources to run a dual DKIM setup for years or possibly decades.



RFC 8463 still reads out:

   Signers SHOULD implement and verifiers MUST implement the
   Ed25519-SHA256 algorithm.

Keys and signatures lengths are *quite* different.  Considering that any crypto 
library a filter loads by now certainly includes ed25519 code anyway, what 
resources would a dual DKIM setup waste?  The difference is just a couple of calls.


It is a waste of resources to force continued usage of the longer keys...


Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP smuggling

[Alessandro Vesely via mailop]

On Tue 19/Dec/2023 21:19:06 +0100 Marco Moock via mailop wrote:

Am 19.12.2023 um 17:20:20 Uhr schrieb Slavko via mailop:

Please, understand i properly, that it is no vulnerabiliy in SMTP 
itself, but in (some) implementations/servers only?


According to the stuff I read, sendmail and Postfix (and more) are 
affected, for sendmail a patched version exists and the behavior can be 
controlled in accessdb for specific hosts if needed.



A tool to check vulnerability is trivial if you already have an SMTP client. 
However, they are delaying the publication of their tool "maybe already at the 
37C3 conference", which is to be held on 27-30 December 2023.



Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] ECDSA DKIM validation?

[Alessandro Vesely via mailop]

On Tue 19/Dec/2023 09:21:55 +0100 Taavi Eomäe wrote:
Considering how Gmail and quite a few widespread DKIM implementations still 
don't support EdDSA DKIM, I wouldn't get my hopes too high.



Won't any Google insider shred some lite on why a generally technically sound 
company lags like that?



Best
Ale
--



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DMARC processing

[Alessandro Vesely via mailop]

On Tue 19/Dec/2023 09:47:15 +0100 Eduardo Diaz Comellas via mailop wrote:


I'm starting to deploy DMARC records in all our managed domains, but we don't 
have any specific tool to parse and extract meaningful information from the 
reports.


Do you have any recomendations?



The most basic thing is to transform XML reports into HTML tables[*].  That 
lets you glance at messages quickly.  Not so practical if you have hundreds or 
more reports every day.  The next step is to sum up those figures and deliver a 
daily total, or filter them by exception.  However, having an idea of what each 
report generator sends doesn't hurt.


Best
Ale
--

[*] For example, I use this style sheet:
http://www.tana.it/sw/dmarc-xsl/

More tools here:
https://dmarc.org/resources/code-and-libraries/




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Merry Christmas from Google?

[Alessandro Vesely via mailop]

On 17/12/2023 10:45, Benny Pedersen via mailop wrote:

hopefully mailman will ARC-Sign / ARC-seal before it breaks dkim



That's not the correct way to do it.  Authentication results have to be 
collected on entry, before passing the message to Mailman.  The seal, 
and A-Rs conversion to AAR are to be done later, after Mailman hands the 
message out.



Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Yahoo Feedback Loop

[Alessandro Vesely via mailop]

On Wed 29/Nov/2023 20:01:59 +0100 John Levine via mailop wrote:

According to Alessandro Vesely via mailop :

On Mon 27/Nov/2023 19:28:17 +0100 John Levine via mailop wrote:

It appears that Mike Hammett via mailop  said:

-=-=-=-=-=-
-=-=-=-=-=-

What do you do when someone keeps reporting conversations on a mailman mailing 
list that is opt-in only to Yahoo? ...

I just unsubscribe them.  Life is too short.  If they want to resub,
that's up to them.


You can unsub them even if you don't host the list.  In that case, Mailman ...


Mailman?  Why do you assume Mailman is involved?



It's just the most usual case.  I believe /all/ mailing list offer a way to 
unsubscribe an address, and ask to confirm it (especially if the unsub was 
submitted via a web form.)



Best
Ale
--






___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Yahoo Feedback Loop

[Alessandro Vesely via mailop]

On Mon 27/Nov/2023 19:28:17 +0100 John Levine via mailop wrote:

It appears that Mike Hammett via mailop  said:

-=-=-=-=-=-
-=-=-=-=-=-

What do you do when someone keeps reporting conversations on a mailman mailing list that is opt-in only to Yahoo? 

It seems like they forgot they were on NANOG and are now reporting every message sent to it. 


I just unsubscribe them.  Life is too short.  If they want to resub,
that's up to them.



You can unsub them even if you don't host the list.  In that case, Mailman asks 
them to confirm. Perhaps that's enough for them to realize they reported a 
mailing list post.  Or maybe they confirm, and that was what they really aimed 
to...



Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft's block list?

[Alessandro Vesely via mailop]

On Wed 22/Nov/2023 15:25:36 +0100 Otto J. Makela via mailop wrote:

Can someone shed light on a Microsoft/Outlook block list? Our hobby server
(on upcloud.com) seem to have been blocked for quite some time now.

At this time, SPF and DKIM should be correct for our outgoing messages.
Is there anything to be done, apart from switching to some mail sender
company instead of ourselves attempting a direct connection?

2023-11-15T08:27:37.762372+00:00 mail postfix/smtp[113710]: 7407B6274D: 
to=, 
relay=hotmail-com.olc.protection.outlook.com[104.47.18.97]:25, delay=0.29, 
delays=0.05/0/0.21/0.03, dsn=5.7.1, status=bounced (host 
hotmail-com.olc.protection.outlook.com[104.47.18.97] said: 550 5.7.1 
Unfortunately, messages from [SERVERIPADDRESS] weren't sent. Please contact 
your Internet service provider since part of their network is on our block list 
(S3150). You can also refer your provider to 
http://mail.live.com/mail/troubleshooting.aspx#errors. 
[AM6EUR05FT032.eop-eur05.prod.protection.outlook.com 2023-11-15T08:27:37.743Z 
08DBE4B9C5B508E7] (in reply to MAIL FROM command))



I used to have lots of those "550 5.7.1 Unfortunately, messages from 
[94.198.96.74] weren't sent".  It was caused by MIPSpace, #595 in Valli's 
multirbl.  The IP was already blocked when I got it, last April (but it doesn't 
show up in queries, perhaps because it's private).


MIPSpace only accept delist requests from "a representative of the company 
listed in the SWIP or rwhois", so I cannot even ask.  I solved by using a relay 
for M$'s domains.



Best
Ale
--



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google rate-limiting more aggressively than usual?

[Alessandro Vesely via mailop]

On Sun 19/Nov/2023 00:15:58 +0100 Philip Paeps via mailop wrote:

On 2023-11-18 18:59:53 (+0800), Alessandro Vesely via mailop wrote:

On Fri 17/Nov/2023 15:37:58 +0100 Philip Paeps via mailop wrote:
We do all the things in the Bulk Sender Guidelines (except DMARC because we 
don't want to frustrate our users ability to use third-party mailing lists 
that don't mitigate it).


If you publish p=none you're enabling DMARC without causing any trouble 
whatsoever to any list.


The last time I looked into this (admittedly several years ago now), I still 
found a non-zero number of sites that would drop all email from domains with a 
DMARC record, regardless of the contents of that record.



I don't think someone can drop almost all mail and still call itself a mail 
server.

Even with all the distemper DMARC brought to mailing lists, it is still the 
path to securing email.  Boycotting it is not a good idea.



In addition you can enable reporting, which may occasionally provide some 
insight.


I'm not convinced that insight would be actionable though.  I know I have users 
who won't use the smtp.FreeBSD.org relay.  Knowing who they are won't 
necessarily get me any closer to reducing their number. ;-)



Confirmation of which DKIM signatures are verified is good to know.  I miss the 
analogue feature for ARC.


If you also send aggregate reports, those are an interesting read as well.



BTW, this list itself has p=quarantine and rewrites your From: anyway.

Not that enabling DMARC would free you from UnsolicitedRateLimitError.  I've 
been receiving those since April this year, although I never send bulk email 
yet have all stuff in those guidelines, including DMARC.


Yeah ... Google does what Google does.  Unfortunately, users don't shout at 
Google.



Shouting wouldn't solve problems either.


Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google rate-limiting more aggressively than usual?

[Alessandro Vesely via mailop]

On Fri 17/Nov/2023 15:37:58 +0100 Philip Paeps via mailop wrote:
We do all the things in the Bulk Sender Guidelines (except DMARC because we 
don't want to frustrate our users ability to use third-party mailing lists that 
don't mitigate it).



If you publish p=none you're enabling DMARC without causing any trouble 
whatsoever to any list.  In addition you can enable reporting, which may 
occasionally provide some insight.


BTW, this list itself has p=quarantine and rewrites your From: anyway.

Not that enabling DMARC would free you from UnsolicitedRateLimitError.  I've 
been receiving those since April this year, although I never send bulk email 
yet have all stuff in those guidelines, including DMARC.



Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft lays hands on login data: Beware of the new Outlook

[Alessandro Vesely via mailop]

On Sat 11/Nov/2023 10:52:26 +0100 hg user wrote:

Do you have a list of IPs that are known to be used for this legit service ?



A user of mine used to have logins from my.com (NL), which looks particularly 
suspect as it is a subsidiary of mail.ru.  Mymail behaves similarly to what 
Luis and others described for mail apps.




My boss wants to block access from abroad but that will block several
people, I'm afraid.


What if users travel abroad?

IMHO, it is better to monitor login IPs using services like AbuseIPDB which 
provide an abuse score.



Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] valid DKIM-signed email spam-classified @gmail only; correct PASS @ other server recipients ?

[Alessandro Vesely via mailop]

On Mon 30/Oct/2023 00:37:00 +0100 pgnd via mailop wrote:



An obvious question is what's in the mail.  How does it resemble other
mail that might have been classified as spam?  Please do not use the terms
"DKIM" or "ed25519" in your answer.


anything/everything.

just the word TEST.  pages of text.  attachments of any color.
it doesn't matter.



Do they hate your IP neighbors?  What's https://talosintelligence.com/ saying 
about?



Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Success MiTM attack

[Alessandro Vesely via mailop]

On Tue 24/Oct/2023 06:53:37 +0200 Matt Palmer via mailop wrote:

On Tue, Oct 24, 2023 at 03:11:06AM +0100, Richard Clayton via mailop wrote:

In message <07d58480-7dde-4d15-a5ca-5bb6c8e10...@mtasv.net>, Matt Palmer
via mailop  writes

The relative "noisiness" of the attack, in fact, is a fairly strong signal 
that it *isn't* lawful intercept; western law enforcement agencies are 
typically very hesitant to do anything that could "tip off" the target of 
their investigation.


In my, perhaps jaundiced, view the revelation of the attack (an expired 
cert) suggests that it was indeed LI ... it's the sort of thing that 
goes wrong with ad hoc arrangements.


I would contend that p(noisy hackers) >> p(noisy lawful intercept).  It's 
not that the cops don't screw up now and then, but rather that their 
failures tend to have greater adverse consequences (media, politicians, 
blown investigations, abrupt career termination, etc), so they're more 
motivated to not make this sort of mistake.


Meanwhile, hackers (and I include most of the non-western nation states 
here) don't have to worry about PR problems, so forgetting to clean up after 
themselves is less of a concern.  The exception of course is opsec failures 
that lead to lengthy terms of incarceration, but forgetting to renew a cert 
isn't *that* kind of mistake.



Is that the way it went?  Let's Encrypt certificates get renewed automatically, 
so it's hard to "forget" to do it.  In order to get those certificates, and to 
divert traffic toward their proxy, they must have had access to a local router 
or something.  When that was fixed, fake certificates failed to renew.  No?


I'm not clear what the role of an anonymous cipher would have been.


Best
Ale
--



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Success MiTM attack

[Alessandro Vesely via mailop]

On Sun 22/Oct/2023 13:18:53 +0200 Hans-Martin Mosner via mailop wrote:

Am 22.10.23 um 12:23 schrieb Paul Menzel via mailop:
It was interesting and surprising to me, as the common perception is, that 
SSL certificates protect against MiTM attacks as it should provide authenticity. 


The weak point of SSL certificates is that clients are willing to accept new 
certs for the same domain as long as their signature path is correct (ending at 
one of the trusted root CAs). State-level agents may have ways of obtaining a 
certificate for a third party from a trusted authority, as long as they 
convince the authority that their interception request is lawful.



That would be a show stopper for Let's Encrypt and EFF, methinks.

The Summary and finale section starts with the paragraph:

The attacker managed to issue multiple SSL/TLS certificates via Let’s
Encrypt for jabber.ru and xmpp.ru domains since 18 Apr 2023

However, they don't hypothesize on how that was possible.  Is that due to 
anonymous ciphers being enabled?  How?  The whole point of a certification 
authorities is that third parties /cannot/ manage to issue copies of whatever 
certificate at will.



Best
Ale
--






___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Filtered DNS at hhs.gov

[Alessandro Vesely via mailop]

That's strange.  The same server replies on one query but not the other:

ale@pcale:~$ dig +short +norecurse @158.74.30.103 bounce.connect.hhs.gov txt
"v=spf1 ip4:158.72.139.19 ip4:158.70.144.146 include:cust-spf.exacttarget.com 
-all"
ale@pcale:~$
ale@pcale:~$ dig +short +norecurse @158.74.30.103 _dmarc.bounce.connect.hhs.gov 
txt
;; communications error to 158.74.30.103#53: timed out
;; communications error to 158.74.30.103#53: timed out
;; communications error to 158.74.30.103#53: timed out
;; no servers could be reached

Note that the server is firewalled and is not reachable by ping or traceroute.

I suspect they tried to put a filter on port 53 too, to avoid too many queries, 
and filter off _dmarc because it is an invalid host.  Sounds real?!?


Best
Ale
--



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] fastmail and sender score snafu

[Alessandro Vesely via mailop]

On Mon 09/Oct/2023 08:23:33 +0200 Robert Mueller via mailop wrote:


I see that current setup might be useful in case some user changes MX 
before the domain is activated at Fastmail, in which case giving 4xx 
could make sense. But it is not right to report such re-tries to sender 
score as attempts to deliver to non-existing users.


Yes, this is why we 4xx rather than 5xx email sent to an unconfigured domain. 
Many inexperienced email users aren't sure exactly what order to change or set 
things up in and we've seen users lose email before because they changed the MX 
records before adding their domain at Fastmail. The 4xx response reduces the 
chance of lost email.



That's bad.

First, nobody sends an important mail to a new domain without double checking 
its delivery.  It is very reasonable to loose a few test messages when you set 
a new domain up.


By 4xx any unconfigured domain, a warning for delayed email can take hours and 
several attempts.  A 5xx would result in an immediate DSN, which is much better 
in case of mistyping.



Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Authentication Bounces by Gmail

[Alessandro Vesely via mailop]

On Sun 17/Sep/2023 18:58:05 +0200 Ángel via mailop wrote:

On 2023-09-15 at 10:26 +0200, Alessandro Vesely via mailop wrote:

I get this language, on forwarding:

Remote-MTA: dns; gmail-smtp-in.l.google.com [74.125.71.27]
Diagnostic-Code: smtp; 550-5.7.26 Unauthenticated email from intesasanpaolo.com 
is not accepted due to
 550-5.7.26 domain's DMARC policy. Please contact the administrator of
 550-5.7.26 intesasanpaolo.com domain if this was a legitimate mail. 
Please
 550-5.7.26 visit
 550-5.7.26  https://support.google.com/mail/answer/2451690 to learn 
about the
 550 5.7.26 DMARC initiative. 
t16-20020a05600c451000b003fee9453d8csi1042282wmo.59 - gsmtp

MAIL FROM was rewritten so as to pass SPF.  ARC sealing the message
provided no benefit except checking, from the bounce, that the body
hash in AMS matched the one on the original DKIM signature, which had
passed.  The message was legitimate and none of the signed headers,
h=date:from:to:cc:message-id:subject:mime-version:content-type was
altered.  Why should I contact the administrator of the original
sender?


If this message came directly from intesasanpaolo.com (i.e. 
intesasanpaolo.com was sending through tana.it server but not listing it on

their SPF), that's something to the administrator of intesasanpaolo.com
could be interested in.


The bank is sending to a user of mine who asked me to forward messages to her 
gmail account.




The DKIM pass should have been enough, though...



Comparing the bounced message with the original, it turned out the angle 
brackets were removed from the From: address, which is legal since there was no 
display-name, but breaks signatures.  Still no idea how that happened.



Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Authentication Bounces by Gmail

[Alessandro Vesely via mailop]

On Wed 13/Sep/2023 02:14:29 +0200 Jason R Cowart wrote:
We are seeing an increasing number of bounces by Gmail related to failed 
authentication checks.  The bounces include language like:


<<< 550-5.7.26 This mail is unauthenticated, which poses a security risk to the
<<< 550-5.7.26 sender and Gmail users, and has been blocked. The sender must
<<< 550-5.7.26 authenticate with at least one of SPF or DKIM. For this message,
<<< 550-5.7.26 DKIM checks did not pass and SPF check for [mcn.org] did not pass
<<< 550-5.7.26 with ip: [67.231.157.125]. The sender should visit
<<< 550-5.7.26 https://support.google.com/mail/answer/81126#authentication for
<<< 550 5.7.26 instructions on setting up authentication. 
z6-20020a05622a028600b00403a8e58423si1377805qtw.448 - gsmtp
[...]

Is anyone else experiencing this?



I get this language, on forwarding:

Remote-MTA: dns; gmail-smtp-in.l.google.com [74.125.71.27]
Diagnostic-Code: smtp; 550-5.7.26 Unauthenticated email from intesasanpaolo.com 
is not accepted due to
550-5.7.26 domain's DMARC policy. Please contact the administrator of
550-5.7.26 intesasanpaolo.com domain if this was a legitimate mail. 
Please
550-5.7.26 visit
550-5.7.26  https://support.google.com/mail/answer/2451690 to learn 
about the
550 5.7.26 DMARC initiative. 
t16-20020a05600c451000b003fee9453d8csi1042282wmo.59 - gsmtp

MAIL FROM was rewritten so as to pass SPF.  ARC sealing the message provided no 
benefit except checking, from the bounce, that the body hash in AMS matched the 
one on the original DKIM signature, which had passed.  The message was 
legitimate and none of the signed headers, 
h=date:from:to:cc:message-id:subject:mime-version:content-type was altered.  
Why should I contact the administrator of the original sender?

Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Authentication Bounces by Gmail

[Alessandro Vesely via mailop]

On Wed 13/Sep/2023 16:34:46 +0200 Grant Taylor via mailop wrote:

On 9/13/23 6:04 AM, Jaroslaw Rafa via mailop wrote:

So allow your user to specify a list of IP addresses of servers from where 
the mail is forwarded.


I don't buy it.

Even if people did know the IP address of their (former) forwarding inbox 
provider server(s) at one point in time, things change.  Often this change is 
unbeknownst to the end users.  Maybe it's simply a change within the providers 
network.  Maybe the provider outsourced to a 3rd party.  Maybe the provider 
insourced from a 3rd party.  Maintaining this list is going to be untenable for 
most end users.



It is not the end user who maintains the list.  It is an agreement between the 
forwarder and the final receiver.  The forwarder has to maintain a dot-forward 
(or its equivalent setting) with the domain name of the final receiver anyway.


For a protocol idea, receivers can publish a standard web form where they 
accept forwarding agreement applications by forwarders.  Keep the agreement 
confined within the receiver's mailbox which confirmed it, to avoid gaming.



Best
Ale
--







___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Legit-looking mail to the wrong address with no unsubscribe

[Alessandro Vesely via mailop]

On Fri 25/Aug/2023 23:12:56 +0200 postfix wrote:
users either underuse, or overconsume.  In both cases they are paying more than 
what a market without subscription would do.



Aha, so that's why they tend to give the wrong address...

For comparison, the delivery address is wrong in rare cases, which are solved 
quickly.



Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Legit-looking mail to the wrong address with no unsubscribe

[Alessandro Vesely via mailop]

On Fri 25/Aug/2023 17:36:06 +0200 Chris Adams via mailop wrote:

Once upon a time, Jaroslaw Rafa  said:

Dnia 25.08.2023 o godz. 09:48:35 Chris Adams via mailop pisze:


So even for transactional messages, there's usually an account making 
the purchase, or something is being delivered to an address, or the 
like.  So a "this is not me" link should be able to note that (a) don't 
send more mail about the current transaction to this address and (b) 
don't send any mail for future transactions with the same delivery to 
the same address without further input.  Future orders that would have 
transactional emails blocked should pop up and say "hey, this address is 
flagged as NOT YOU, are you sure?".


This does not solve the problem of one-time purchases WITHOUT an account 
(actually may be multiple "one-time" purchases, but without registering an 
account at the shop and logging in).


"or something is being delivered to an address"

One of the things that prompted me to send the initial message here is 
DoorDash delivering food to the same person.  In that case, it appears 
they made an account, but even if they didn't, it's probably going to 
the same place.  So "delivery address+email" is a unique identifier.



If you have an unsub button —which some suggest be /always/ set in automated 
mails— you should store unsubbed addresses whether they have an account or not. 
 So Chris' solution is good for all cases.  Re-entering an unsubbed address 
should trigger extra checks, COI or whatever.



Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [STATE of the UNION] Tails from the trenches of the spam auditing team..

[Alessandro Vesely via mailop]

On Thu 24/Aug/2023 17:42:21 +0200 John Levine via mailop wrote:

It appears that Slavko via mailop  said:

In all the years I've been running mail systems (which to my great astonishment 
is now greater than 25!) I've used a variety of netblock sizes and occasionally 
entire AS numbers in outright blocks.


IIRC, Jaroslaw have bad neighbors...


Well, yeah, sometimes you get what you pay for.



Hm... finding an expensive ISP is not a good business criterion.  List 
information is often based on stale and arbitrary information, such as the PBL.


In addition, public DNSBL have that nasty habit of requiring the ISP —not the 
postmaster— to request delisting, which they won't do.  SWIP is long time dead. 
 Strange setup, in an epoch where anybody can get certbot certificates just 
like that, there's no accepted way to say this IP is mine.



Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DKIM AUID and subdomains

[Alessandro Vesely via mailop]

On Sun 20/Aug/2023 12:35:20 +0200 Slavko via mailop wrote:


i recently start to sign subdomain's (no bulk, nor mass, nor advertising,
etc) mails by parent (main) domain key, mostly to simplify DNS setup,
thus mails looks eg.:

 DKIM-Signature: ... d=example.org

 From: 

That works and AFAIK it is permitted/mentioned in RFC and IMO
have to work with DMARC's relaxed alignment.



Are you actually moving email addresses to a subdomain?



Now i think about DKIM identity (i=) tag in signature. I search across
Internet and i found very little (near to zero) info if it is useful. I even
found DKIM ML thread (~10 years old), where it was suggested
to remove it from RFC at all (which doesn't happen).



It is also possible to set:

  DKIM-Signature: ... d=sub.example.org

Here you just have to add a key.  I think reputation is gathered against the 
whole (sub)domain name.  This should result in segmented user reputation, 
perhaps according to the frequency their accounts get compromised...



Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] ANY OVH Contact?

[Alessandro Vesely via mailop]

On Wed 09/Aug/2023 18:36:46 +0200 Michael Peddemors via mailop wrote:

On 2023-08-09 08:55, Mark Alley via mailop wrote:


On 8/9/2023 3:31 AM, Jaroslaw Rafa via mailop wrote:

Dnia  9.08.2023 o godz. 11:00:12 Otto J. Makela via mailop pisze:

Unless the situation has dramatically changed in the last year,
OVH has no functioning abuse team. I block a majority of their nets
from sending email, don't seem to getting any false positives.

Luckily you don't block the net where my server is located, otherwise you
would get a false positive, if I would send mail to you...


Even by merely glancing at one of those subnets 15.204.0.0/17, I see a 
relatively sizable mail filter, Vadesecure, hosting their MTAs there.


- Mark Alley

Hope they have their IP ranges SWIP'ed by OVH, or at least 'rwhois'



Nope, I find ab...@ovh.us at the relevant RDAP page:
https://rdap.arin.net/registry/ip/15.204.0.0

SWIP seems to me to be dead, any contradiction?


Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Antivirus/anti-phish email scanning

[Alessandro Vesely via mailop]

On Mon 31/Jul/2023 15:34:39 + Mailop wrote:

Use AV products by all means, but don't assume they will catch everything.
Do have plans for if/when you find something; both before and after it
causes harm.



Training users would seem to be a promising activity.  There are lots of 
offers in this area as well.  Any recommendations?


TIA
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Guide for setting up a mail server ?

[Alessandro Vesely via mailop]

On Mon 10/Jul/2023 11:25:04 +0200 Carsten Schiefner via mailop wrote:

Home - maddy
https://maddy.email/



Courier-MTA is another all-in-one package.
https://www.courier-mta.org/


They both have a long list of configuration tasks.  I don't think one can work out a 
guide from comparing them, but it might be interesting to look at (If your mail 
reader won't rewrap)"

MAddy   Courier-MTA

Getting a serverUpgrading an 
existing installation
Installing maddyOverview
System configuration (systemd-based distribution)   Preparing for 
installation
Host name + domain  OPTIONAL: 
Install the Socks 5 client toolkit
TLS certificatesRun configure
First run   IPv6
DNS records Compile and run 
make check
MTA-STS and DANEInstallation
User accounts and maddy command Install 
configuration files
Building from sourceAdjust system 
paranoia level
Forward messages to a remote MX 
Post-installation setup
Using PAM authentication
Post-installation checks
OPTIONAL: 
Configure webadmin
Release builds  Create system 
aliases
Multiple domains configuration  Create smtp 
access list
Upgrading from older maddy versions Backscatter 
suppression
Outbound delivery security  Miscellaneous 
configuration
Docker  Define local 
domains
Reference manualOPTIONAL: 
Configure UUCP
OPTIONAL: 
Configure LDAP aliasing
Modules introductionOPTIONAL: 
Enable standard mail filters
Global configuration directives OPTIONAL: 
Configure custom mail filtering
TLS configuration   Create a list 
of domains to accept mail for
Automatic certificate management via ACME   Starting and 
stopping the Courier mail server
Endpoints configuration Run the Courier 
mail server in parallel to your mail server
IMAP4rev1 endpoint  OPTIONAL: 
Configure ESMTP authentication and SSL
SMTP/LMTP/Submission endpoint   OPTIONAL: 
Configure ESMTP smarthosting
OpenMetrics/Prometheus telemetryOPTIONAL: 
Configure the SECURITY ESMTP extension
IMAP storageOPTIONAL: 
Configure the Sender Policy Framework
IMAP filtersOPTIONAL: 
Configure the IMAP server
SQL-indexed storage OPTIONAL: 
Configure IMAP shared folders
Blob storageOPTIONAL: 
Configure IMAP over SSL
Filesystem  OPTIONAL: 
Certificate Authentication
Amazon S3   OPTIONAL: 
Sending mail via an IMAP connection
SMTP message routing (pipeline) OPTIONAL: 
Configure IMAP realtime folder status updates
SMTP targetsOPTIONAL: 
Configure SMAP
Local queue OPTIONAL: 
Configure the POP3 server
Remote MX delivery  OPTIONAL: 
Configure POP3 over SSL
SMTP & LMTP transparent forwarding  OPTIONAL: 
Configure the IMAP/POP3 aggregator proxy
SMTP checks OPTIONAL: 
Configure the webmail server
Check actions   OPTIONAL: 
Configure webmail calendaring
DKIMOPTIONAL: 
Configure mail filtering for the webmail server
SPF OPTIONAL: 
Changing mail account passwords using the webmail server
Milter client   OPTIONAL: 
Configure autoreplies for the webmail server
rspamd  OPTIONAL: 
Configure encryption for the webmail server
DNSBL lo

Re: [mailop] SPF +all considered harmful

[Alessandro Vesely via mailop]

On Sat 08/Jul/2023 11:47:41 +0200 Sebastian Nielsen via mailop wrote:
I would say +all is always harmful. The difference between having +all and not 
having any at all (or ?all) is that you affirmately, by using +all, tell the 
system the email is genuine. If you somehow want to treat all emails as 
“unspecified” or “unknown”, ergo don’t want to reject, but you want to still 
have a SPF so you don’t get sent to spam folder for not having a SPF, you can 
use ?all to force a “neither genuine or fake” result that should be treated as 
no SPF at all in the actual validation system.



You need +all if you're after dmarc=pass.


If you as a webshop would put +all on a SPF, and I got a email, that was 
stamped as genuine in my email client, and I enter my card number on a website 
that was linked in said email to correct an order, I would held you accountable 
for every loss of money on that credit card, since you certified the email as 
genuine, and affirmately told me (or my computer system), by publishing a +all 
SPF, that I should trust that email to 100%.



Did any reimbursement claim ever succeed?


+all in SPF, ergo a harmful action, may however have its usage in certain 
situations, for example development or testing or SPF validation systems or 
similar.



It is used in alumni and similar sites.  E.g. member.fsf.org.


Best
Ale
--






___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mimecast Adimin Probation Block - 74.203.49.59

[Alessandro Vesely via mailop]

On Thu 29/Jun/2023 04:46:35 +0200 Sebastian Nielsen via mailop wrote:
See RFC 8058 on doing one-click unsubs in a way unlikely to be mistriggered.  


Its a good idea, but don't count on all MUAs implementing this function, so 
best here is to have both, if request arrives from the RFC 8058 header, treat 
it as secure enough to warrant one-click, but if it arrives through the 
unsubscribe link in the email itself, require an extra click on button.



It can well be the same form.  In PHP:

   if (isset($_POST["List-Unsubscribe"]) &&
   $_POST["List-Unsubscribe"] == "One-Click")
   {
   // do the unsubscribe
   if ($ok)
   {
   http_response_code(202);
   return $address ." successfully unsubscribed";
   }

   http_response_code(500);
   return $bad;
   }
   http_response_code(200);
   return '
   Manual unsubscribe
   Enter "One-Click",
   see https://www.rfc-editor.org/rfc/rfc8058";>RFC 
8058
   
   ';


Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Cannot talk to Sharedband

[Alessandro Vesely via mailop]

On Sat 24/Jun/2023 16:41:25 +0200 Bill Cole via mailop wrote:

On 2023-06-24 at 05:49:30 UTC-0400 (Sat, 24 Jun 2023 11:49:30 +0200)
Alessandro Vesely via mailop 
is rumored to have said:


I had a bounce:

Reporting-MTA: dns;PR3PR05MB7547.eurprd05.prod.outlook.com
Received-From-MTA: dns;wmail.tana.it
Arrival-Date: Sat, 24 Jun 2023 03:03:07 +

Original-Recipient: rfc822;redac...@sharedband.com
Final-Recipient: rfc822;redac...@sharedband.com
Action: failed
Status: 5.7.520
Diagnostic-Code: smtp;550 5.7.520 Access denied, Your organization does not 
allow external forwarding. Please contact your administrator for further 
assistance. AS(7555)



I'm using 94.198.96.72/29 since April, and I'm trying to remove IP blocks as 
I find them.


That's not clearly an IP-based block. It looks like that is a consequence of 
tana.it having -all in its SPF record. That is explicitly a prohibition on 
forwarding, whether the SPF specs say so or not. It is certainly comprehensible 
that a mail system which does a lot of forwarding does not want to handle your 
unforwardable mail.



Their mentioning AS7555 made me think about a routing problem.

SPF -all bounces usually say "Address does not pass the Sender Policy Framework"


Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Cannot talk to Sharedband

[Alessandro Vesely via mailop]

I had a bounce:

Reporting-MTA: dns;PR3PR05MB7547.eurprd05.prod.outlook.com
Received-From-MTA: dns;wmail.tana.it
Arrival-Date: Sat, 24 Jun 2023 03:03:07 +

Original-Recipient: rfc822;redac...@sharedband.com
Final-Recipient: rfc822;redac...@sharedband.com
Action: failed
Status: 5.7.520
Diagnostic-Code: smtp;550 5.7.520 Access denied, Your organization does not 
allow external forwarding. Please contact your administrator for further 
assistance. AS(7555)


I'm using 94.198.96.72/29 since April, and I'm trying to remove IP blocks as I 
find them.  Since they block my server, I wrote them from Gmail.  Surprise:


Reporting-MTA: dns; googlemail.com
Arrival-Date: Sat, 24 Jun 2023 02:35:23 -0700 (PDT)
X-Original-Message-ID: 


Final-Recipient: rfc822; postmas...@sharedband.com
Action: failed
Status: 5.4.1
Remote-MTA: dns; sharedband-com.mail.protection.outlook.com. (104.47.2.36, the
 server for the domain sharedband.com.)
Diagnostic-Code: smtp; 550 5.4.1 Recipient address rejected: Access denied. 
AS(201806281) [DB5EUR01FT100.eop-EUR01.prod.protection.outlook.com 
2023-06-24T09:36:26.242Z 08DB746591C0DBB7]
Last-Attempt-Date: Sat, 24 Jun 2023 02:36:26 -0700 (PDT)


How was that joke about TBTB?


Best
Ale
--







___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DMARC and subdomains

[Alessandro Vesely via mailop]

On Fri 16/Jun/2023 22:41:39 +0200 Gellner, Oliver via mailop wrote:

On 16.06.2023 at 16:13 Jaroslaw Rafa via mailop wrote:
[...]
So at least one (and important one, given the size of this mail service) 
implementation of DMARC does not use the PSL.


eu.org is located in the private domain section of Mozillas public suffix list. 
Apparently Google does not treat those private domains as public suffixes (at 
least not all of them) or uses a different public suffix list. The DMARC 
specification does not mandate that you have to use Mozillas PSL and pick up 
every self-appointed entry from there.



FWIW, future development provides for walking down the DNS tree.  So a DMARC 
verifier would lookup _domainkey.foo.bar.example.com and 
_domainkey.bar.example.com before reaching _domainkey.example.com.

Eu.org would have to publish a "psd=y" tag to say it is a public suffix domain. 
 Psd domains can specify policies.

Their current record specifies a pct=, which won't be supported by the upcoming 
standard.

"v=DMARC1;p=none;sp=none;pct=10;rua=mailto:dmarc-mas...@eu.org;ruf=mailto:dmarc-mas...@eu.org";


Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SPF: Does include: a host without TXT entry invalidate the whole SPF entry?

[Alessandro Vesely via mailop]

On Fri 09/Jun/2023 19:14:31 +0200 Slavko via mailop wrote:

Dňa 9. júna 2023 16:07:28 UTC používateľ Andrew C Aitchison via mailop 
 napísal:


I asked one of the checker websites about that and recieved the reply:
 RFC6652 is a proposed standard from 2012, but was replaced by DMARC in 2015.
 DMARC reports on both SPF and DKIM.


But that is their point of view, as RFC 6652 doesn't seem to 
be marked as obsolete or so...



Actually, DMARC failure reports (aka forensic reports) include just DMARC data; 
that is, whether it was DKIM or SPF which failed, along with relevant 
identifiers and their alignment.  RFC 7489 adds:


 Note that a failure report generator MAY also
   independently produce an AFRF message for any or all of the
   underlying authentication methods.

IME, few receivers produce failure reports and none of them add the underlying 
stuff.



Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SPF: Does include: a host without TXT entry invalidate the whole SPF entry?

[Alessandro Vesely via mailop]

On Fri 09/Jun/2023 07:37:06 +0200 Benoît Panizzon via mailop wrote:


If you don't care enough to publish a valid SPF record, why should 
we think you care whether we deliver your mail?


The customer in question used an ESP to send marketing emails. 
That ESP told him what host to include in his SPF record.


Probably some years later, that ESP changed domain and that include 
became invalid.



Anyone took care to alert them about that error?

RFC 6652 provides for setting ra= and rr= tags, which are themselves flagged as 
errors by most SPF checking sites...



Best
Ale
--








___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SRS? Was Noticed Google now suggests changing envelope sender for forwarding

[Alessandro Vesely via mailop]

On Fri 02/Jun/2023 02:14:50 +0200 Brandon Long via mailop wrote:

On Thu, Jun 1, 2023 at 11:20 AM Alessandro Vesely via mailop.org wrote:

On Thu 01/Jun/2023 17:45:38 +0200 Robert L Mathews wrote:


So I guess it's time to add SRS rewriting for Gmail addresses...!


The only points I see in SRS are mailbox full or oversize.  [...] But this 
does not happen so frequently any more.  [...] Permanent failures, 5xx, 
are permanent, like cancelled account.  In that case, SRS doesn't do a  
good job.  It is better to remove the forwarding instructions completely, 
no?


I feel like SRS is trying to be something more than just VERP, but the more 
was never really flushed out.


The "more" is validation that you generated the address, so you can ignore 
mail that isn't actually a bounce... perhaps if it starts getting spam or whatever.


The issue is that bounces may occur after days, so you would need to make 
your address usable for days.  And you might get transient bounce messages 
("still trying"), or the next hop may not rewrite and forward to multiple 
addresses...


Also, sometimes the recipient wants everybody to know about the new address and 
possibly take note, but some other times a recipient changed address in order 
to cut some contacts, and wants to keep the new address secret.  Bounce 
handling should differ in such cases.



Anyways, most folks seem to be fine with just a less validated approach, up 
to them.


Gmail's forwarding has always used a VERPs like approach with the +=caf 
semantics, and yes, repeated bounces of certain types can lead to the 
forwarding being disabled... though, there's obviously issues with stopping 
forwarding because customers may never be checking the forwarding account. >
Also, 5xx means permanent failure just for that transaction, not for the 
account ever... though one can try and deduce whether the latter is true.



5xx implies human (or at least out-of-band) intervention.  The question is 
which human, the recipient, the sender or the sysadmin?  Any numbers on the 
frequencies that these occur, anyone?


Behavior is presumably different if there are other means to contact the 
recipient...



Anyways, obviously folks who forward should not respond to the sending 
server until the message has been accepted by the forwarding server, and any 
smtp rejection should be propagated directly to the sender... oh, and spam 
check before even attempting to forward, of course.



Some systems automatically switch to reject after the first delivery failure, 
as an anti-backscatter mechanism.  To do the same with forwarding failures one 
has to remove the dot-forward.  That might be considered parallel to mailing 
lists auto-unsubscribing after a few rejections.



Best
Ale
--








___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] SRS? Was Noticed Google now suggests changing envelope sender for forwarding

[Alessandro Vesely via mailop]

On Thu 01/Jun/2023 17:45:38 +0200 Robert L Mathews wrote:

So I guess it's time to add SRS rewriting for Gmail addresses...!



The only points I see in SRS are mailbox full or oversize.  You ought to notify 
the author that the message got lost.  It is just a temporary feature, though.


But this does not happen so frequently any more.  Disk space went cheaper and 
cheaper, and mailbox limits are not so tight any more.  Permanent failures, 
5xx, are permanent, like cancelled account.  In that case, SRS doesn't do a 
good job.  It is better to remove the forwarding instructions completely, no?



Best
Ale


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Transparency is key... Here is a perfect example.. M3AAWG is coming.. time to take a stance?

[Alessandro Vesely via mailop]

On Wed 31/May/2023 00:13:38 +0200 Michael Peddemors via mailop wrote:

18.156.43.163   (M)   1   guardpost-n08.euc1.mailgun.co
18.157.58.83    (M)   1   guardpost-n07.euc1.mailgun.co
18.157.75.126   (M)   1   guardpost-n01.euc1.mailgun.co
18.158.176.19   (M)   1   guardpost-n02.euc1.mailgun.co
18.197.223.145  (M)   1   guardpost-n05.euc1.mailgun.co

Registrar: NameCheap, Inc.
Registrar IANA ID: 1068
Registrar Abuse Contact Email: ab...@namecheap.com
Registrar Abuse Contact Phone: +1.6613102107
Domain Status: clientTransferProhibited 
https://icann.org/epp#clientTransferProhibited

Registry Registrant ID: REDACTED FOR PRIVACY

whois on the IP?

18.156.0.0/14 AMAZO-ZFRA
Organization:   A100 ROW GmbH (RG-123)



The difference between names and numbers is amazing:

At https://rdap.arin.net/registry/ip/18.156.0.0
among other things you find:

registrant:
A100 ROW GmbH
Marcel-Breuer-Strasse 10\nMunchen\n\n80807\nGermany

abuse:
Amazon EC2 Abuse
ab...@amazonaws.com
+1-206-555-
Abuse of Amazon Web Services
The activity you have detected originates from a dynamic hosting environment.
For fastest response, please submit abuse reports via the AWS webform:
https://repost.aws/knowledge-center/report-aws-abuse
If your company system is configured to automatically send abuse reports, 
please send them to ab...@amazonaws.com including:

* src IP
* dest IP (your IP)
* dest port
* Accurate date/timestamp and timezone of activity
* Intensity/frequency (short log extracts)
* Your contact details (phone and email)

technical:
Amazon EC2 Network Operations
amzn-noc-cont...@amazon.com

noc:
Amazon AWS Network Operations
amzn-noc-cont...@amazon.com
+1-206-555-

administrative:
IP Management
ipmanagem...@amazon.com
+1-703-464-1336


Best
Ale
--













___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] verifier.port25.com

[Alessandro Vesely via mailop]

On Tue 23/May/2023 22:27:22 +0200 Tobias Fiebig via mailop wrote:

On Tue, 2023-05-23 at 13:31 -0500, Blake Hudson via mailop wrote:


Anyone have [...] alternative tools for testing DKIM, SPF, and similar in 
one go?


Lemme throw email-security-scans.org into the list of tools for this.
;-)



Considering just DKIM tests, this one is the only tester which explicitly and 
clearly recognizes ed25519 signatures.  For the rest, EmailAudit reported a 
pass, but then said "DKIM key size is 0 bits.  More senders are starting to use 
2048 bits."



Best
Ale
--






___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Yahoo: SOA record per subdomain required?!

[Alessandro Vesely via mailop]

On Mon 08/May/2023 00:51:47 +0200 Slavko via mailop wrote:

The PSL is something strange, introduced by DMARC which
defines "organizational domain", which seems to be not as
clear as DMARC's authors think.

This PSL is not standardized and is maintained by Mozilla,
which is only as volunteer to do that. Hopefuly they do it in
public way, but one have to consider that list as suggestion
only, it is not used by all and AFAIK some orgs maintain
own lists.



It looks like the PSL won't be used in the "standard" version of DMARC. 
Verifiers would just lookup DMARC records at the From: domain or parents 
thereof.  (There's a new tag to flag the rare exceptions.)  DMARC record 
existence, that way, could the role of SOA+PSL as far as belonging to the same 
organization is the meaning that Y! look for.



Best
Ale
--



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DKIM with 3072-bit or 4096-bit RSA signatures

[Alessandro Vesely via mailop]

On Thu 27/Apr/2023 01:21:14 +0200 Matt Palmer via mailop wrote:

the Wikipedia page
for DKIM even lists "non-repudiability" under the heading "Advantages"
(https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail#Advantages).



Fixed.


Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google cannot verify email authentication any more?

[Alessandro Vesely via mailop]

On Fri 21/Apr/2023 19:47:09 +0200 Brandon Long via mailop wrote:
This smtp response doesn't match this email message.  In any case, both of 
these messages did pass authentication, but we chose the wrong error message to 
send in response to this one (the other was accepted).



Oops, you're right.  I must have picked the wrong one (they do it every day).  
I attach the previous one, in case it serves.

It bounced 5 times.  Times in UTC+2

04:38:49 d9-20020a05640208c900b00504b18d24f8si586620edz.362
04:43:50 gn3-20020a1709070d0300b0094f236b9e37si633963ejc.327
04:48:51 bo3-20020a170906d04300b0094efdfd3730si441968ejb.329
04:48:51 g7-20020a50ee0700b00501e283279fsi513501eds.205
05:18:53 gc37-20020a1709072b2500b0094f9b6a4e1asi419415ejc.908
05:23:54 qo20-20020a170907213400b0094e5b84ddb8si589103ejb.351 Accepted.



I'll file a bug.



Thank you


Best
Ale
--



--- Begin Message ---

Dear Abuse Team

The following abusive behavior from IP address under your constituency
191.36.158.106 has been detected:

2023-04-19 20:16:33 CEST, 191.36.158.106, old decay: 21600, prob: 3.13%, 
SMTP auth dictionary attack, target 94.198.96.74:587

191.36.158.106 was caught 5 times since Mon Mar 27 20:36:17 2023

original data from the mail log:
2023-04-19 20:16:27 CEST courieresmtpd: 
started,ip=[191.36.158.106],port=[51769]
2023-04-19 20:16:33 CEST courieresmtpd: 
error,relay=191.36.158.106,port=51769,msg="535 Authentication failed.",cmd: 
AUTH LOGIN alesp
2023-04-19 20:26:41 CEST courieresmtpd: [191.36.158.106]: Connection timed 
out


This data is transmitted in the hope that it may help sanitizing hosts
connected to the Internet.  Please feel free to forward it to whomever
it may concern.
This is an automated report.  No thank-you messages are needed.
Data in this message is an automatic extraction from the log files.
Legend: https://www.tana.it/firewall_info.html

See also: https://www.abuseipdb.com/check/191.36.158.106
Recipient(s) found in https://rdap.lacnic.net/rdap/ip/191.36.158.106
--- End Message ---
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Google cannot verify email authentication any more?

[Alessandro Vesely via mailop]

This morning I found this:

421-4.7.0 This mail is unauthenticated, which poses a security risk to the
421-4.7.0 sender and Gmail users, and has been blocked. The sender must
421-4.7.0 authenticate with at least one of SPF or DKIM. For this message, DKIM
421-4.7.0 checks did not pass and SPF check for [tana.it] did not pass with ip:
421-4.7.0 [94.198.96.74]. The sender should visit
421-4.7.0 https://support.google.com/mail/answer/81126#authentication for
421 4.7.0 instructions on setting up authentication. 
d9-20020a05640208c900b00504b18d24f8si586620edz.362 - gsmtp

I changed SPF recently (after changing ISP), while DKIM signing remained the 
same.  I attach the message.

Best
Ale
--
--- Begin Message ---

Dear Abuse Team

The following abusive behavior from IP address under your constituency
191.36.158.106 has been detected:

2023-04-21 04:19:25 CEST, 191.36.158.106, old decay: 21600, prob: 3.13%, 
SMTP auth dictionary attack, target 192.168.1.254:465

191.36.158.106 was caught 6 times since Mon Mar 27 20:36:17 2023

original data from the mail log:
2023-04-21 04:19:21 CEST courieresmtpd: 
started,ip=[191.36.158.106],port=[43433]
2023-04-21 04:19:25 CEST courieresmtpd: 
error,relay=191.36.158.106,port=43433,msg="535 Authentication failed.",cmd: 
AUTH PLAIN abuse


This data is transmitted in the hope that it may help sanitizing hosts
connected to the Internet.  Please feel free to forward it to whomever
it may concern.
This is an automated report.  No thank-you messages are needed.
Data in this message is an automatic extraction from the log files.
Legend: https://www.tana.it/firewall_info.html

See also: https://www.abuseipdb.com/check/191.36.158.106
Recipient(s) found in https://rdap.lacnic.net/rdap/ip/191.36.158.106
--- End Message ---
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] NS DKIM

[Alessandro Vesely via mailop]

On Mon 27/Mar/2023 19:38:14 +0200 Slavko via mailop wrote:

Dňa 27. marca 2023 17:06:55 UTC používateľ Alessandro Vesely via mailop 
 napísal:

On Mon 27/Mar/2023 18:25:24 +0200 Brad Beyenhof via mailop wrote:

On 3/27/23, 9:18 AM, "mailop on behalf of Heiko Schlittermann via mailop" 
mailto:mailop-boun...@mailop.org> on behalf of mailop@mailop.org 
<mailto:mailop@mailop.org>> wrote:

Lena--- via mailop mailto:mailop@mailop.org>> (Mo 27 Mär 
2023 17:40:29 CEST):

If the DNS name xxx._domainkey.example.com exists, then
_domainkey.example.com exists too.


dig 3._domainkey.lena.kiev.ua txt
3._domainkey.lena.kiev.ua. 66633 IN TXT "v=DKIM1; p=MIGfMA0GCSqGSIb...

dig _domainkey.lena.kiev.ua txt
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 57410


Reading https://www.rfc-editor.org/rfc/rfc8020#section-3.1 
<https://www.rfc-editor.org/rfc/rfc8020#section-3.1>
this should not happen, shouldn't it?


It's possible that `3._domainkey` is a dotted record in the DNS zone for 
`lena.kiev.ua`, and `_domainkey.lena.kiev.ua` isn't set up as its own zone.


Isn't that the usual way to do it?  I certainly didn't create a new zone for 
_domainkey.  Yet, I have (using bind):


Yes, that is as empty non terminals appears.

AFAIK zone is something what has own SOA, and once 
something has SOA (or any other record) it is not empty 
anymore ;-)



It'd be easier if SOA records always returned the name of the zone...

If you query for SOA records, you know you queried the zone name when you get 
it in the answer section rather than the authority section.  (Or use +trace).



Best
Ale
--






___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] NS DKIM

[Alessandro Vesely via mailop]

On Mon 27/Mar/2023 18:25:24 +0200 Brad Beyenhof via mailop wrote:

On 3/27/23, 9:18 AM, "mailop on behalf of Heiko Schlittermann via mailop" 
mailto:mailop-boun...@mailop.org> on behalf of mailop@mailop.org 
> wrote:

Lena--- via mailop mailto:mailop@mailop.org>> (Mo 27 Mär 
2023 17:40:29 CEST):

If the DNS name xxx._domainkey.example.com exists, then
_domainkey.example.com exists too.


dig 3._domainkey.lena.kiev.ua txt
3._domainkey.lena.kiev.ua. 66633 IN TXT "v=DKIM1; p=MIGfMA0GCSqGSIb...

dig _domainkey.lena.kiev.ua txt
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 57410


Reading https://www.rfc-editor.org/rfc/rfc8020#section-3.1 

this should not happen, shouldn't it?


It's possible that `3._domainkey` is a dotted record in the DNS zone for 
`lena.kiev.ua`, and `_domainkey.lena.kiev.ua` isn't set up as its own zone.



Isn't that the usual way to do it?  I certainly didn't create a new zone for 
_domainkey.  Yet, I have (using bind):


; <<>> DiG 9.16.37-Debian <<>> _domainkey.tana.it any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18450
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1


Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mailing Lists and domains with DMARC reject

[Alessandro Vesely via mailop]

On Thu 09/Mar/2023 19:21:36 +0100 John R Levine via mailop wrote:
Yes, the idea was to prevent malicious unsubs by sending fake spam with 
someone else's one-click unsub.


Would a MUA send a POST to a known domain if it was found on a message coming 
from an unknown, or anyway different domain?


Maybe.  It's quite common for a message to come from some company and the links 
to point back to the ESP.



Isn't it difficult to agree on opaque tokens in that case?


Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mailing Lists and domains with DMARC reject

[Alessandro Vesely via mailop]

On Wed 08/Mar/2023 18:39:37 +0100 John R Levine via mailop wrote:


And why does RFC8058 require that fields such as List-Unsubscribe-Post: 
MUST be signed?


Is it special "One click" case? I was not interested in it yet...


Yes, the idea was to prevent malicious unsubs by sending fake spam with someone 
else's one-click unsub.



Would a MUA send a POST to a known domain if it was found on a message coming 
from an unknown, or anyway different domain?


It may be that in the tradeoff between resilience and security the latter wins. 
 In that case shouldn't RFC8058 have modified Section 5.4.1 of RFC6376, 
Recommended Signature Content?


Should software that defines the default fields to sign after that section add 
List-Unsubscribe-Post to that list?



Best
Ale
--






___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mailing Lists and domains with DMARC reject

[Alessandro Vesely via mailop]

On Wed 08/Mar/2023 22:27:57 +0100 Ángel via mailop wrote:

On 2023-03-08 at 11:24 +0100, Alessandro Vesely wrote:

On Tue 07/Mar/2023 20:02:48 +0100 Slavko wrote:


Why do you sign Content-Type: since you know it is going to be 
changed?


Do you mean exactly me, or it was generic question? If you mean me:

Do you want change the text/plain message, eg. to multipart/alternative 
with text/html appended? Of course, in my case that change will invalidate 
body signature too (as i sign whole body), but anyway, it constructs core 
of message, thus (IMO) fulfill RFC.


Yes, I meant you, since you (are among the ones who) do it.

The change to multipart can only happen using the deprecated l=.  It allows to 
completely replace the body appearance.  As you don't use l=, the only added 
protection is against an improbable collision between the original bh= and the 
hash of the modified body.


There are more ways to change a Content-type for abuse.

Suppose there is a web form that is expected to send a plain text message 
saying:

"Hello Alessandro

Thanks for registering on example.com, please click the following link to validate 
your account: https://example.com/register...";


These kind of forms are already abused by using "names" such as "buy our viagra 
at great price on http://spamurl.com";



URLs don't depend on Content-Type:, do they?


The "I received a scam letter from Paypal" thread a few months ago is also based 
on the same concept.



That turned out to be authentic, IIRC.


Now, let's suppose that email is DKIM-signed but the Content-type: text/plain header 
is not. And the form is filled out by «Bobby * { color: white; background-color: 
white; } .phish * { color: black}Important notification from your bank 
Your password has expired. Please https://phishing.com";>Renew it here»


and attacker changes the Content-type from text/plain to text/html...



Is that content going to replace «Alessandro» in the plain/text message from 
the generated message?  The culprit seems to be rather the input sanitizing 
than the signing.




Another venue would be changing the charset to utf-7 This was a common
way of bypassing XSS filters on browsers. It is now unsupported by all
browsers, and forbidden by the spec [1]. I don't know if there is any
MUA which allows that (or even used to support it)



That requires the original text to already contain the exploit.  Perhaps the 
plain text message was exemplifying it?




Determining which headers to sign (or not to sign) is complex, brittle
and reasons for that unintuitive and not well-known. A reference
document that provided guidance (if not even a direct recipe) would
surely be helpful to the email community.



I agree that some kind of transactional messages can bear paranoid signatures. 
They also deserve p=reject.


Ordinary messages, which can expect to be forwarded or slightly modified could 
keep a lower profile, couldn't they?


I understand that the only advantage of signing lightly is for the very few 
people who can recover that kind of signatures after MLM transformation, so it 
seems to be a lost argument...




1-
https://html.spec.whatwg.org/multipage/parsing.html#character-encodings



I hope Javascript in email messages does not run...


Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop