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

It appears that Tobias Fiebig via mailop said: >Moin, >> In this case, if DKIM validators correctly rejected the invalid >> signatures, this mistake would have been caught and fixed more >> quickly. >So, back to the initial question: Would it make sense if i'd file a bug >against rspamd? Sure.

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

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

Re: [mailop] Debugging fwd issue meta.com to zoho.com

It appears that Slavko via mailop said: >Do you want to tell, that if d= and/or s= tags contains >internationalized domain name/label, it must be in A-label (ASCII >encoded) form? Or how it is supposed to be handled please? See RFC 8616. That is precisely what it is about. R's, John

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

According to Tobias Fiebig via mailop : >Moin, > >to share some closure on this with the rest of the list; What was >ultimately the issue was an RFC8616 based DKIM-Signature header, i.e., >containing UTF-8 encoded fields (in this case, even though there were >no non-ascii characters in them). ...

Re: [mailop] How to ensure ownership from a Microsoft email?

It appears that Cyril - ImprovMX via mailop said: >Now, I wonder. Can I trust Microsoft that if they send an email on behalf of >aotearoa.energy, they initially >validated the ownership or is there a way to bypass that? tl;dr It's self service with, as far as I can tell, no validation at all.

Re: 600,000 routers bricked

It appears that Robert Jacobs said: >-=-=-=-=-=- > >If you do a bit more digging the ISP is not Lumen ... It is a well known ISP It's Windstream. and I recall reading about this >outage when it happened. I don’t know if indeed this was a botched attempt to >gather a bot network or like >some

Re: DKIM length 'l=' tag

It appears that Bill Cole said: >Never has been safe. Terrible idea from the start. Never should have >been included in the specification. Agreed. >I was thinking of the same thing in a half-assed way, just catching >anything using the length tag. I'd bet that correlates to spam but we'd

[dmarc-ietf] Re: The null sender inconsistency

It appears that Richard Clayton said: >This is not a question of validation, DMARC is all about alignment > >You will need to say EHLO with a domain name that aligns with the From: >if you cannot manage that then DKIM is your only way to get your bounce >message to have a DMARC pass Now that I

Re: Correcting national address databases?

Box. You should move to New York. My NY license has always had my PO Box and no other address. I do have a street address, and the PO does deliver there, but it's not on my license. -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly

[Ietf-dkim] Re: Manipulation of signed messages

It appears that Alessandro Vesely said: >My verifier, in particular, works every time on my messages. It doesn't mean >it doesn't work at scale. Nor, of course, does it mean that it does. Could you give us a list of the list managers that you've tried it with? I presume you've done Mailman 2

[Ietf-dkim] Re: DKIM with body length

It appears that Alessandro Vesely said: >I did try and use it. You have to be careful to put the subject tag on new >messages or write /Re:/ in the right place. You must not sign MIME-Version: >and other fields that the MLM writes anew (yes, also Content-Type:). Oh, and >never send

Re: [dns-operations] DNSbomb attack

It appears that Ond� ej Surý said: >I don’t know why are you trying to create rift where there’s really none. I suspect that I am not the only person who is getting a wee bit tired of papers that say OMG MOST AWFUL DNS FLAW EVER! INTERNET WILL COLLAPSE! MUST CHANGE ALL RFCS! and the authors send

[Ietf-dkim] Re: DKIM with body length

It appears that Jon Callas said: >And look at it -- l= is intended to increase robustness and strictness of >interpreting the message. I don't see how that followes. In all the years I've been futzing with email I can't ever think of a time where a message showed up with added crud at the end

[Ietf-dkim] Re: DKIM with body length

It appears that Murray S. Kucherawy said: >I've read the middle part a few times and I don't understand either the >attack or the proposed mitigation, so I think some examples might help. The attack requires l= and an unsigned Content-Type header. If Content-Type isn't signed, the bad guy can

Re: [mailop] Yahoo no longer accepting email forwards?

It appears that Mark E. Jeftovic via mailop said: >The only difference between messages that get through vs ones that are >rejected (same message) is whether we send to the Yahoo email box >directly, or else via an email forward (which has SRS enabled, and >optionally SPF and even minimal

Re: [mailop] TLS inbound to comcast.net

It appears that Benny Pedersen via mailop said: >Suresh Ramasubramanian via mailop skrev den 2024-05-21 15:18: >> Yeah Benny – if you’re running 16 year old code and certificates >> that you’re still on TLS v1 or 1.1, it is time to upgrade, asap. >> What you have is not much better or worse than

[Ietf-dkim] Re: DKIM with body length

It appears that Wei Chuang said: >-=-=-=-=-=- > >Hi DKIM folks, >As many of you know there was a DKIM security vulnerability disclosure >Friday around the signature header body length tag "l=". It looks like the l= senders are largely one ESP who said today they have stopped doing it, and

[Ietf-dkim] Re: DKIM with body length

It appears that Alessandro Vesely said: >On Mon 20/May/2024 20:10:44 +0200 John Levine wrote: >> It appears that Jeremy Harris said: >>>On 20/05/2024 09:06, Alessandro Vesely wrote: >>>> Content-Type: is a technical field >>> >>>Not a ter

[Ietf-dkim] Re: DKIM with body length

It appears that Murray S. Kucherawy said: >(a) Inertia will mean "l=" is generated and/or accepted for a long time to >come no matter what we say or do; and Yup. >(b) Even if (a) weren't true, "l=" then becomes an unrecognized tag at >verifiers, which will mean those signatures break and we

[Ietf-dkim] Re: DKIM with body length

It appears that Wei Chuang said: >-=-=-=-=-=- > >Hi DKIM folks, >As many of you know there was a DKIM security vulnerability disclosure >Friday around the signature header body length tag "l=". The blog post is >here: https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/ >The authors

[Ietf-dkim] Re: DKIM with body length

It appears that Jeremy Harris said: >On 20/05/2024 09:06, Alessandro Vesely wrote: >> Content-Type: is a technical field > >Not a term I've met before. Is there a formal definition? As Dave said, no. There isn't even an informal definition. >And as far as "which forwarders need to change"

Re: who runs the root, Cogent-TATA peering dispute?

It appears that Bryan Fields said: >Suppose the community wanted to change this or make a formal policy on root >server hosting requirements. Where would this be done? Could a party submit >a proposal to ICANN via the policy development process? If not where should >the community start this?

[Ietf-dkim] Re: DKIM with body length

It appears that Dave Crocker said: >What I  am suggesting is /first/ getting a substantial base of industry >agreement, through collective action and field practice, and /then/ >codifying it with an update specification. > >The specification through the IETF would then merely document a new

[Ietf-dkim] Re: DKIM with body length

It appears that Steve Atkins said: >> Do people really think that senders that are ignoring Sec. 8.2 of RFC 6376 >> are going to pay attention to a separate RFC >that updates that RFC? > >+1. Senders, no. Honestly, I don't know. Of the trickle of mail I see with l=, most is from the

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

It appears that Bill Cole via mailop said: >Who uses it? In my logs most of the l= tags are l=1 on that libertarian newsletter, and one or two other newsletters. I see that Verisign puts an l= in the mail their employees send with the real message length. Other than that, I'm with you, it is

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

It appears that Slavko via mailop said: >I feel as the problem lies elsewhere. Perhaps just mentioned gigants >fails properly parse the l= tag (or even do not parse it at all) and their >UI shows whole message (or all its parts) as signed, ... That's not how DKIM works, and not how l= works.

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

It appears that Taavi Eomäe via mailop said: >> Every a few months we see a paper / blogpost that passes SPF / DKIM / >> DMARC. So maybe requiring both SPF and DKIM for BIMI would be a good idea. > >Both together might make sending a bit too error-prone. Hardening DKIM >seems more doable. I

Re: Cogent-TATA peering dispute?

It appears that William Herrin said: >I don't understand why Cogent is allowed to operate one of the root >servers. Doesn't ICANN do any kind of technical background check on >companies when letting the contract? You must be new here. There is no contract for running root servers and never has

Re: [mailop] Line too long

It appears that Brandon Long via mailop said: >-=-=-=-=-=- >-=-=-=-=-=- > >RFC 3030 which provides for the BDAT command and BINARYMIME which treats >the message not as text at all >and so I wouldn't expect that that text limit would apply, though the RFC >doesn't discuss any limits. It says that

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

It appears that Taavi Eomäe via mailop said: >-=-=-=-=-=- >-=-=-=-=-=- >Hi! > >As part of coordinated disclosure, I am sharing it here as well. In >short, using the approach described below, attackers can replace the >entire contents of a letter, in a way the letters still pass DKIM’s

Re: [mailop] Does iCloud accept forwards?

It appears that Mark Fletcher via mailop said: >Can you please have your email administrators check your SPF / DKIM >> settings and ensure that mail sent from your domain has valid DMARC >> signatures in accordance with the DMARC policies that you have defined for >> your domain. > >As you can

Re: Should FCC look at SS7 vulnerabilities or BGP vulnerabilities

It appears that Brandon Martin said: >I think the issue with their lack of effectiveness on spam calls is due >to the comparatively small number of players in the PSTN (speaking of >both classic TDM and modern IP voice-carrying and signaling networks) >world allowing lots of regulatory

Re: [mailop] v=spf1 -all SPF treewalk?

It appears that Mark Alley via mailop said: > >This claim stated that (and I'm quoting verbatim here), "/I forced many >ESPs to start failing SPF for any subdomain of a domain that has no >explicit SPF, and fails SPF at the *primary domain level* /(Context >note: when/v=spf1 -all /exists at

Re: Mailing list SPF Failure

It appears that Michael Thomas said: >On 5/16/24 8:11 AM, Peter Potvin via NANOG wrote: >> Appears there’s no SPF record at all now for nanog.org >> , which is not ideal… > >Since probably 99% of the mail from NANOG is through this list, it >hardly matters since SPF will

[dmarc-ietf] Re: PSOs sending mail from their PSD

It appears that Scott Kitterman said: > >>instead, it could say: >> >>Report generators MUST NOT consider ruf= tags in records having >>a "psd=y" tag, unless the domain is the RFC5322.From domain and/ >>or there are specific agreements between the interested parties. No. You can

[dmarc-ietf] Messages from the dmarc list for the week ending Sun May 12 06:00:03 2024

Count| Bytes | Who ++--- 12 ( 100%) | 137391 ( 100%) | Total 2 (16.7%) | 25581 (18.6%) | Mark Alley 2 (16.7%) | 17646 (12.8%) | Dotzero 2 (16.7%) | 11084 ( 8.1%) | John Levine 1 ( 8.3%) | 27325 (19.9%) | Hector Santos 1 ( 8.3

[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

It appears that libor.peltan said: >Hi all, > >On the other hand, couldn't it actually be beneficial if the signalling >zone name is generic enough, and if (in theory on the future) it is >shared with possibly completely different signals, possibly unrelated to >DNSSEC? It doesn't seem very

[dmarc-ietf] Re: New attack leveraging DMARC None

require getting the customer to understand that they're causing the problem and to spend money fixing it, rather than saying "your mail is broken." Good luck with that. Also remember that until DMARC came along, this all worked just fine. R's, John -- Regards, John Levine, jo...@taugh

[dmarc-ietf] Re: New attack leveraging DMARC None

It appears that Scott Kitterman said: >> Addressing this issue - perusing Section 5.5.6, is there anything else >> we could add that would be acceptable language in an Standards track >> document to encourage urgency behind a transitory state of p=none use by >> domain owners? Would that even

Re: [mailop] What is Yahoo TSS09 ?

It appears that Farhad Hedayatifard via mailop said: >I had this happen with a new IP block a couple of weeks ago as well. We're all set. Whenever Yahoo sees mail from a block that's never been announced before they assume that it's probably an abandoned block that's been hijacked so they block

[mailop] What is Yahoo TSS09 ?

I am moving my servers to new IP addresses, which is always fun. The new block is 192.55.226/24 which was allocated in 1989 and has never been live until this week. So here's what AOL says to innocuous messagee from my users. 553 5.7.2 [TSS09] All messages from 192.55.226.66 will be permanently

Re: [mailop] Apple mail admins?

It appears that Mendel Kucharzeck via mailop said: >Hi, > >I would try contacting icloudad...@apple.com Or, of course, you could tell us what domain and what server and quite possibly someone would spot the problem. R's, John

Re: [mailop] [External] Gmail has a thing about dots

It appears that Kevin A. McGrail via mailop said: >Gmail treats dots as non-existent.  These dots aren't in the Gmail address. They're in the return address in the message. >On 5/2/2024 3:02 PM, John Levine via mailop wrote: >> While debugging something else, I've been tr

[mailop] Gmail has a thing about dots

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> But Gmail still doesn't like

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

It appears that Philip Homburg said: >In your letter dated Thu, 2 May 2024 10:27:17 +0200 you wrote: >>I'm not following what breaks based on the wording I suggested, and I'm not su >>re why you keep bringing that up. :-) > >Let's say I sign my zones using some scripts and ldns-signzone. This

Re: [DNSOP] Questions before adopting must-not-sha1

It appears that said: >There are other reasons to deprecate SHA-1 in DNSSEC than mathematical concern >about the use of that particular digest algorithm in the protocol. Problems >with >SHA-1 definitively exist in other places, in protocols that are in much more >widespread use than DNSSEC.

[pfx] Re: long header folding and DKIM fails

It appears that Steffen Nurpmeso via Postfix-users said: W> |I did not want to insult you! > |In mind i had these canon..py snippets > | > | def strip_trailing_whitespace(content): > |return re.sub(b"[\t ]+\r\n", b"\r\n", content) > | > | > | def compress_whitespace(content): > |return

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Apr 28 06:00:04 2024

. Levine 1 ( 8.3%) | 10551 ( 8.7%) | Douglas Foster 1 ( 8.3%) | 10072 ( 8.3%) | Murray S. Kucherawy 1 ( 8.3%) | 5050 ( 4.2%) | RFC Errata System 1 ( 8.3%) | 3163 ( 2.6%) | John Levine 1 ( 8.3%) | 2754 ( 2.3%) | ___ dmarc mailing

Re: [mailop] Problems with invoices.premierinn.de and postmas...@premierinn.de

It appears that Benny Pedersen via mailop said: >John Levine via mailop skrev den 2024-04-25 18:33: >> It appears that Andrew C Aitchison via mailop >> said: >>>> because the return path would not work. >>>> >>>>$ host invoices.premierinn.

Re: [mailop] Problems with invoices.premierinn.de and postmas...@premierinn.de

It appears that Andrew C Aitchison via mailop said: >> because the return path would not work. >> >>$ host invoices.premierinn.de It has an SPF record. What's the problem? >Should someone here not know, RFC 7505 > A "Null MX" No Service Resource Record for Domains That Accept No Mail >is

[pfx] Re: Fun with line endings, was Re: Mail text wrapping

It appears that Viktor Dukhovni via Postfix-users said: >On Wed, Apr 24, 2024 at 01:01:46AM -0000, John Levine via Postfix-users wrote: > >> >I must be interpreting this wrong because it appears postfix is not >> >accepting that. Here is the complete process. A messa

[pfx] Re: Fun with line endings, was Re: Mail text wrapping

work. BTDT. This has nothing to do with MIME or wrapping, by the way. The SMTP spec says that the *only* line ending is \r\n and bare \r or \n is undefined. Postfix strips the \r on the way in and will add the \r on the way out if you let it handle the SMTP sessions. R's, John -- Regards, John Le

Re: Help with removing DNS shinkhole FP from Charter/Spectrum

It appears that William Herrin said: >On Sun, Apr 21, 2024 at 6:21 PM Validin Axon wrote: >> Looking for some help/advice. Spectrum is sinkholing my company's domain, >> validin[.]com, to 127.0.0.54. > >Howdy, > >If you can't reach a technical POC, use the legal one. Your lawyer can >find the

Re: [mailop] Google Mail rejects forwarded email despite `~all` in SPF

It appears that Paul Menzel via mailop said: > The following message to was undeliverable. > The reason for the problem: > 5.3.0 - Other mail system problem 550-'5.7.26 This mail has been >blocked because the sender is unauthenticated.\n5.7.26 Gmail requires >all senders to

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Apr 21 06:00:04 2024

Count| Bytes | Who ++--- 33 ( 100%) | 296336 ( 100%) | Total 9 (27.3%) | 59633 (20.1%) | Scott Kitterman 6 (18.2%) | 36555 (12.3%) | John Levine 5 (15.2%) | 71162 (24.0%) | Todd Herr 4 (12.1%) | 53314 (18.0%) | Douglas Foster 3

Re: [dmarc-ietf] Thoughts on choosing N

It appears that Scott Kitterman said: >> Or I suppose say if there's more than 8 components in the name, just stop >> because no domain actually used for mail is that deep. Take out the skip >> stuff. > >I am not entirely unsympathetic, but I think what we have is reasonable and >based on

Re: [dmarc-ietf] Thoughts on choosing N

It appears that Todd Herr said: >When DMARC was first developed, there was concern about DNS load and >needing to minimize DNS lookups. Operational expertise now shows that this >is no longer cause for concern. > >Short circuiting a tree walk has led to many issues, like a reliance on the >PSL,

Re: [dmarc-ietf] Thoughts on choosing N

It appears that Scott Kitterman said: >>I'm with Scott, pick a number, 5, 8, whatever, and be done with it. >> >Modulo we do need to explain why 8. Related, I think we also need to explain >why the reporting address thing is important for DMARCbis since having an >intermediate level record

Re: [dmarc-ietf] Thoughts on choosing N

It appears that Alessandro Vesely said: >8 is not needed and not justified. A mail site using 8 labels would have >troubles with the RFC 7489 version, which uses the PSL. They'd have to ask >for >PSL upgrades, right? No, they would not. They might ask to have their pseudo-TLDs added to the

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Apr 14 06:00:04 2024

Count| Bytes | Who ++--- 21 ( 100%) | 150727 ( 100%) | Total 9 (42.9%) | 62034 (41.2%) | Neil Anuskiewicz 4 (19.0%) | 19770 (13.1%) | John Levine 2 ( 9.5%) | 21019 (13.9%) | Douglas Foster 2 ( 9.5%) | 12465 ( 8.3%) | Scott Kitterman

Re: [Ietf-dkim] RFC 8463: DNS textual form underspecified

It appears that Steffen Nurpmeso said: > |I realize that RFC 8463 says repeatedly that the base64-encoded > |representation of an ED25519 key is 44 bytes, and that the > |examples go for this. Still there is no wording that the entire > |ASN.1 structure shall be thrown away. Yeah, I should

Re: [DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

It appears that Peter Thomassen said: >The _signal label generically indicates that ns2.foobar.fi likes to signal >something about nohats.ca. Its presence is needed to allow separating the >object from the source without ambiguity. > >We could change _signal to something else, but not to

Anyone got a contact at OpenAI. They have a spider problem.

As I think I have mentioned before, I have the world's lamest content farm at https://www.web.sp.am/. Click on a link or two and you'll get the idea. Unfortunately, GPTBot has found it and has not gotten the idea. It has fetched over 3 million pages today. Before someone tells me to fix my

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-failure-reporting-10.txt

It appears that Neil Anuskiewicz said: >Do you all think we should mention the decline and fall of the failure report? >I think that Yahoo! is the only major MBP that still sends >failure reports. I think the others may have stopped over PII concerns. I still get a dozen a day. They're not

Re: [anti-abuse-wg] Reverse DNS delegations

It appears that Alessandro Vesely said: >On Sat 06/Apr/2024 19:54:27 +0200 Randy Bush wrote: > Why isn't it possible to gain a delegation by proving number > assignment? Because your ISP can't be bothered. >>> Is such unbotherability legitimate? >RIPE could at least reproach those

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Apr 7 06:00:04 2024

Kitterman 7 ( 6.8%) | 62365 ( 6.6%) | Todd Herr 7 ( 6.8%) | 35765 ( 3.8%) | John Levine 5 ( 4.9%) | 75347 ( 8.0%) | Douglas Foster 5 ( 4.9%) | 39532 ( 4.2%) | Jim Fenton 5 ( 4.9%) | 27791 ( 2.9%) | John R. Levine 3 ( 2.9%) | 38637 ( 4.1%) | Tim Wicinski 3 ( 2.9%) | 31423

Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all

It appears that Scott Kitterman said: >I hear you. Your operational issue is my system working as designed. DMARC >works on top of SPF, it doesn't change it. > >Anything like this belongs in an operational guidance document, not in the >protocol description. I have no problem describing

Re: [anti-abuse-wg] Reverse DNS delegations

It appears that Alessandro Vesely said: >Why isn't it possible to gain a delegation by proving number assignment? Because your ISP can't be bothered. I have a free /48 from Hurricane and they delegated the rDNS as part of the setup so it's not like it's unusual or difficult. Delegating IPv6

Re: Microsoft missing public DNS TXT entry for DKIM records (msn.com)

It appears that Adam Brenner via NANOG said: >mail server. Our mail server checks if DKIM email headers are present >and if they are, tries to validate them. If the check fails, we reject >the message. MSN's setup is broken but let me strongly reiterate the advice DON'T DO THAT. If a DKIM

Re: [mailop] Are there other comparable services like spamcop.net / spamhaus.org?

It appears that Aban Dokht via mailop said: >Hi list, > >are there other comparable services like spamcop.net or spamhaus.org worth >submitting SPAM samples to? By the way, how do you think you're submitting stuff to spamhaus? They do not accept third party samples and never have. R's, John

Re: [mailop] Are there other comparable services like spamcop.net / spamhaus.org?

It appears that Niels Dettenbach via mailop said: >Am Mittwoch, 3. April 2024, 10:41:01 CEST schrieb Aban Dokht via mailop: >> Currently we are reporting SPAM samples semi automated to those to services >> and would like to know, if the are other ones worth to contribute so. > >even if they work

Re: [mailop] how does mailhash.josephlist.net work?

It appears that Peter N. M. Hansteen via mailop said: >On Tue, Apr 02, 2024 at 04:09:48PM +0200, Benoit Panizzon via mailop wrote: >> I came across emails rejected by mailhash.josephlist.net >> >> reason: 550 5.7.1 block listed email address s...@example.com by >> mailhash.josephlist.net

Re: [dmarc-ietf] ARC, DMARCbis WGLC - Issue 144 Mention of ARC in DMARCbis

It appears that Murray S. Kucherawy said: >Can you give an example, even if only a hypothetical one? I'm not Emmanuel but people at large mail systems have told me that the biggest value of ARC is to deal with mailing lists that do lousy spam filtering. Lists often let anything through that has

Re: [dmarc-ietf] DMARCbis WGLC - Issue 144 Mention of ARC in DMARCbis

It appears that Todd Herr said: >Issue 144 has been opened for the question of what to say about ARC (RFC >8617) in the context of indirect mail flows, a la Murray's example text >from this post >: > >"One possible

Re: [dns-operations] Offline DNSSEC Validation

and a set of dnskeys and tells you whether the signature is good. If you want to follow the DS chain you'll have to do that yourself but having just written a stunt DNSSEC signing server, I can say that the code to do the chaining would not be hard. R's, John -- Regards, John Levine, jo...@taugh.com

Re: [dmarc-ietf] WGLC contentious topics (I'm in the rough and I know it) in draft-ietf-dmarc-dmarcbis-30

It appears that Seth Blank said: >More accurate language that alleviates the concern would be "It is >therefore critical that domains that host users who wish for their messages >to be modified and spoofed by downstream intermediaries, such as alumni >forwarders or mailing lists, SHOULD NOT

Re: [dmarc-ietf] SPF follies, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

It appears that Tim Wicinski said: >-=-=-=-=-=- > >I have to agree with Seth's comments that "security teams believe an SPF >hard fail is more secure". >I've been on the receiving end of that discussion more than once. I believe you, but if you reject on SPF fail you're going to lose a lot of

Re: [mailop] Anyone from Google - Sudden Gmail bounces??

It appears that Odhiambo Washington via mailop said: >> checkrbl 41.212.32.15 >> Found in "Spamhaus ZEN DQS" (zen.dq.spamhaus.net): >> * PBL, end user (from Spamhaus) (127.0.0.11) >> >> checkrbl 41.212.32.16 >> Found in "Spamhaus ZEN DQS" (zen.dq.spamhaus.net): >> * PBL, end user (from

Re: [dmarc-ietf] SPF follies, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

It appears that Mark Alley said: >>   People who publish -all know what they do. > >I posit that there is a non-insignificant amount of domain owners that >don't know what the consequences of -all are other than that they've >been instructed to use "-all" by a guide online, ... I'm with you.

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Mar 31 06:00:04 2024

Count| Bytes | Who ++--- 33 ( 100%) | 260931 ( 100%) | Total 11 (33.3%) | 59746 (22.9%) | Alessandro Vesely 7 (21.2%) | 37255 (14.3%) | John Levine 4 (12.1%) | 51406 (19.7%) | Jim Fenton 4 (12.1%) | 26151 (10.0%) | Matthäus Wander

Re: [dmarc-ietf] WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

I mostly agree but here's a few comments. It appears that Seth Blank said: >Section 4:2: Use of RFC5322.From: > >Is it also worth it to call out that time and operational impact have >proven this to be the right choice? Since we never tried anything else, we don't know. I suppose we might note

[dns-operations] Mysteries of DNSSEC

I have a stunt DNS server at contacts.abuse.net that synthesizes answers from a database so if you look up, say, example.com.contacts.abuse.net it'll give you the contact addresses in TXT records, the number of contacts in an A record, and some hints about where the answer came from in HINFO.

Re: [dns-operations] Evaluation of NSEC3-encloser attack

It appears that Jim Reid said: > > >> On 27 Mar 2024, at 19:37, Ondřej Surý wrote: >> >> Both salt and iterations have absolutely no value for NSEC3 security (see >> the RFC you just quoted), so just always use empty salt and zero iterations. >There’s no added value in fiddling with salt to

Re: [mailop] Debt Collection Client Email Servers

It appears that Jaroslaw Rafa via mailop said: >Does USA have a government-certfied platform for electronic delivery of >documents (like many European countries have) ... No, and given the political structure here, we never will. We do have a post office which delivers mail reliably to every

Re: [mailop] Debt Collection Client Email Servers

It appears that Michael Irvine via mailop said: >I can't say the specific lenders, but I can say that it is not just bank and >money lending. We have clients who are from the courts and other 3rd parties >that do >not fully validate the email that is given to them. We still must take it as

Re: [dmarc-ietf] Errata for Aggregate Reporting

It appears that Alessandro Vesely said: >On Sun 24/Mar/2024 18:06:53 +0100 John Levine wrote: >> It appears that Brotman, Alex said: >> >>>https://www.rfc-editor.org/errata/eid5774 :: There were a number of edits >>>for clarification to this portion of the do

Who is security-research.org ?

I noticed them in my DNS logs, trying to do AXFRs of random zones I host. The probes are coming from Hetzner, a low-cost German hosting provider with a history of tolerating dodgy customer behavior. Their website, which is hosted at Vultr, airly assures us it's nothing personal, they scan

Re: [dmarc-ietf] Errata for Aggregate Reporting

It appears that Brotman, Alex said: >There were a few errata for the aggregate reporting. I wanted to confirm with >the list that these are still valid. > >https://www.rfc-editor.org/errata/eid5440 :: I thought it had been determined >the ";" was not necessary. It was required in 7489 but not

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Mar 24 06:00:04 2024

Count| Bytes | Who ++--- 56 ( 100%) | 437345 ( 100%) | Total 9 (16.1%) | 63038 (14.4%) | Scott Kitterman 9 (16.1%) | 54473 (12.5%) | Alessandro Vesely 9 (16.1%) | 50879 (11.6%) | John Levine 8 (14.3%) | 54502 (12.5%) | Matthäus

Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (7865)

It appears that Murray S. Kucherawy said: >-=-=-=-=-=- > >This seems like it's probably legitimate. Does it need to be fixed in the >-bis document? It's already fixed in the current markdown. FYI, the XML pattern is silly. It forbids harmless stuff like leading zeros in 01.02.03.04 and

Re: [mailop] mailop and DKIM signatures

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

Re: [dmarc-ietf] no DMARC result for DKIM testing and policy

and finish up. R's, John -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC result for DKIM testing and policy

It appears that Todd Herr said: > 2. That part of 6376 might be better written as "Should the signature > fail to verify, verifiers MUST NOT treat messages from Signers in testing > mode differently from unsigned email." as I see no reason to penalize a > Domain Owner who successfully

Re: [mailop] Mailbox Filling w. Opt-In/Sign-Up mails

It appears that Richard Clayton via mailop said: >you have not been paying attention ... it's called list-bombing (Google >will find you many references) > >it dates from 2017 or so ... here's an early high-viz example > >

Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?

Tightened up a little, reworded in view of the fact that your own mail provider (M*r*s*ft) may let people spoof you through shared IP ranges. >11.X External Mail Sender Cross-Domain Forgery Add this to 11.1 Authentication Methods Both of the email authentication methods that underlie DMARC

Re: [mailop] mailop and DKIM signatures

According to Marco Moock via mailop : >Am 16.03.2024 um 17:44:09 Uhr schrieb John Levine: > >> It appears that Marco Moock via mailop said: >> >> But who will follow 13 years old standard... ;-) >> > >> >When Google and Co. make DKIM mandatory, thi

Re: [DNSOP] I-D Action: draft-ietf-dnsop-compact-denial-of-existence-03.txt

It appears that Dave Lawrence said: >Stephane Bortzmeyer writes: >> > One current implementation does not differentiate DO=0 vs 1 and gives the >> > same NODATA answer for both cases. >> >> Yes. I see no practical problem with that but, from a philosophical >> point of view, it disturbs me.

Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?

It appears that Scott Kitterman said: >1. Bad mail gets DMARC pass and so DMARC policy is not applied (avoid >consequences of DMARC fail). > >2. Bad mail gets DMARC pass and something else (e.g. BIMI) does a wrong thing >(gets benefits of DMARC pass). I agree these are the two main points.

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Mar 17 06:00:05 2024

7 ( 6.4%) | 96182 ( 8.6%) | Douglas Foster 7 ( 6.4%) | 34125 ( 3.1%) | John Levine 6 ( 5.5%) | 50080 ( 4.5%) | Murray S. Kucherawy 5 ( 4.6%) | 64726 ( 5.8%) | Hector Santos 5 ( 4.6%) | 61477 ( 5.5%) | Mark Alley 2 ( 1.8%) | 45081 ( 4.0%) | Tobias Herkula 2 ( 1.8

Re: [mailop] mailop and DKIM signatures

It appears that Marco Moock via mailop said: >> But who will follow 13 years old standard... ;-) > >When Google and Co. make DKIM mandatory, this will be hard, because >those messages are likely to be rejected. Why do you imagine that Google is unable to read the specs? I know people at Google

  1   2   3   4   5   6   7   8   9   10   >