Re: [mailop] $GOOG
heho, thanks for bringing this up. i am currently digging a bit in the whole scape of centralization, especially in academia (see page 4-7 here for the perspective of mail-hosting in academia: https://arxiv.org/pdf/2104.09462.pdf ); things are... dire, especially in the us. universities used to be _the_ place self-hosting infrastructure. email is a rather evolving system, and to align the design choices of the past with the needs of a mass Internet, the complexity of running stuff oneself is going up (and the number of dmarc report rua bounces from _large_ entities i get each night tells me that this is not limited to smaller operators...); with major providers intransparently deciding what to enforce (and what applies to them), i hear many saying 'well, if you want your mails delivered, go for $bigone'. this is essentially how we lost xmpp and i fear the dice are already in the cup for smtp et al. (and the rest of the Internet). with best regards, tobias -Original Message- From: mailop On Behalf Of Paul Vixie via mailop Sent: Wednesday, 13 April 2022 23:44 To: mailop@mailop.org Subject: [mailop] $GOOG it's troubling me that in a recent thread asking where to host mailboxes, google was recommended several times, in spite of the fact that google is provably wrong and provably non-transarent in how they decide what inbound e-mail to reject. of all constituencies, this one, mailop, is one i would have expected to know better than to cooperate with your oppressor. ___ 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] [E] $GOOG
> If your friends somehow believe that Gmail is the only mail provider in the > world I suppose I am sorry for them but I don't understand why that is anyone > else's problem. The idea is that you give away something for free, gain significant market share (=network effect), and then get into a position where you can first push standards (hello MTA-STS), and later can migrate to a walled garden, because the default becomes 'if you want it to work, just go to X'. _Then_ you can start to monetize either the product (what we see a lot with 'free' EdTech from google et al.) _or_ use your market position to ensure the technology develops along your product vision (I would argue this is what the chromium engine accomplished for the web). We had this with IE back in the day, now essentially with the chromium engine; As I said, we have this quiet a lot with EdTech. We had this with XMPP. And I think there are also some bold opinions on protocol suggestions for congestion control coming out of google for quick. So, in a sense, it kind of fits in a general trend of centralization, and centralized control; And that may indeed be a problem for people _not_ wanting to host their mail with one of N big providers. And email is simply 'next'. And I don't put any 'nasty' words towards Google/gmail here. They just do what an independent actor working in self-interest trying to optimize their outcomes does in a given system. With best regards, Tobias -Original Message- From: mailop On Behalf Of John Levine via mailop Sent: Sunday, 17 April 2022 05:52 To: mailop@mailop.org Cc: p...@redbarn.org Subject: Re: [mailop] [E] $GOOG It appears that Paul Vixie via mailop said: >srsly? do you really think changing one's domain name or ISP is a >reasonable way forward when google isn't accepting one's e-mail? When your domain is a cruddy free one which has earned a poor reputation, yes. As I have said a few times, sometimes free services are worth what they cost. >i think you could have punctuated that sentence after "operators". but >google is a "shabby mail operator" (your words) who has taken my >friends and family as hostages. ... What we have here appears to be reverse Stockholm syndrome. Google gives away Gmail accounts for free. It is clear that Gmail users are getting at least what they've paid for, and in many cases more than that. If your friends somehow believe that Gmail is the only mail provider in the world I suppose I am sorry for them but I don't understand why that is anyone else's problem. R's, John ___ 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] [E] $GOOG
> Uh, what? Google follows public mail standards at least as well as their > large competitors like YahAOL and Microsoft. You do not have to like MTA-STS, > but it's an open IETF standard and there's a lot more providers than Google > that use it. I was not arguing that google is not following mail standards. I _would_ argue thought that there is a discussion that _could_ be had regarding the sensibility of MTA-STS' design including HTTP; And what hits my rua currently mostly looks like google to me; But I am looking forward to reports from MS et al. However, the point I actually did try to make, though, was indeed that mail is increasing in complexity, and 'the big ones' get things in order (well, apart from those mismatching DNS/EHLO setups from MS), while the tail of non-centralized setups does not keep up, ultimately leading to a mono/multipolization and aggregation of the ecosystem, essentially changing it from 'open' to 'something only big companies can take part in'. > Chromium is open source, and there are dozens of browsers built on it. Could > you explain what the problem is? Which, again, is exactly my point. Chromium, by now, drives the majority of browsers, in part because it is open source, and also because it is really good at what it does. Still, I would argue that the majority of contributions to that codebase comes from google employees. Or, to underline who makes product decissions for chromium, from the git log: "Do not revert without consulting chrome-...@google.com" Hence, this open source core puts google into a position where they could simply decide the direction into which the web goes. Also, as a disclaimer: The core of this argument is not about whether google (or any other player in a comparable market position for a specific ecosystem; Think of Cisco in the past for networking, MS for OS in the past etc.) _would_ leverage their power to further their own interests, or are generally 'the bad ones'. I _personally_ would argue that utilizing that power to leverage their own interests is a reasonable expectation if they are an economically working actor. Independent of one's own answer to that question, though, the _real_ question is whether it is good for the Internet and society at large if individual actors get into a position where they _could_ leverage their pull on the ecosystem; And, to be fair, google has been using that power for good things as well; See, for example, the phase-out of plain http, which I would attribute--in large parts--to the chrom(e|ium) decissions around handling http. Still, the question remains; What ecosystem do we want a society to run on? With best regards, Tobias -Original Message- From: mailop On Behalf Of John Levine via mailop Sent: Sunday, 17 April 2022 19:42 To: mailop@mailop.org Cc: tob...@fiebig.nl Subject: Re: [mailop] [E] $GOOG It appears that Tobias Fiebig via mailop said: >> If your friends somehow believe that Gmail is the only mail provider in the >> world I suppose I am sorry for them but I don't understand why that is >> anyone else's problem. > >The idea is that you give away something for free, gain significant >market share (=network effect), and then get into a position where you can >first push standards (hello MTA-STS), and later can migrate to a walled >garden, ... Uh, what? Google follows public mail standards at least as well as their large competitors like YahAOL and Microsoft. You do not have to like MTA-STS, but it's an open IETF standard and there's a lot more providers than Google that use it. >We had this with IE back in the day, now essentially with the chromium >engine; Chromium is open source, and there are dozens of browsers built on it. Could you explain what the problem is? R's, John ___ 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] [E] $GOOG
Heho, > We spent months working out the details, including why it uses HTTPS rather > than DANE, on public mailing lists in the IETF. (I would have preferred DANE, > but the choice of HTTPS was not made casually.) To clarify, my comment did not want to pull the found consensus into question, and I do not doubt that there are good reasons _for_ HTTPS at this level. This comment relates more to issues in the operational implementation I encountered when I (recently) implemented MTA-STS; The most pressing one that the MTA-STS policy is bound to the recipient domain, which means that I can not simply roll it out for all my MX, iff they are accepting mail for domains where I do not control the DNS, and my favorit MTA not supporting MTA-STS, because they do not want to include an HTTP client. However, I also assume that such issues were indeed discussed, and a tradeoff happened. > If this is something you care about, where were you? This one hurts, mostly because I know where I was, and also know where I rather would have been, doing what. ;-) > I have certainly run into plenty of people who've had trouble getting their > mail into Gmail, loudly announced that GMAIL HAS BROKEN MAIL FOR EVERYONE IN > THE WORLD, then I take a look and say "do you know what SPF is?" "No, why do > you ask?" Sigh. I think this gets to the core of why centralization for many things is succesfull in the first place (leaving the whole good/bad/intention discussion out of it). Running systems is not easy; Especially for basic infrastructure (which email is), it should just _work_. Then again, over the past three decades, it also got _a lot_ more complex (see [0] for my favorit summary on that); There is also some work I was involved in which I hope to be able to share with the list by the end of the month, goin into the direction of "good setups" w.r.t. mail hosters, and the results align pretty much with your observation there. However, it also circles back to the age old question (among people sceptical of centralization) of how we can have more distributed infrastructure, without having it a) constantly break, b) crappily maintained, and thereby c) causing more issues than it solves. At the moment, I sadly do not yet have a good answer for that, and I suspect that it won't have a technical answer at all. With best regards, Tobias [0] https://dataswamp.org/~solene/2021-07-09-obsolete-feeling-in-the-crossfire.html ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] MTA-STS Key-Value Delimiter
Heho, I recently deployed MTA-STS, but am somewhat lost with the kv delimiters in the policy file: RFC8461 calls for CRLF delimited values; Errata 6253 notes that this _should_ have been CRLF or LF. I opted for the former, assuming that it is more likely people didn't read the eratta and only delimit on CRLF, while those reading the eratta most likely would to both: From the report: "policy-string":["version: STSv1\r","mode: enforce\r","mx: mail.aperture-labs.org\r","mx: mail2.aperture-labs.org\r","max_age: 86400\r"] In the MTA-STS reports I am getting (from google only so far) now, I do see that they are delmiting on LF only, pulling the CR into the values, at least in the reported policy. I am now wondering if this might cause any issues? With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [EXTERNAL] MTA-STS Key-Value Delimiter
Heho, Good to hear it is only cosmetic. :-) > I do think it's reasonable to assume CRLF is the safer value. :) Well, difficult. I'd say that the initial phrasing of the RFC might have cause some confusion. But one would have to gauge a lot more implementations to know that... 🤔 Might be a worthwhile measurement study. With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM by the third party
Heho, Depends on what you mean here. Option A: You use that third party mail-server as a legitimate outbound relay. In this case, I would argue, that it makes a limited amount of sense, i.e., they configured sth. wrongly, maybe because you have no DKIM configuration coordinated with them. Option B: You sent to an address on that server, and they forward your mail. Here, it does make some sense, I'd, say, depending on what they do. For example, I do the same, i.e., providing an _additional_ dkim sig, on forwarded mail, because I also apply SRS to messages. So, then I add a signature for the new envelope from domain from SRS, and add ARC headers as well. With best regards, Tobias -Original Message- From: mailop On Behalf Of Henrik S via mailop Sent: Thursday, 21 April 2022 04:05 To: mailop@mailop.org Subject: [mailop] DKIM by the third party Hello My mail is sent by the third party smtp server, and the dkim signature is made for the third party domain (for this case, it's pobox.com). does this DKIM have helps to the authorization of my outgoing messages? Thanks ___ 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] Troubleshooting MTA-STS reports
Heho, Interestingly, Microsoft also sends TLSRPT, even when they use TLSA instead of MTA-STS. With best regards, Tobias -Original Message- From: mailop On Behalf Of Jesse Hathaway via mailop Sent: Tuesday, 26 April 2022 23:23 To: Eric Tykwinski Cc: mailop@mailop.org Subject: Re: [mailop] Troubleshooting MTA-STS reports On Tue, Apr 26, 2022 at 4:08 PM Eric Tykwinski wrote: > Everything looks fine to me, have you tried sending an email to a another > google account. > They are the one company I know sends MTA-STS reports, others sadly don’t. Thanks for checking, I didn't realize they were so rare. > My guess is that Google might not be sending inter-domain reports since your > hosted there. > Doesn’t make sense to me, but I’m sure if that’s the case Brandon or someone > else from Google will tell you. I was wondering whether that might be part of the problem. ___ 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] DMARC/TLSRPT to non-existing accounts/reflection and sender reputation
Heho, This might be a bit of a theoretical attack thing, but looking over the bounces for my nightly outbound DMARC reports I actually started to wonder about this; (Mostly because I am getting scared by regularly sending DMARC reports to non -existing accounts on a major ESP ;-)). Maybe I am overlooking/overthinking something here, but it would be nice to hear what others think about it, and whether they think that this is actually a problem needing a solution. Assumptions: - Many major ESPs track a sending mailer's reputation; If a host tries to throw in a lot of mail for non-existing users/domains, reputation goes down. - There are spam-traps out there with pretty much the same goal; see what flies in and, e.g., populate RBLs Setup: - I create _a lot_ of subdomains - MX (I just set it; not sanctioned by the ESP) for the subdomains is either a large ESP or a spam-trap. - Create a -all SPF record and a DMARC p=reject entry and a rua=mailto:p@, as well as the _report._dmarc record for each of these sub-domains Execution: - I generate a lot of mails (one From: per subdomain) towards a target (ESP, small setup) that sends DMARC reports - The target rejects my mails (spf -all) and sends a DMARC report; Based on the MX this goes to the ESP/spam-trap. - The spam-trap/ESP get a lot of 'unknown recipient/domain' mails from my target; They don't accept them, but take note for the senders' reputation. -> Sender reputation of the target goes down With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DMARC/TLSRPT to non-existing accounts/reflection and sender reputation
Heho, Yes; The benefit of this is also that you do not need your target to have any service you can subscribe on running; They just have to follow a proper mail setup. But I like you suggestion. Would be any of the larger ESPs who is doing sender reputation by IP up for a test? .oO( I would like to do this in coordination, as I'd use some of my own IPs for this, and would prefer not to permanently burn the whole network... ) With best regards, Tobias -Original Message- From: mailop On Behalf Of Ángel via mailop Sent: Saturday, 30 April 2022 20:47 To: mailop@mailop.org Subject: Re: [mailop] DMARC/TLSRPT to non-existing accounts/reflection and sender reputation That's an interesting attack. I initially thought you were going to describe placing a victim as your destination target which is something which is prevented by requiring the receiver to authorize them: https://www.rfc-editor.org/rfc/rfc7489.html#section-7.1 But this is getting a spamtrap to accept emails and treating them as intruding attempts. The onus should be on them to detect that they are the MX of the target domain, and thus the sender may be playing by the rules. Quite easy to notice if you start seeing in DMARC reports in your spamtrap, actually. But this doesn't mean that all spamtrap operators do that, or wouldn't be vulnerable to that. Note that you could perform a similar attack by subscribing a user to a number of mailing lists, promotions, etc. then changing your MX to a spamtrap, which would then blame the sender IP. Regards ___ 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] Outlook Sender Support Complaint Messages Broken With DMARC
Heho,
I signed up for the sender support (sendersupport.olc ) of Microsoft and
activated forwarding of messages flagged by users as spam. Today I saw an email
sent by microsoft to postmaster@ with a from of one of my domains rejected
based on the domains DMARC policy by my mailer.
Based on the data in my rspam log and the sendersupport site showing ~1 mail
having been marked as spam by a user, I _suspect_ that this is the forward
feature; However, this feature seems to break DKIM signatures and re-signs with
hotmail.com, leading to the DMARC policy reject triggering, as neither SPF nor
DKIM match;
Is there any good way to get into contact with them about this (as this is not
really me having issues sending to them, but them to me ;-))/is anyone from MS
reading on this list?
With best regards,
Tobias
rspamd.log:2022-04-30 10:54:14 #27730(normal) <1736ea>; task;
rspamd_task_write_log: id: <267a1c47b4bb64e17ab1633ea69b5...@engelsystem.de>,
qid: , ip: 40.92.58.32, from: , (default: T
(reject): [10.00/10.00]
[NEURAL_HAM(-2.97){-0.991;},DMARC_POLICY_REJECT(2.00){engelsystem.de : SPF not
aligned (relaxed), DKIM not aligned
(relaxed);reject;},FORGED_RECIPIENTS(2.00){m:@outlook.de;s:postmas...@aperture-labs.org;},ARC_ALLOW(-1.00){microsoft.com:s=arcselector9901:i=1;},DATE_IN_PAST(1.00){38;},FORGED_SENDER(0.30){noreply-hamburg-hi...@engelsystem.de;st...@hotmail.com;},R_DKIM_ALLOW(-0.20){hotmail.com:s=selector1;},R_SPF_ALLOW(-0.20){+ip4:40.92.0.0/15;},MIME_GOOD(-0.10){text/plain;},MX_GOOD(-0.01){},BAYES_SPAM(0.00){39.71%;},ARC_SIGNED(0.00){aperture-labs.org:s=key01:i=2;},ASN(0.00){asn:8075,
ipnet:40.80.0.0/12,
country:US;},DKIM_MIXED(0.00){},DKIM_TRACE(0.00){hotmail.com:+;engelsystem.de:-;},DWL_DNSWL_NONE(0.00){hotmail.com:dkim;},FREEMAIL_ENVFROM(0.00){hotmail.com;},FREEMAIL_TO(0.00){outlook.de;},FROM_HAS_DN(0.00){},FROM_NEQ_ENVFROM(0.00){noreply-hamburg-hi...@engelsystem.de;st...@hotmail.com;},MID_RHS_MATCH_FROM(0.00){},MIME_TRACE(0.00){0:+;},RCPT_COUNT_ONE(0.00){1;},RCVD_COUNT_SEVEN(0.00){11;},RCVD_TLS_LAST(0.00){},RCVD_VIA_SMTP_AUTH(0.00){},R_DKIM_REJECT(0.00){engelsystem.de:s=es;},TO_DN_NONE(0.00){}]),
len: 9927, time: 1357.5940132141113ms, dns req: 61, digest:
<197fd69596e5326847617462eb097561>, rcpts: ,
mime_rcpts: <@outlook.de>, forced: reject "Action set by DMARC";
score=nan (set by dmarc)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamhaus: Get more details about LISTING (Could a DMARC Report Address point to a spamtrap)?
Heho, I recently described how this could actually be used by a malicious third party to cause a sender to be blocklisted by major mail operators (see thread titled "DMARC/TLSRPT to non-existing accounts/reflection and sender reputation" from the end of April). However, in your case it does not really sound malicious. Still, spamhaus might have picked up expired domains to setup spam traps, and you may be sending to a ruf/rua on an expired domain. (Note: Wild guess) In any case, I would be _really_ interested in hearing more in case you figure out the root-cause of this. With best regards, Tobias -Original Message- From: mailop On Behalf Of Benoit Panizzon via mailop Sent: Tuesday, 17 May 2022 10:49 To: mailop@mailop.org Subject: [mailop] Spamhaus: Get more details about LISTING (Could a DMARC Report Address point to a spamtrap)? Hopefully somebody from spamhaus is reading. The 2nd day in a row, our main mailplattform IP address is listed and outlook.com blocks all emails. Spamhaus only gives a timestamp +/- 5 minutes. There are A LOT OF EMAILS passing our plattform in 10 Minutes. Yesterday I found a suspect. One customer had configured his exchange server to relay 'bounces' via our platform. That was fixed. Today I am looking through the logs again. No suspicious emails. But in that timespam, we send out DMARC reports. Could it be, that someone publishes a DMARC Report address which points to a Spamhaus Spamtrap? For the 2nd time I requestd 'more details' from Spamhaus. Is there a chance to get such informations? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G-Leiter Commerce Kunden __ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 PrattelnFax +41 61 826 93 01 Schweiz Web http://www.imp.ch __ ___ 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] Spamhaus: Get more details about LISTING (Could a DMARC Report Address point to a spamtrap)?
Heho, > If they did, they would age them for at least a year before turning them into > traps, by which time the DMARC records would be long gone. I generally agree with your argument, that this is a really unlikely scenario. Also, because the spam-trap domain would naturally lack the ._report._dmarc. record necessary, this pretty much will not be the case; I overlooked that. However, judging from the state of DMARC reporting by the bounces hitting my report-from (_large_ orgs having non existent mailboxes in there etc.), I'd argue that the only thing that prevents ruf/rua that are stale for a decade is the age of RFC7489. With best regards, Tobias -Original Message- From: mailop On Behalf Of John Levine via mailop Sent: Tuesday, 17 May 2022 23:23 To: mailop@mailop.org Cc: tob...@fiebig.nl Subject: Re: [mailop] Spamhaus: Get more details about LISTING (Could a DMARC Report Address point to a spamtrap)? It appears that Tobias Fiebig via mailop said: >Heho, >I recently described how this could actually be used by a malicious >third party to cause a sender to be blocklisted by major mail operators (see >thread titled "DMARC/TLSRPT to non-existing accounts/reflection and sender >reputation" from the end of April). However, in your case it does not really >sound malicious. > >Still, spamhaus might have picked up expired domains to setup spam >traps, and you may be sending to a ruf/rua on an expired domain. (Note: >Wild guess) If they did, they would age them for at least a year before turning them into traps, by which time the DMARC records would be long gone. That's not it. I suppose someone could set up a malicious MX to aim random junk at mail servers, but Spamhaus' trap servers are pretty hard to find. ___ 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] Spamhaus: Get more details about LISTING (Could a DMARC Report Address point to a spamtrap)?
Heho, > They're just reporting what they recieve. It shouldn't be a big surprise > that spamware makes up addresses, some of which happen to be in your domains. Nah, i mean 'i receive spam with a from of $large_entity and reject due to DMARC failing', hence my systen tries to send a report to whatever is the rua in _dmarc., and it bounces for $various_reasons (mailbox full, mailbox does not exist, [...]). No clue what this bouncing has to do with spamware making up addresses in some of my domains? With best regards, Tobias -Original Message- From: mailop On Behalf Of John R Levine via mailop Sent: Wednesday, 18 May 2022 01:23 To: Tobias Fiebig ; mailop@mailop.org Subject: Re: [mailop] Spamhaus: Get more details about LISTING (Could a DMARC Report Address point to a spamtrap)? On Tue, 17 May 2022, Tobias Fiebig wrote: > However, judging from the state of DMARC reporting by the bounces > hitting my report-from (_large_ orgs having non existent mailboxes in > there etc.), I'd argue that the only thing that prevents ruf/rua that > are stale for a decade is the age of RFC7489. They're just reporting what they recieve. It shouldn't be a big surprise that spamware makes up addresses, some of which happen to be in your domains. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ 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] Paper on email delivery/standards adoption
Heho, Quiet some time ago i asked the list for some help in an ongoing email measurement study; The paper is now finally out and accepted. An open-access preprint can be found here: https://pure.mpg.de/rest/items/item_3384330_2/component/file_3388008/content I guess the most interesting result on this list is that the 'Email Camel' (after the DNS Camel) is more complex than... well, DNS. Anyway, figured it might be interesting for some on the list. With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Paper on email delivery/standards adoption
Heho, Thanks, already found that. :-| There is another embarrassing one later on in the paper. Sadly nothing we can do about the version going to Usenix anymore. :-/ With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M <mailto:tob...@fiebig.nl> tob...@fiebig.nl From: mailop On Behalf Of Patrick Ben Koetter via mailop Sent: Tuesday, 14 June 2022 11:41 To: mailop@mailop.org Subject: Re: [mailop] Paper on email delivery/standards adoption Typo in line 4 SMPT -> SMTP Am 13.06.22 um 21:21 schrieb Tobias Fiebig via mailop: Heho, Quiet some time ago i asked the list for some help in an ongoing email measurement study; The paper is now finally out and accepted. An open-access preprint can be found here: https://pure.mpg.de/rest/items/item_3384330_2/component/file_3388008/content I guess the most interesting result on this list is that the 'Email Camel' (after the DNS Camel) is more complex than... well, DNS. Anyway, figured it might be interesting for some on the list. With best regards, Tobias ___ mailop mailing list mailop@mailop.org <mailto:mailop@mailop.org> https://list.mailop.org/listinfo/mailop -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Someone from freenet.de on this list?
Heho, This is indeed--to a degree--an issue. In general, I'd argue that MLs should pretty much behave like mail-op; I.e.: Rewrite sender; In addition, one might also want to strip existing DKIM and/or re-sign the message with one's own key. Alternatively, you can also investigate whether there are ways to not break DKIM upon ML posting; I had my own endeavor with the implications of DMARC/DKIM/SPF and MLs recently: https://doing-stupid-things.as59645.net/email/mailinglists/dmarc/2022/05/19/sending-an-email.html Ultimately, DMARC, DKIM, and SPF will not be going away, and if you want to deliver to 'the big ones' you essentially must have it in place. So, if you want to keep providing a working service (and no judgement on the implications and interrelations there, and whether this makes sense; I have a ton of opinions on that, but that goes way beyond the scope of this ML), I guess there is no path that does not go through deploying SPF/DKIM/DMARC yourself and finding ways to make your MLs play along with sender domains that have it deployed as well. With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] What to do with a look-alike domain used in phishing
Heho, ~a year ago I registered a (by then) unregistered look-alike domain for a major European hoster, as I was receiving rather good spear-phishing from it, and it was, well, unregistered. (The domain is hetzners.de ). I setup DMARC p=reject and SPF -all, and let it be. Now, the domain keeps sitting around; Thing is, that dereg would most likely lead to more spam falling out of the domain again (or it being actually registered by some spammer), which is rather not so nice to the Internet as a whole. The hoster is not interested in receiving it from me (free of charge etc.; Offered to just send them the authcode). Now, what can I ethically do with the domain? I would kind of prefer it going to some org. that actually makes an effort in drying out domains used like this; Does somebody have a suggestion/contact whom to ask? With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Microsoft DMARC RUA Mailbox Full
Heho, Not sure if anyone from microsoft/microsoft.com is reading along, but your RUA mailbox seems to be full, and now bounces. ;-) With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication
Heho, We did some measurements on this recently, see: https://www.usenix.org/system/files/atc22-holzbauer.pdf At the moment, I’d say that you still lose _some_ destinations (and delivering MTAs) by forcing TLS (~10% of smaller providers). This is _any_ TLS; Numbers for disabling 1.0/1.1 will look worse than those 10%, even though we did not test that. The methodology we use should be easily adjustable to also test for specific version support; However, recruiting a wide sample of people will be difficult. What you _could_ do as a large ESP is configuring multiple MXes with the same priority and different settings and run a large scale study that way about MTA’s preferences without impacting mail delivery. If you are willing to give that a shot, I’d be _very_ interested in collaborating. Side note: I recently ran into a security research institute with whom I could not agree on ciphers with the OpenSMTPd default cipher list on my side… their choices were just a tad dusty… With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Debugging MTA-STS sending
Heho, I am currently trying to debug a test for MTA-STS sending; The setup is a domain with an MX with an invalid certificate to test whether MTA-STS policies are honord (if they are, no mail should be received). I tested this last night with an ESP I know should be honoring MTA-STS; However, while the policy was retrieved from the webserver, the email got ultimately delivered. I also did not get an MTA-STS TLS-RPT, even though other domains got them from the same ESP today. Could some of you who are on a setup that validates MTA-STS please try to send me an email to, and if it (hopefully) fails share the NDR?: measurem...@mail-mtasts.measurement.email-security-scans.org (Alternatively, if you see something wrong in the config, please let me know.) With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Debugging MTA-STS sending
Hello Eric,
This is interesting. The certificate for tls-invalid should a) not match the
CN, and b) be expired. The ": b'84:OK secure
match=tls-invalid.measurement.email-security-scans.org servername=hostname,'"
is hence a bit confusing. Also just tested it with 'openssl s_client -starttls
smtp -crlf -connect tls-invalid.measurement.email-security-scans.org:25' just
now, and the CN does indeed not match.
I will look into this.
With best regards,
Tobias
--
Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M tob...@fiebig.nl
-Original Message-
From: Eric Tykwinski
Sent: Tuesday, 9 August 2022 15:01
To: 'Tobias Fiebig' ; mailop@mailop.org
Subject: RE: [mailop] Debugging MTA-STS sending
Tobias,
I'm actually sort of interested now as well.
I just ran this through postfix-mta-sts-resolver
(https://github.com/Snawoot/postfix-mta-sts-resolver)
Log for test:
2022-08-09 08:52:32 DEBUGSTS: len(self._children) = 1
2022-08-09 08:52:32 DEBUGSTS: Read: b'56:postfix
mail-mtasts.measurement.email-security-scans.org,'
2022-08-09 08:52:32 DEBUGSTS: Enq request: b'postfix
mail-mtasts.measurement.email-security-scans.org'
2022-08-09 08:52:32 DEBUGSTS: Got new future from queue
2022-08-09 08:52:32 DEBUGSTS: Lookup PERFORMED: domain =
mail-mtasts.measurement.email-security-scans.org
2022-08-09 08:52:32 DEBUGRES: Got STS resolve request:
sts_txt_domain=_mta-sts.mail-mtasts.measurement.email-security-scans.org,
known_id=None
2022-08-09 08:52:32 DEBUGRES: Parsed STS record for domain
'mail-mtasts.measurement.email-security-scans.org': {'v': 'STSv1', 'id':
'2022080901'}
2022-08-09 08:52:33 DEBUGRES: Parsed policy for domain
mail-mtasts.measurement.email-security-scans.org: {'mx':
['tls-invalid.measurement.email-security-scans.org'], 'version': 'STSv1',
'mode': 'enforce', 'max_age': '86400'}
2022-08-09 08:52:33 DEBUGSTS: Future await complete: data=b'84:OK secure
match=tls-invalid.measurement.email-security-scans.org servername=hostname,'
2022-08-09 08:52:33 DEBUGSTS: Wrote: b'84:OK secure
match=tls-invalid.measurement.email-security-scans.org servername=hostname,'
2022-08-09 08:52:33 DEBUGSTS: Client disconnected
Log for my server which is valid:
2022-08-09 08:54:09 DEBUGSTS: len(self._children) = 1
2022-08-09 08:54:09 DEBUGSTS: Read: b'20:postfix virtcolo.com,'
2022-08-09 08:54:09 DEBUGSTS: Enq request: b'postfix virtcolo.com'
2022-08-09 08:54:09 DEBUGSTS: Got new future from queue
2022-08-09 08:54:09 DEBUGSTS: Lookup PERFORMED: domain = virtcolo.com
2022-08-09 08:54:09 DEBUGRES: Got STS resolve request:
sts_txt_domain=_mta-sts.virtcolo.com, known_id=None
2022-08-09 08:54:09 DEBUGRES: Parsed STS record for domain 'virtcolo.com':
{'v': 'STSv1', 'id': '20220309085700'}
2022-08-09 08:54:09 DEBUGRES: Parsed policy for domain virtcolo.com: {'mx':
['mail.virtcolo.com', '*.virtcolo.com'], 'version': 'STSv1', 'mode': 'enforce',
'max_age': '604800'}
2022-08-09 08:54:09 DEBUGSTS: Future await complete: data=b'67:OK secure
match=mail.virtcolo.com:.virtcolo.com servername=hostname,'
2022-08-09 08:54:09 DEBUGSTS: Wrote: b'67:OK secure
match=mail.virtcolo.com:.virtcolo.com servername=hostname,'
2022-08-09 08:54:09 DEBUGSTS: Client disconnected
Both seem to work fine.
Sincerely,
Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300
-Original Message-
From: mailop On Behalf Of Tobias Fiebig via mailop
Sent: Tuesday, August 9, 2022 6:24 AM
To: mailop@mailop.org
Subject: [mailop] Debugging MTA-STS sending
Heho,
I am currently trying to debug a test for MTA-STS sending; The setup is a
domain with an MX with an invalid certificate to test whether MTA-STS policies
are honord (if they are, no mail should be received). I tested this last night
with an ESP I know should be honoring MTA-STS; However, while the policy was
retrieved from the webserver, the email got ultimately delivered. I also did
not get an MTA-STS TLS-RPT, even though other domains got them from the same
ESP today.
Could some of you who are on a setup that validates MTA-STS please try to send
me an email to, and if it (hopefully) fails share the NDR?:
measurem...@mail-mtasts.measurement.email-security-scans.org
(Alternatively, if you see something wrong in the config, please let me know.)
With best regards,
Tobias
___
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] Debugging MTA-STS sending
Heho, Currently not sue why the DNS policy is missing. Will revisit the RFC, might be due to ttl. dig +short TXT _mta-sts.mail-mtasts.measurement.email-security-scans.org "v=STSv1; id=2022080902" With best regards, Tobias -Original Message- From: Luis E. Muñoz Sent: Tuesday, 9 August 2022 17:11 To: Tobias Fiebig Cc: Eric Tykwinski ; mailop@mailop.org Subject: Re: [mailop] Debugging MTA-STS sending On 9 Aug 2022, at 10:27, Tobias Fiebig via mailop wrote: > This is interesting. The certificate for tls-invalid should a) not match the > CN, and b) be expired. The ": b'84:OK secure > match=tls-invalid.measurement.email-security-scans.org servername=hostname,'" > is hence a bit confusing. Also just tested it with 'openssl s\_client > -starttls smtp -crlf -connect > tls-invalid.measurement.email-security-scans.org:25' just now, and the CN > does indeed not match. https://esmtp.email/tools/mta-sts/ also is reporting on a missing DNS policy. The cert is reported as expired as well. -lem ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Debugging MTA-STS sending
Heho, Debugging this further, "MTA-STS DNS Policy" is also marked x when the TXT record is present but the policy is faulty, e.g., due to a non-compliant MX. So, everything as it should be in this case. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl -Original Message- From: mailop On Behalf Of Tobias Fiebig via mailop Sent: Tuesday, 9 August 2022 17:57 To: 'Luis E. Muñoz' Cc: mailop@mailop.org; 'Eric Tykwinski' Subject: Re: [mailop] Debugging MTA-STS sending Heho, Currently not sue why the DNS policy is missing. Will revisit the RFC, might be due to ttl. dig +short TXT _mta-sts.mail-mtasts.measurement.email-security-scans.org "v=STSv1; id=2022080902" With best regards, Tobias -Original Message- From: Luis E. Muñoz Sent: Tuesday, 9 August 2022 17:11 To: Tobias Fiebig Cc: Eric Tykwinski ; mailop@mailop.org Subject: Re: [mailop] Debugging MTA-STS sending On 9 Aug 2022, at 10:27, Tobias Fiebig via mailop wrote: > This is interesting. The certificate for tls-invalid should a) not match the > CN, and b) be expired. The ": b'84:OK secure > match=tls-invalid.measurement.email-security-scans.org servername=hostname,'" > is hence a bit confusing. Also just tested it with 'openssl s\_client > -starttls smtp -crlf -connect > tls-invalid.measurement.email-security-scans.org:25' just now, and the CN > does indeed not match. https://esmtp.email/tools/mta-sts/ also is reporting on a missing DNS policy. The cert is reported as expired as well. -lem ___ 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] Debugging MTA-STS sending
Heho, Ok, for those who are (potentially) interested, I just setup some more MTA-STS domains with slight deviations; Will debug the lib shared earlier a bit with those. measurem...@mail-mtasts-n-iv.measurement.email-security-scans.org : MX has non-matching, expired certificate, policy delimited with \n measurem...@mail-mtasts-rn-iv.measurement.email-security-scans.org : MX has non-matching, expired certificate, policy delimited with \r\n measurem...@mail-mtasts-n-plain.measurement.email-security-scans.org : MX does not advertise starttls, policy delimited with \n measurem...@mail-mtasts-rn-plain.measurement.email-security-scans.org : MX does not advertise starttls, policy delimited with \r\n measurem...@mail-mtasts-n-mult-ivv.measurement.email-security-scans.org : Two MX; prio 10 has non-matching, expired certificate, prio 50 has valid TLS certificat, policy delimited with \n measurem...@mail-mtasts-rn-mult-ivv.measurement.email-security-scans.org : Two MX; prio 10 has non-matching, expired certificate, prio 50 has valid TLS certificat, policy delimited with \r\n measurem...@mail-mtasts-n-mult-ivp.measurement.email-security-scans.org : Two MX; prio 10 does not advertise starttls, prio 50 has non-matching, expired certificate, policy delimited with \n measurem...@mail-mtasts-rn-mult-ivp.measurement.email-security-scans.org : Two MX; prio 10 does not advertise starttls, prio 50 has non-matching, expired certificate, policy delimited with \r\n With best regards, Tobias -Original Message- From: mailop On Behalf Of Tobias Fiebig via mailop Sent: Tuesday, 9 August 2022 19:46 To: 'Tobias Fiebig' ; 'Luis E. Muñoz' Cc: mailop@mailop.org; 'Eric Tykwinski' Subject: Re: [mailop] Debugging MTA-STS sending Heho, Debugging this further, "MTA-STS DNS Policy" is also marked x when the TXT record is present but the policy is faulty, e.g., due to a non-compliant MX. So, everything as it should be in this case. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl -Original Message- From: mailop On Behalf Of Tobias Fiebig via mailop Sent: Tuesday, 9 August 2022 17:57 To: 'Luis E. Muñoz' Cc: mailop@mailop.org; 'Eric Tykwinski' Subject: Re: [mailop] Debugging MTA-STS sending Heho, Currently not sue why the DNS policy is missing. Will revisit the RFC, might be due to ttl. dig +short TXT _mta-sts.mail-mtasts.measurement.email-security-scans.org "v=STSv1; id=2022080902" With best regards, Tobias -Original Message- From: Luis E. Muñoz Sent: Tuesday, 9 August 2022 17:11 To: Tobias Fiebig Cc: Eric Tykwinski ; mailop@mailop.org Subject: Re: [mailop] Debugging MTA-STS sending On 9 Aug 2022, at 10:27, Tobias Fiebig via mailop wrote: > This is interesting. The certificate for tls-invalid should a) not match the > CN, and b) be expired. The ": b'84:OK secure > match=tls-invalid.measurement.email-security-scans.org servername=hostname,'" > is hence a bit confusing. Also just tested it with 'openssl s\_client > -starttls smtp -crlf -connect > tls-invalid.measurement.email-security-scans.org:25' just now, and the CN > does indeed not match. https://esmtp.email/tools/mta-sts/ also is reporting on a missing DNS policy. The cert is reported as expired as well. -lem ___ 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] Debugging MTA-STS sending
Heho, Ok, at least something that works. :-| I am currently setting up a host to implement the postfix lib you shared earlier; Let's see what falls out of that. With best regards, Tobias -Original Message- From: mailop On Behalf Of Eric Tykwinski via mailop Sent: Tuesday, 9 August 2022 20:24 To: mailop@mailop.org Subject: Re: [mailop] Debugging MTA-STS sending Tobias, No starttls definitely works for me at least: MailCow with postfix-mta-sts-resolver. __ This is the mail system at host mail.virtcolo.com. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system : TLS is required, but was not offered by host plaintext.measurement.email-security-scans.org[195.191.197.83] __ Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 ___ 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] Debugging MTA-STS sending
Heho, I just gave https://github.com/Snawoot/postfix-mta-sts-resolver a try, and it works as expected for me. The only mails getting delivered are those for the test-cases where at least one MX is valid; And in those cases the mail flows through the lower-prio MX with the valid cert. So, if you still see some other mails delivered, something might be different on mailcow. Giving that a shot now. With best regards, Tobias -Original Message- From: mailop On Behalf Of Tobias Fiebig via mailop Sent: Tuesday, 9 August 2022 20:37 To: mailop@mailop.org Subject: Re: [mailop] Debugging MTA-STS sending Heho, Ok, at least something that works. :-| I am currently setting up a host to implement the postfix lib you shared earlier; Let's see what falls out of that. With best regards, Tobias -Original Message- From: mailop On Behalf Of Eric Tykwinski via mailop Sent: Tuesday, 9 August 2022 20:24 To: mailop@mailop.org Subject: Re: [mailop] Debugging MTA-STS sending Tobias, No starttls definitely works for me at least: MailCow with postfix-mta-sts-resolver. __ This is the mail system at host mail.virtcolo.com. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system : TLS is required, but was not offered by host plaintext.measurement.email-security-scans.org[195.191.197.83] __ Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 ___ 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] Debugging MTA-STS sending
Heho, Thanks! Looks promising or rather working. :-) I am currently dealing with a major ESP for some reason not finding my policies... Will come back to the list as soon as the web/selftest interface is ready. :-) With best regards, Tobias -Original Message- From: mailop On Behalf Of Alessandro Vesely via mailop Sent: Wednesday, 10 August 2022 18:55 To: mailop@mailop.org Subject: Re: [mailop] Debugging MTA-STS sending On Tue 09/Aug/2022 12:23:51 +0200 Tobias Fiebig via mailop wrote: > > I am currently trying to debug a test for MTA-STS sending; The setup is a > domain with an MX with an invalid certificate to test whether MTA-STS > policies are honord (if they are, no mail should be received). I tested this > last night with an ESP I know should be honoring MTA-STS; However, while the > policy was retrieved from the webserver, the email got ultimately delivered. > I also did not get an MTA-STS TLS-RPT, even though other domains got them > from the same ESP today. > > Could some of you who are on a setup that validates MTA-STS please try to > send me an email to, and if it (hopefully) fails share the NDR?: > > measurem...@mail-mtasts.measurement.email-security-scans.org Here's the warning I've received thus far, using Courier-MTA: --- DELAYS IN DELIVERING YOUR MESSAGE The delivery of the following E-mail message has been delayed. This is an advisory notice only; it is sent only to notify you about a temporary delay in delivering your message. You DO NOT need to do anything at this time. Additional attempts to deliver your message will be made. Some possible reasons for this delay: * Network congestion or failure. * The destination mail server is temporarily off-line. Diagnostic information is provided below for each recipient. If copies of this message were sent to additional recipients, deliveries to those addresses are not included in this notice. This is an advisory notice for the following addresses only: : tls-invalid.measurement.email-security-scans.org [195.191.197.90]: >>> STARTTLS <<< 400 Invalid peer certificate --- If your message was also sent to additional recipients, their delivery status is not included in this report. You may or may not receive other delivery status notifications for additional recipients. The original message follows as a separate attachment. --=_courier_0 Content-Type: message/delivery-status Content-Transfer-Encoding: 7bit Reporting-MTA: dns; wmail.tana.it Arrival-Date: Wed, 10 Aug 2022 09:55:52 +0200 Received-From-MTA: dns; [172.25.197.111] (pcale.tana [172.25.197.111]) Final-Recipient: rfc822; measurem...@mail-mtasts.measurement.email-security-scans.org Action: delayed Status: 4.0.0 Will-Retry-Until: Wed, 17 Aug 2022 09:55:52 +0200 --=_courier_0 Content-Type: text/rfc822-headers; charset="utf-8" Content-Transfer-Encoding: 7bit [DELETED] --=_courier_0-- Best Ale -- ___ 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] Gmail Dynamic Email / Impact on Email Ecosystem
Heho, The gmail feature 'dynamic email' [1] just flew by me, and I was somewhat wondering whether this is google proprietary, or if there is some standardization going on (already completed?) which I missed. From the product page it currently looks more like an integration in the google ecosystem; Either way, I believe that this might be something to have a discussion on. If it is backed by open standards, there are some interesting discussions to be had re: impact of such a feature in terms of security/privacy. If this is a google-ecosystem only feature, I'd kind of like to put on my doom-sayer hat and claim that this smells a bit like the death of XMPP; While technically still email (and currently integrated with the rest of the world), google is in a rather dominant market position (~15% of domains, iirc), and such individual-actor product decissions may actually send quiet some ripples through the email ecosystem as a whole (Why didn't you RSVP? I send you an RSVP request from my gmail?!). (Not saying that email's UX can be a tad dusty... but changes like this might really benefit from a really concious engagement with the potential implications.) So, apart from my rather centralization-critical gut reaction... what do you think about features like this being added by individual ESPs and its impact on how email will develop? With best regards, Tobias [1] https://support.google.com/a/answer/9709409?hl=en ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail Dynamic Email / Impact on Email Ecosystem
Heho, > Brandon Long via mailop > https://developers.google.com/gmail/ampemail is the Google developer > information about dynamic email, that link was about controlling the > content with Google Workspace. Thanks for sharing, this has some rather interesting examples. Do I need to be specially vetted to send AMP email, or could I--as long as it is compliant to the standard--send one myself, i.e., without being a registered newsletter sender? The AMP page is somewhat unclear there. > Brandon Long via mailop > The standardization is via AMP, docs at https://amp.dev/about/email/ > and a pretty short list of other providers who support it. I acknowledge that mail's UX is currently 'fresh and outstanding' and something will have to change. Still, change is naturally driven by those who do, which--in this case--is the group of organizations around AMP. However, I'd argue that changes will be aligned with the needs of these organizations in terms of providing consistent services to their customer base under their business model [1], which naturally inflicts on how these systems are being designed. This also inflicts on the governance of venues for organizing and coordinating such changes, as for example AMP, implementing a model that allows decision making to follow operational needs [2]. And, to be clear, I am not claiming that this is a google-specific thing, or try to pick on google, but instead argue that any rational actor with that scale of operations will ultimately operate in this way to match its objectives. > Brandon Long via mailop > The death of email will come from outside the eco-system, not from > individual attempts to extend it. I wouldn't necessarily call AMP an individual attempt, given the market share of some of the involved parties. Also, I was referring to the death of XMPP. If I remember correctly, XMPP's rise and fall actually started with major players [3,4] committing to XMPP federation. However, over time, and with needs, roadmaps, and available features in clients diverging more and more, federation was discontinued by Facebook and Google [5]. At this point, the role of others being less sharing and more consuming--Page explicitly calling out Microsoft here [6]--certainly should also be mentioned. What ultimately broke the neck of XMPP was then its ill suitedness to the evolving User Experience on smartphones. With its complicated protocol, and federation needs--the classical finding others problem--it was simply no match for centralized services using simple but usable identifiers (phone numbers), even if they may have been using XMPP 'under the hood'. That then is what gave us the current zoo of messengers we all love and like (if someone wants to further discuss this point, please feel free to write me on What'sApp, Signal, Telegram, Threema, Facebook Messenger, Skype, Skype4Bussiness/Lync, Google Meet, reddit, or via netcat on tcp/2342). So, in the end, the dynamics around new features adopted by a few players representing a major subset of the ecosystem can have a long-lasting impact that may ultimately interact with, e.g., the deliverability discussions we regularly have. (Most recently, tightened SPF requirements by Google, and I am not claiming that _that_ move was necessarily a bad one; But one with consequences to consider that are not strictly technical in nature, but cross influence technology, i.e., in this case, mail.) With best regards, Tobias [1] https://doing-stupid-things.as59645.net/burning/world/resillience/2022/06/30/propositions-part-4.html [2] Page 78, Sec. VII.E.6, Point 206 ff https://www.texasattorneygeneral.gov/sites/default/files/images/admin/2020/Press/20201216%20COMPLAINT_REDACTED.pdf [3] https://googletalk.blogspot.com/2006/01/xmpp-federation.html [4] https://www.facebook.com/notes/10160197317616729/ [5] https://blogs.fsfe.org/hugo/2013/05/google-talk-discontinued-will-google-keep-its-promise-and-give-xmpp-users-a-way-out/ [6] https://www.theverge.com/2013/5/15/4334242/larry-page-to-tech-world-being-negative-is-not-how-we-make-progress ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Research project on SPF validation: Is your server violating RFC standards for SPF resolution?
Heho, As the question of 'how many SPF related DNS requests is your server supposed to send' recently came up, I figured it might be interesting to share the following research project with you, for which we are looking for participants in our tests and also feedback on the tooling we build. The project is led by Md. Ishtiaq Ashiq, a PhD student at Virgina Tech looking into various aspects of the email ecosystem supervised by Tijay. Our team would like to understand how the SMTP servers out in the wild verify SPF records. While doing so, we noticed that quite a few SMTP servers may allow an attacker to launch a denial-of-service attack using SPF referrals. An attacker may use an infinite number of SPF referrals in their SPF setting and can send an email to a vulnerable mail server which would make the SMTP server make a whole lot of DNS queries. By exploiting this vulnerability, an attacker can block the SMTP queue of the server, flood the associated recursive resolver, or any DNS authoritative server. According to RFC recommendations (https://datatracker.ietf.org/doc/html/rfc7208#section-4.6), a few DNS lookup limits exist that an SMTP server needs to maintain while resolving an SPF record. That is, SPF implementations MUST limit the total number of DNS queries to 10 and the number of void lookups to 2 to avoid unreasonable load on the DNS. To measure more SMTP servers’ behavior, we setup a test website where you can get a report of your own MX and contribute to our dataset: https://spf.net-measurement.net/ You can provide your email address here, allow us to send a test email, and queries that your server made for resolving the SPF record of the sender will be shown. Please find more details about the vulnerability, our SPF referral policy, and the data we store at the given URL. We will only store the recipients MX’ FQDN and behavior regarding RFC7208. The site is still in the early phase. So, if you do encounter any bugs or errors, please let us know! We would highly appreciate your participation, and discussion on this configuration issue. Specifically, we would like to know more about your setups of your MXes are not following the limits of RFC7208, specifically if this comes from software defaults or might even have been a conscious choice. We are also preparing a survey on SPF behavior, which we will share shortly. With best regards, Md. Ishtiaq Ashiq (iash...@vt.edu), Tobias Fiebig (tfie...@mpi-inf.mpg.de / tob...@fiebig.nl) Taejoong "Tijay" Chung (ti...@vt.edu) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Research project on SPF validation: Is your server violating RFC standards for SPF resolution?
Heho, > The rspamd default is 30. I'd say it works better that way in practice, > because people do make mistakes and vendors do modify the records customers > include. Did you encounter such issues in practice and/or were you involved in the discussion forming that default? If so, it would be nice to get some more perspective on that. With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Research project on SPF validation: Is your server violating RFC standards for SPF resolution?
Heho, Ok, thanks, that clarifies that. :-) With best regards, Tobias -Original Message- From: mailop On Behalf Of Taavi Eomäe via mailop Sent: Thursday, 25 August 2022 14:32 To: mailop@mailop.org Subject: Re: [mailop] Research project on SPF validation: Is your server violating RFC standards for SPF resolution? > Did you encounter such issues in practice and/or were you involved in the > discussion forming that default? If so, it would be nice to get some more > perspective on that. We see SPF records that exceed the standard's query limit fairly often, but weren't involved in the forming of rspamd's default. We can say with fairly good confidence that it's simply more robust¹ to tolerate records that are slightly incorrect, and more "fair" not to punish the sender instantly. (Considering all the poorly configured domains out there that don't have any SPF at all.) [1]: https://en.wikipedia.org/wiki/Robustness_principle ___ 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] Research project on SPF validation: Is your server violating RFC standards for SPF resolution?
Heho, Thank you all for your feedback, and especially to Simon for pointing out the issue in February. This should, of course, not happen, and is part of the reason why we are moving this to strict opt-in measurements. I discussed your points with the project lead (Taejoong “tijay” Chung ), who asked me to share his message below with the list. With best regards, Tobias Dear Simon Arlott and community members, This is Tijay Chung (Virginia Tech), who is the principal investigator in this project. Since my list registration request has not been processed yet, I've asked my colleague, Tobias–who joined the team for this project as a collaborator in June-to share this post. First of all, I would like to thank you all for your feedback. We certainly did not apply proper care in executing this project, and will make sure that our future actions are not as intrusive as our past measurements. Furthermore, we do agree that the RFC should be amended; After all, part of our research question is finding out what a reasonable limit and recommendation would be. Also, I want to sincerely apologize for the incident that happened in February. Back then, we sent out emails for randomly chosen domains with the description of who we are and why we are doing this, and the link for the webpage for further details (the email that Simon attached; And we–by now–understood that this is not the right way of measuring such an issue.). In the excitement of kicking of this project, we missed a flaw in our implementation. We had planned to limit the number of maximum SPF queries to around 300, but our implementation of the algorithm that generates SPF recursion trees kept creating more nodes. Thankfully, some email administrators reported this flaw. As soon as we received the reports, we immediately shut it down and applied a patch ensuring we only serve 300 SPF records per mail at most. We now understand that we should have applied more care in setting up our measurement infrastructure, and should have followed a voluntary participation approach properly informing participants about the risks of the experiments as we now try to do with the self-measurement website. Furthermore, we also shifted towards a structured analysis of various SMTP server and SPF plugin/SPAM filter combinations to get a less intrusive picture of the problem space. Similarly, we are using passive DNS data to get a better picture of the practical needs in terms of the number of DNS lookups needed for SPF used in production. Of course we will share these results with the community as soon as we have compiled a report. Regarding the website, we have received valuable feedback such as adding a functionality for participants to keep track of their SPF requests history, and providing a form of double-opt-in to ensure people actually control the email addresses requesting a test-mail. We are shutting the website down for a moment to implement them. I would like to apologize again for what happened and thank you so much for the valuable feedback. Sincerely, Taejoong “Tijay” Chung. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Research project on SPF validation: Is your server violating RFC standards for SPF resolution?
Hello Bill, > I refuse to participate in your research, as all evidence I have is that VT > is grossly unethical and allows incompetents to run research projects. I hear your frustration with this, and will not defend the measurements that took place in February. As outlined below, we will work on limiting our measurements to people that clearly opted in, and would appreciate feedback on that. > So, are you REALLY opt-in? Holw do you authenticate that? Trusting what a > stranger types on a web page? > > That would be yet another abusive and incompoetent study design. Only trusting the address entered would be single-opt-in, and--as you note--insufficient. Instead, my current plan would be the following: - Enter email on website; - Receive a results URL with a random identifier - On that page, be requested to send an email from the entered email to 'opt-in@...'; Should be a) SPF compliant and b) Validly DKIM signed. - If an authenticated mail is received, we send a measurement email in reply and start to display the results - If an insufficiently authenticated mail is received we only display 'An opt-in message was received but failed SPF/DKIM/both authentication.' on the page without sending an email. The main issue I see with that design atm is that it allows any user behind an MTA to opt-in the whole setup; What might make more sense is restricting this to selected from addresses (postmaster@?). I would appreciate opinions on this. With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Research project on SPF validation: Is your server violating RFC standards for SPF resolution?
Hello John, > If it's opt-in, please identify all of the IPs that send mail or DNS or web > queries so those of us who have not opted in can block them. I just started going through the setup built at VT and found several points where there will have to be some serious re-design of several components. As soon as that is done, we will: a) Post a list of all components on the website, indicating what exactly can be blocked to make sure to not receive any unwanted packets from us. b) Provide that list of addresses and domains to mailop@ before setting the service available again. c) Provide an additional form to submit address ranges for exclusion from the study on the website. d) Implement the opt-in mechanism outlined in my previous reply to Bill. If you see anything else we could do to make this safer, please let me know. With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] OpenSSL Vulnerability and SMTP
Heho, Just as a side note/PSA in case people missed this; While the Internet is moving towards a 'well, that OpenSSL bug was not t bad; It would need either a malicious server with a _signed_ cert (or cert checks being disabled), OR a malicious client and the use of cert-auth' perspective... MTAs usually do a lot of outbound TLS acting as clients to remote servers, but opportunistically (disabled cert validation). This might also be triggered by a remote entity directing an MTA to a specific server (think: Using bounces, DMARC/TLS RPT). ;-) So mail might be one of the few cases where the OpenSSL bug is relevant (even though not many run their MTAs on Ubuntu 22.04 or similar, I guess; Docker world might be different, no clue what mailcow is doing). With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] OpenSSL Vulnerability and SMTP
Heho, Yes, the one Christof posted; I was somehow expecting everyone had gotten those notifications over the past weeks. Referring to the Malwaretech blog, making exactly my point: "Likelihood of exploitation Give the fact the vulnerability is primarily client-side, requires the malicious certificate to be signed by a trusted CA (or the user to ignore the warning), and is complex to exploit, I estimate a low chance of seeing in-the-wild exploitation." With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] tls certificates
Heho, I looked at that recently; See the SMTP paper recently published [1], and enforcing TLS certainly is indeed on the rise, and at least one of the privacy mail providers at least allowed their users to opt-in to TLS-Only sending for their mails. We are currently also setting up a website to run our tests against one's own ESP/Setup (without me having to dig results out of the logs ;-)), which I'll hopefully be able to share soonish. With best regards, Tobias [1] https://www.usenix.org/system/files/atc22-holzbauer.pdf -Original Message- From: mailop On Behalf Of Slavko via mailop Sent: Wednesday, 23 November 2022 00:13 To: mailop@mailop.org Subject: Re: [mailop] tls certificates Dňa 22. novembra 2022 21:00:36 UTC používateľ "Gellner, Oliver via mailop" napísal: >Also the number of MTAs that require STARTTLS is not increasing based on my >experIence. I haven’t seen a large ESP which enforced TLS for all incoming and >outgoing connections yet. Are you aware that even change from 1 to 2 means grow? I didn't write if requiring TLS is in most of servers, nor that is required by a lot of servers, but i see grow in logs (over time), where host try STARTTLS and when it fails, they go away without fallback to plain. I inspect them mostly only by checking its hostname, and as they are not "important" for me, i mostly ignore them. But i remember one from DE, which was "important" and required exception from my side. regards -- Slavko https://www.slavino.sk/ ___ 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] SPF (and other email security protocols) Survey
Heho, (Excuse the footnotes; But there is a lot of tangential stuff worth mentioning, but not necessarily core to the thread.) Let me weigh in here and provide some context as Tijay listed me as a collaborator, and he seems to be a bit delayed in replies. Tijay is a Professor at VT, and works on a variety of topics at the intersection of security and measurement. This means that he usually supervises students in pursuit of their PhD*. One of the areas a PhD student currently works on is SPF. This started with them prodding around and finding that a) The _defined_ limits for SPF lookups seem to be impractical (using Bulk ESPs, Salesforce here, marketing there,... lots of includes), and b) Some SPF implementations are really not good at dealing with _very_ deep SPF trees. This is, for better or worse, how ideas for research papers usually come together in this specific field of research**. So, what is this research about now: The group found that odd behavior, and what you usually do then first is do some measurements. That didn't go to well, and shut off a couple of mailserver***, and they are currently working really hard at getting that measurement setup robust and in line; I am helping there a bit, as we built a similar setup for our mail-delivery scans (even though that does no potentially intrusive things, which makes stuff a lot easier in terms of consent etc.). Anyway, apart from that, to get a scientific exploration of the topic, the question also is _why_ did this problem occur in the first place. Hence, there is now a survey which asks people (broadly) a) how they are implementing SPF/DMARC/TLS-RPT in their setup (software, limits), b) demographics about their setup [number of users, domains etc.], and whether they are aware of the (TBH, obviously outdated) limits from the standards. The survey does not contain mandatory fields, and tells people what to expect and that they can quit at any time, and can of course also have their incomplete replies (or complete replies if they change their mind later on!) deleted.* I think Laura also explained _very_ well why this is not 'human subject research'; I still see the issue there in terms of the IRB terminology (which is often even prescribed in that unhandy way; And IRBs also usually have 'limited experience and knowledge' when it comes to 'Internet things', especially network measurements; But for that, see **.) For the survey and measurements combined, the idea is to then have empirical data on how things are implemented (network measurements, even though there is ongoing debate on how usable those earlier measurements are in a scientific sense), _why_ they are implemented that way (technical level; part about tools and implementations in the survey), and _if_ and _how_ best practices/RFCs should be amended to capture the actual needs of the email ecosystem (second part of the survey). That together then can form a publication on the observed challenges in SPF/DMARC reporting. As such, the survey is for everyone involved in Email; There is no harm to [the research], if you are not sure if the survey is for you and you agree to participate, go through the survey and see if you'd be able to provide meaningful input on the questions. If there are further questions, or you want to further discuss individual points, please let me know. With best regards, Tobias * This is also the reason why I'd argue that it might be somewhat good if the communication style with researchers tries to keep in mind that, in the end, there is a human on the other side. People tend to make rather strong and frustratedly sounding statements from time to time, but these might be ultimately read by a PhD student, i.e., a very junior person. A bit of kindness can go a long way in communication, and for me personally is also an important point of being an engineer. ** We can have an awful lot of discussions about this, and there is a lot going on; Besides the obvious 'is it good or not' and 'is this really science?', we essentially deal with 'science' with all its incentives (publish or perish); This means trying to do research on Internet protocols that have been around for longer than the combined age of the PI and PhD in many cases; PhDs fall out of their masters before getting into such a topic, and then essentially have a year to know all the ins and out of a protocol that grew over the past 40 years... because after the first year they _should_ basically have their first paper under submission. Certainly people that haven't run their own mailserver/authNSes for more than a decade. Yes, recipe for disaster. Currently, I am actually looking into building an 'AS for Measurement Research', especially 'higher level protocols' (mail, DNS,... ) that is open to researchers; That should a) have its own ASN, /47, /23, and delegated zones, so people can _really_ easily block/filter it, b) Maintain a global opt-
Re: [mailop] SPF (and other email security protocols) Survey
Hey Bill, > Do you know why his students have at least twice in the past engaged in > deceptive spamming to gather data? Yes, I do, see Footnote ** of my previous mail; But to recap: It is a complex problem between how academia is setup, what it incentivizes, what it requires, what it rewards, and who does network measurement research (usually people without operational experience working on things technically too big for a single PhD). You can, of course, now simply tie that to Tijay, who at least starts to engage with the issue now, and tries to be part of a solution instead of the problem; Then again, as I said, it is a wider problem, and there surely is a ton more science-y-groups that are doing similar things, but simply did not pop up on your radar yet. I for one personally prefer working on fixing the underlying problem instead of keeping beating on a person that is actually developing awareness of the issue. Because academia will not go away. PhDs doing research won't. So,... well. Let's fix things instead. > Frankly, there's no chance that I'll ever cooperate with that person's > research. This is fine. Your choice, and also the reason I am trying to build one stable AS for that kind of research, so people can easily enforce never being involved on multiple network layers, without running the risk of, e.g., blocking IPs that are later used by a different entity (when using stuff like EC2, for example). Similarly, that's the reason why such an entity should have a board checking planned research that actually involves non-academics. In the end, well done research can be really beneficial (e.g., by figuring out changes to RFCs); It just MUST not cause harm, and that harm is often not apparent, certainly not to people usually found in IRBs, and often not even for people that are not actively involved in that _specific_ type of system (Say, DNSOP assessing Mail measurements, or MAILOP commenting on some BGP experiments, even though, of course, there are community overlaps). > His tenure should be pulled. He has a pattern demonstrating ignorance of his > field of study. This is not fine; At least in my personal opinion. It is essentially what I talked about in my previous mail when referring to rather frustrated comments that do not necessarily take into account that the person on the other end of the communication is also a, well, person. Furthermore, it--again--does not really help in mitigating the underlying problem, which is a bit bigger than just one person doing research, but instead may even make it worse. I would usually have this discussion off-list, but given that you posted this to the list as well, it might be worthwhile to talk about it somewhat openly, as it relates to how we want to interact with each other here. The reason I believe that comment is not fine is that it rather directly attacks Tijay as a person, without considering the context of events. Your earlier statements in that context were even a bit stronger. In any case, this is certainly not in line with how I would expect a rather senior engineer to communicate, especially given that this message may also be read by more junior people directly. In the end, we are all shaping the tone in the community. Specifically, your call for revoking tenure is relatively close to "make that person lose their job and prevent them from ever working in that field again". This is usually done when people demonstrate significant neglect of ethical standards and practices in their _academic field_.* The problem here, though, as I mentioned above are those standards and practices (or rather: Especially the incentive structures and requirements) in the field, which are just incompatible with how the Internet works (and this issue is certainly not restricted to mail). So, you are basically putting a lot of (kind of justified) frustration at academic research at large into comments towards a single person. Furthermore, when I think about the impact of one of the measurement studies (crashing MXes of smaller ops running off-the-shelf frameworks), I cannot shake off the feeling that a reply to one of those operators posting to mailop asking for help with the issue (without the measurements having been tied to Tijay) could very well have been: "Ah, yeah. Unethical scans. But you should have figured that out by yourself. Maybe, if you can't debug something that simple, and figure out how to block it, you shouldn't be running mail-servers on the Internet. *shrug*" Which, I think, illustrates the point about tone I hinted at earlier a bit more. Instead, I would expect clear, yet respectful, communication that takes the underlying problem into account and works towards a solution, making sure that the problem does not occur again in the future, independent from the people involved, while the people involved are allowed to grow. But that may just be me. With best regards, Tobias * Note
Re: [mailop] SPF (and other email security protocols) Survey
Hello John, > So if they were competemnt and ethical, tney would stop and find people to > work with who understand the issues so they can do research that is not > abusive and could have useful results. Unfortunately, as we have seen, they > are neither. I personally believe (and sincerely hope that my believes are not disappointed here) that this stopping, reflecting, and improving is currently taking place, and has been for some time, as signified by no new mail measurements I know of having hit the world from the group so far. > Having spent my entire life in and around academia, I have no sympathy for > people who say that since we are so nice and our goals are virtuous it > excuses the stuff we are doing. No, it does not. You are attacking a strawman here, one where I obviously (and usually quiet aggressively) agree with your point. My argument was that it is hardly possible to gain a sufficient understanding of many protocols to be able to thoroughly design network measurements while accounting for all possible harms within the time available for a PhD. That is just as much a recipe for disaster as it is a practical reality for many people out there; Start your PhD, do four papers in four years, and have your first one submitted by the end of year 1. Learning by doing, breaking too much in the meantime, which is not a desirable state of affairs, especially given that with the standard-academia-workload no PI will be able to thoroughly vet what their students built. To still be able to make a positive difference, I started my current efforts to build something to curb this issue; Because no matter if one extends sympathies to people doing harm out of ignorance (no matter whether you see the cause for that in an underlying system or not), the truth is also that those measurements will keep hitting the Internet. I might have a bit too much of an idealistic world view here, but I believe established infrastructure which provides proper feedback from more experienced people before packets hit the fan (to which one can also point people to if they make mistakes) can really make a positive difference here, especially if people who really know what they are doing are willing to look at things before they are let out on the Internet. Talking of which: John, would you be willing to be part of something like that? I mean, it will probably take quiet some time until I have this going, so this would be a commitment for an undetermined future point in time (mostly due to me not having a /23 v4 spare for the project; But I am working on it. And of course then there is the adoption thing.)... But I believe your eyes in such a project might actually allow quiet a lot of students to learn a lot. With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF (and other email security protocols) Survey
Heho, > Please, give us the IP ranges these clowns are using so we can block all > traffic from them. Not sure which 'clowns' you refer to; If this is about the sum of researchers under the mechanics of current academia which might release crappy measurements to the public, I sadly lack such a list; If I manage to get the circus^Wmeasurement AS going I will certainly share the prefixes (and ASN) for people to block. After all, that is part of its point. If you are referring to Tijay: Stuff is being built on EC2, and I leave it to Tijay if he already wants to share the IPs; However, as long as I can and want to give some input on that project, that SPF measurement setup will not originate any measurements until some issues are resolved. So, I am not sure how much of a point is in that at the moment, especially as those addresses may still change. If and when those issues are resolved whatever IPs it will be running from will be first communicated, with enough time for people to take measures. With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF (and other email security protocols) Survey
Hello Andrew > If VT PhD students don't have the experience needed in the topics they study, > then shouldn't VT change either the students or the topics ? As I said, this is not about specific instances, people, or VT in particular. It is more of an observation that while in 1988, you could go through RFC1031-1035 and have a rather complete overview of DNS (picked as an example here). That changed since then, not only for DNS; Mail, TCP,... they all grew. A lot. At the same time--sticking with DNS here--countless ways of 'holding it wrong' emerged in practice, far beyond RFC1537 and RFC1912. And to do proper measurements (in terms of 'not unethical' and imho also in terms of 'actually reliable') you MUST know all of this. When I look at the people with whom I graduated my master, who went on to work on DNS implementations: They spent _at least_ as much (likely more) time on DNS alone as I did on my whole PhD. And a PhD comes with a lot of other things added to it (teaching, funding, different topics); It is more like a mixed bag of beans. And still they will _always_ know more about DNS than me. Which brings us to the academic-philosophical point: Technically, I would expect a PhD to be exactly about that: Having the time to _really_ dig into something, getting to the bottom of it, and making meaningful contributions to the state of knowledge; if it takes five years, a decade, or more. But then again, as said earlier in this thread, I tend to be a bit (too) idealistic. Nevertheless, from your message, I believe that we actually agree on this. Closing the loop: Academia has grown into an output focused, measured, and managed ecosystem in many places*. People have 4 (EU) to 6 (US-ish) Years for a PhD, with an expectations of 3-5 papers in well regarded venues. There is simply not the time for engaging sufficiently deeply with many technologies, and--throwing another punch here--I think many CS BSc/MSC programs also do not necessarily provide the right foundation for that. Teaching is another chore many faculty run through, while all things fall of different corners of the plate at the same time (and far too often faculty members' mental health as well; Burnout in academia is a thing). And to circle back to on-topic: The result of that is what then pops up in /var/log/maillog. So it isn't about 'should VT change [something]'; It is more 'shouldn't society change the incentive structure and general setup around academia as a whole'? I have quite some opinions there, boiling down to the answers 'yes' (and suspect most here will agree with that). But that is not really in my power; So I try to do what I can instead (channeling results of the system into a more manageable frame, while trying to teach those students I directly work with at the institution I am at). In any case, I believe that harsh words when something (predictably and repeatedly) goes wrong with that system in place will not bring us closer to a solution. With best regards, Tobias *I am not really planning to make a full argument on why I believe that this approach is really detrimental to the acquisition of knowledge and education of students; It is beyond the scope of this ML, and I assume I'd be preaching to the choir. If you are more interested in this, I can recommend a (somewhat recent) measurement study of mine into/tangential to the topic; The discussion actually touches on some of these points, and provides good pointers to further work on it: https://arxiv.org/abs/2104.09462 ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] t-online.de
Heho, > they mean that you must have an webpage(imprint) (on your mail-domain (fqdn > or domain itself)) with contact information (name, postal address, email, > probably phone number). I personally have the feeling that that got a bit more relaxed over time; At least the last two times I interacted with them a missing imprint was not an issue; Then again, that may also be somewhat dependent on the IP space you come from. I guess it is mostly a thing bound to the choices of the postmaster-on-duty who gets the ticket; In any case, they are usually 24/7 and will also mention if something/what is missing/preventing them from allowlisting. With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] How to delegate DMARC reporting to third-party providers for inbound mails
Heho, As said by Alessandro; You will have to make the tool you are currently using for validating DKIM/SPF -> DMARC generate and send the reports. What works well for me is rspamd [1], but there is also a tool for postfix (iirc; maybe somebody else can weigh in there). Similarly, there should be something for TLS-RPT. What you should keep in mind when setting this up, though, is that you can actually run into rather loop-y behavior if you originate your dmarc reports from a domain that requests reports itself (best practice would be originating from a subdomain not requesting reports; you could also exclude originating reports for that domain, at least with rspamd): - You get a mail - You sent a report - Other party gets a mail (the report) - Other party sends out report (because they got a mail from you) - You get a mail... For my setup, that is something I still plan to fix. :-| With best regards, Tobias [1] https://rspamd.com/doc/modules/dmarc.html ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] OpenDMARC
Heho, On Mon, 2022-12-26 at 21:42 +0200, Mary via mailop wrote: > ... > Are there any alternatives to OpenDMARC and OpenDKIM? I had a lot of good experiences with rspamd; Also, it felt 'easier to hold' to reduce the influx of spam, as you can tighten things selectively; Of course, you can also just use the signing/validation parts and use $something_else for spam filtering. Added bonus: Supports ARC as well, and can send DMARC reports ootb. With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Measurement study on understanding global email configuration quality
Dear all, I am a researcher at TU Delft in the Netherlands, looking into Network Security, Protocol Adoption and human factors. My student Olamide is looking into how well _sending_ email setups are maintained around the globe. For this, we need many people, ideally from 'smaller' providers, i.e., with non gmail/hotmail/yahoo addresses, to send us emails. Please consider participating in this study, and sharing it in your networks. To help us, please follow the instructions at: https://www.email-security-scans.org/ Important caveat: If your mailer validates recipient addresses before accepting mails for delivery, you might be unable to send to destination addresses that are (a) only resolvable via IPv6 only, or (b) Have broken DNSSEC, which we use to test DNSSEC validation. If this is the case, please just remove the 1-3 offending addresses from the To: header. Please also note that our test setups will test whether the host delivering mails to us is an open relay. Also note that you may receive bounces from your mailserver for some of the destination addresses, e.g., if mails cannot be delivered via IPv6, or if your mail-setup validates DANE records for our DANE test domain. We do _not_ need a copy of those bounces. In case you want to get results for a domain you operate or use early, please just drop me an email from the same domain and delivering servers after you participated, and I will share the data with you. :-) Met vriendelijke groet, Dr.-Ing. Tobias Fiebig, Assistant Professor / Universitair Docent Department Engineering Systems and Services Informatie- en Communicatie Technologie (ICT) TU Delft / Dept. ESS Faculty of Technology, Policy and Management (TBM) Building 31 Jaffalaan 5 - room B3.170 2628 BX Delft P.O.Box 5015 2600 GA Delft, The Netherlands T +31 (0)15 27 85700 E t.fie...@tudelft.nl Present: Monday t/m Friday ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] Mail Sending Self-Test Platform
Heho, after our paper on mail sending configurations some time ago [1], we now glued that together into a self-service site: https://email-security-scans.org/ I'd be happy to hear your feedback, especially if things do not work as expected (then, your test ID and ideally stored emails would be really helpful, so i can double check what went wrong). More details below (also see [2] for an overview of the tests we run). Please note that setting up the tests (as we have to configure vhosts for some MTA-STS cases etc.) takes some time on our site. The test-site should periodically reload and provide the status. As we use JS for that part, please reload it manually every few minutes if you block JS. I would also be interested to hear what you think should be included in addition to the current tests; Some of our plans for the future below as well. We already found some interesting bits, like Vultr having lame v6 delegation for their AuthNS servers' domain, making their domain and rDNS non v6-resolvable [3], or mail-in-a-box using relaxed/simple for DKIM, which breaks signature validity on long To: headers [4]. If you want me to block certain domains/IPv(4|6) ranges or ASes for the service to keep your users from using it, please let me know and i will implement it asap. # Overview The site tests a variety of parameters about mail sending (details: [2]), by evaluating mails a user sends us in reply to a message that can be requested on the site. Simply requesting a message on the site does not start any evaluation or measurements, i.e., you have to send a reply-all to a requested message to start the evaluation. After the test, you can also delete the test or download a copy of your data, and if you opted to do so, a copy of the emails as we received them. # Method Users send emails to us (in reply-all to a message we sent, for easier usability).Target MXes on our site are either configured in a fully RFC compliant way, or intentionally misconfigured in a common way (broken DNSSEC for the domain, for example, or a broken DANE record, again, see [2] for an overview). Thereby, we can determine the configuration/support of features by the senders' MXes. # Possible Harm The worst thing that should happen to mail operators is finding specific undeliverable mails (broken DNSSEC if DNSSEC is validated, v6 only DNS if no IPv6 DNS resolution is supported) in their mail queue, or users receiving bounces (see FAQ on the page). So far the system has been tested with several hundred mail-setups, without encountering issues. If you encounter other unintended side-effects, please reach out to ab...@email-security-scans.org or me directly off-list. # Test details Specifically, we are testing: - v4 Mail sending - v6 Mail sending - Greylisting support - Transport encryption (Plaintext/TLS cipher strength and version support, opportunistic encryption) - DANE support outbound, i.e., if you honor DANE - MTA-STS support outbound, i.e., if you honor MTA-STS (incl. whether you prefer DANE over MTA-STS, as it should be) - Sending of TLS reports and whether these are standard compliant, also providing a copy of the received report (Google's are not perfect, btw. ;-)) - DNS resolvers used by the mailserver - Whether the mailers' DNS servers resolve via IPv6 - Whether the mailers' DNS servers validate DNSSEC - If all names relevant for email delivery resolve via IPv6 - If all names relevant for email delivery are DNSSEC signed - Mailer-basics (ehlo=rdns=fcrdns), SPF (from/envelope) - SPF policy size (by retrieving your policy, up to 20 referrals deep) - DKIM (also checking key-sizes, algorithm mismatches and canonicalization issues; These are surprisingly common, i.e., simple being set breaking only in cases not caught by standard dkim testers) - DMARC (policy validity, conformance of sent mails, displaying implicit defaults) - DMARC report deliverability by sending one(1) valid DMARC report for a received email, including authorization of out-of-domain RUA/RUF (also providing a copy of any bounces received) - Full IPv6 readiness (join over three previous IPv6 tests) - Whether any headers that should not be duplicated are duplicated - Whether any mandatory headers are missing - If From/Envelope match # Planned tests - evaluate outbound spam filtering - evaluate received_from stripping - test for inbound-link parsers - cluster by provider (via MTA sets), not domain - Add DANE checks for senders' MXes - test for host-addresses in SPF prefixes - add MTA-STS check for senders' domains - add test for handling more than 5 MX with only the lowest-prio one(s) being reachable - requesting-domains' MX aspects (null MX, IPv4/6 addr in MX record, non-reachable MX, broken MTA-STS/TLSA, broken DNSSEC, validation of our setups SPF/DKIM (via DNS server logs, v6 resolvability), etc.). With best regards, Tobias [1] https://www.usenix.org/system/files/atc22-holzbauer.pdf [2] https://www.email-security-scans.org/description.php [3
Re: [mailop] Mail Sending Self-Test Platform
Heho, > The inevitable questions about how bad the issues are. I.e. what > could happen?: > - My ip4 and ip6 reverse DNS records are not DNSSEC-signed. I could > ask my hosting provider if they can sign them. Could there be a > reason not to? > - I'm not DKIM-signing the MIME-Version header (marked as minor > issue). Well, as long as your mail gets delivered, it is not to bad, is it? ;-) More seriously; The indicators are more like "should improve" (stop- shield), "could improve" (road-block), and "fun-fact" (light bulb on 'ok'). Nobody will die (or rather: Have their mails not delivered) if your rDNS is not DNSSEC signed. But in an ideal world it should be. Naturally, non-fcrDNS is a lot worse than that; But then again, you should be able to interpret that when running a mail-server. ;-) For DKIM, btw, i got poked re: my rather RFC4871-ish interpretation; I revisited that to now only add a note (small light-bulb) if some headers in the 'think about doing it depending on your use-case'-frame introduced with RFC6376 are unsigned, while not signing From: now triggers a "should improve". > I'm happy to see my ed25519 dkim signatures are accepted by someone. > (: Fun story how the setup got to that, actually... during testing a tester had an RSA key marked as ed25519 in DNS, while signing with an actual ed25519 key; Lead to a lot more fine-grained evaluation in the tool, incl. plausibility checks for pubkeys in the DNS. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mail Sending Self-Test Platform
Heho, > Looks like an useful utility for testing these things out live. Thanks! > One thing though, the EHLO and rDNS comparison is case-sensitive, > there should really be no need? No, there indeed isn't; Thanks, good catch! Already patched and will deploy in a bit (some more bugs to address from other messages). With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mail Sending Self-Test Platform
Heho, > Thanks for this. I tried it a few days ago (I think because you > posted it to opensmtpd-misc? :-) Yeah, also shared it there, hoping for more motivation to implement DANE/MTA-STS in OpenSMTPd. Next escalation step is releasing code i wrote for other projects and threatening to send patches. ;-P > and without doing anything my ‘score’ went from 7 to 8 since I last > checked! At this rate I expect a 10 by Friday. Unlikely ;-) But i got more lenient with DKIM headers, which might have improved your score. > Is DNSSEC-signing PTR records common? Will it affect delivery in > practice? I doubt that it affects deliverability in any way (if, at all, negatively, if DNSSEC breaks... which... well.) The test mostly works from a 'perfect world' perspective, and there, of course, everything DNS would be DNSSEC signed. ;-) > One confusing UI thing: under ‘DMARC’, the ‘(default)’ is either > in error or its meaning unclear: > > adkim s (default) (plain-text; OPTIONAL; default is "r".) > … > aspf s (default) (plain-text; OPTIONAL; default is "r".) > … > fo 1 (default) … (plain-text; OPTIONAL; default is > "0"). Thanks for catching that; Found and fixed. :-) Pushing when i am through all the feedback. With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mail Sending Self-Test Platform
Heho, > For DMARC, there is a parsing bug. My DMARC record consists of three > concatenated strings, which should be joined as usual. The view > shown in the report strips the leading and trailing double quotes, > but not the intermediate ones: > > v=DMARC1; p=none; " "rua=mailto:dmarca...@tana.it; " > "ruf=mailto:dmarcf...@tana.it; > > Only v= is parsed correctly; p=, rua= and ruf= result as unset. Ok, thanks; Identified and fixed. > For DKIM, the test requires 2048 bit keys. RFC 8301 says "Signers > MUST use RSA keys of at least 1024 bits for all keys. Signers SHOULD > use RSA keys of at least 2048 bits." According to RFC 2119, that > means that there may exist valid reasons in particular circumstances > to ignore a particular item, but the full implications must be > understood and carefully weighed before choosing a different course. > As I carefully weighted the decision to use a small key —0 attacks in > several years— I'd have expected an 💡Ok, but watch notes on this. Hm... I see your point. However, I'd go with 'Should improve', kind of sticking with the RFC phrasing here; A (more general) issue, though is the absence of a clear distinction between 'should' level issues, and 'must' level issues (say, missing rDNS alltogether). What should definately be the case is skipping a warning if there is at least one other RSA2048 or ED25519 key. Will fix that. > Also, the diagnostic urges me to sign more header fields. > Specifically, it says "see RFC6376 Sec. 5.4: content-transfer- > encoding:content-type:message-id:mime-version". It is necessary to > sign Content-Type: only if the sender signs a limited amount of the > body, using l=; in that case, altering Content-Type:, a text/plain > message can be turned into the MIME prologue of a multipart message. > Otherwise, signing those fields doesn't add a significant guarantee > of message integrity. Signing /technical/ fields, as opposed to > semantic ones, in my experience irretrievably decrease signature > resilience. That is because most mailing lists and other agents > disregard the original content of such field. For example, I could > not verify fiebig.nl's signature of the message I'm replying to, > whose Content-Transfer-Encoding: was changed to base64, while I > expect to DKIM verify this message. See this draft[*] for the method > to do so. Hrm, good point. I had initially skipped the approach as in RFC6376; Following that now, i moved all non-signed headers to '💡Ok' (except for from: being signed.) I will spend more time on thinking about a good way to address this. > A test I'd like to make, somewhat more intrusive than replying to > all, is about DMARC aggregate report correctness. It would require > domain owners to provide a target address at their domain. The > server would then send a number of messages to that address, some > from a domain with strict DMARC policies, some from a low-reputation > IP, some with an EICAR test attached, some from non-existent From: > domain, and so forth. On the next day, the diagnostic will examine > the DMARC report received, if any, and check its correctness, both > formal and semantic. Fancy it? Would be an awesome idea, and i am noting it down. However, given that there can be a rather strong wind blowing for email measurement setups that originate emails for measurement purposes (i feel the implementation we have now is already a stretch with one potentially unsolicited email being sent), i'll rather skip on that for now. Thanks for the feedback. Will implement the better handling of multiple DKIM signatures and then push. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mail Sending Self-Test Platform
Heho, dmarcv1 is a typo in the description (i correctly check for DMARC1, otherwise this would have shown up earlier); The actual complaint is psd=n; Lemme see if i can make the report more clear re: where it complained. Do you maybe have some context on psd=n? I can't find it in 7489. With best regards, Tobias On Tue, 2023-02-28 at 17:32 -0500, John Levine wrote: > It appears that Tobias Fiebig via mailop said: > > Heho, > > > > after our paper on mail sending configurations some time ago [1], > > we > > now glued that together into a self-service site: > > > > https://email-security-scans.org/ > > > > I'd be happy to hear your feedback, especially if things do not > > work as > > expected (then, your test ID and ideally stored emails would be > > really > > helpful, > > It's complaining that my DMARC record is invalid because it doesn't > start with "v=DKIMv1". What? > > Test ID ttada96061gfwnvbuthbycansr5h34 > > R's, > John -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mail Sending Self-Test Platform
Heho, On Tue, 2023-02-28 at 17:53 -0500, John R Levine wrote: > > dmarcv1 is a typo in the description (i correctly check for DMARC1, > > otherwise this would have shown up earlier); > ?? > er... DKIMv1... -.-' The check checks for v=DMARC1, not DKIMv1 as the description implies; Currently fixing that. > It's in RFC 9091 and in the DMARC update currently in draft form at > the IETF. The intention was always that you could put private > clauses in DMARC records which get ignored by clients that don't > understand them, but the ABNF was overly clever. That's fixed in the > new draft too. Will fix that part asap/tonight; Will let you know if it should behave better. With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mail Sending Self-Test Platform
Heho, > It's in RFC 9091 and in the DMARC update currently in draft form at > the IETF. The intention was always that you could put private > clauses in DMARC records which get ignored by clients that don't > understand them, but the ABNF was overly clever. That's fixed in the > new draft too. Hrm, digging through this; dmarcbis-27 now; Indeed there are some interesting changes; Implementing this will take some time. Also, given key differences in record parsing (esp. the MUST in -27 2nd to last par. of 5.3, vs. SHOULD same place in 6.3 of 7489) might have interesting implications re: behavior in real world systems, esp. when looking at the long tail of 'mail-in-a-docker-ish' setups glued together with curl | sudo bash. I guess what i will do (with a bit more time) is actually implement both interpretations to policy parsing (7489 as written, not as intended vs. dmarcbis-27) with scoring being at one-passing-is-enough. John: Btw, what I am wondering; Given the last par of 6.3 in 7489, shouldn't dmarcbis switch to DMARC2, given that there are changes to existing tags (REQUIRED -> RECOMMENDED for p, removal of pct, rf, and ri), or does that not constitute a change? (Quick thought; Pretty sure there is a mail-thread on the list, though; Will dig through that later.) With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mail Sending Self-Test Platform
Heho, On Tue, 2023-02-28 at 22:21 -0500, John Levine wrote: > We briefly considered that and decided against it because the vast > majority of actual DMARC records will continue to work unchanged, and > long experience says that if you try to change the version number, > you end up living with the old and new versions forever. Yeah; Maybe it's time for an RFC for next month only containing "All IETF created protocols MUST not have a numbered version indicator." (This is (only partially) joking; But i somehow feel like there will never be DKIMv2, STSv2, or TLSRPTv2 ;-)) > Remember that unknown tags are now ignored. In practice pct turned > out to be impossible to implement so most people didn't try. The > required->recommended for p= is to make it consistent with the > _report._dmarc records in section 7.1 of RFC 7489. Hm, yeah, and introduced tags should not be an issue as per 7489 already. Still, i am a bit wondering; Looking at the data flushed in so far (and already multiple bugs filed against implementations)... there are a lot of funny milters and often unmaintained software integrated in funny docker stacks (probably preaching to the choir there, but i have a lot of grievances with those setups), and generally a lot of awry things (example.com. IN TXT "v=spf1 include:example.com -all" is, for example, far more common than i'd have ever believed...). Then again, considering how bad _my_ code usually is... i am not too sure how well many of those libs hold up towards change. Point being, it might be interesting to conduct a structured study into how different implementations in different versions handle DMARC policies with different levels of 'errors' to inform this. I have a colleague who might still have a lab-setup of implementations around, to see if they could quickly do that. With that information, i could then also provide a better score for DMARC parsing, i.e., make a statement on like "current policy would validate in $list_of_common_implementations but not in $hopefully_short_list_of_other_implementations". With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mail Sending Self-Test Platform
Heho, > My system has five mail items still queued, that won't be delivered. > Two because of broken DNSSEC, three because of invalid TLSA records. > (It's report ppk95bat9arnakovq5nmljen4n342u, by the way.) > > The consequences of this in the report could be somewhat confusing. > It says "Not all DANE related emails have been sent; We are lacking > information to analyze DANE support.", and "The DNS resolver your > email provider/server relies on, Mail for DNSSEC enabled DNS > Resolution tests not sent; Cannot assess test. DNSSEC." That sounds > like something is wrong, but there really isn't, if I understand this > correctly; you just don't have the responses that would have told you > that my system sent you something when it shouldn't have. Hrm, this depends on how you sent the emails; What we do to establish if an email to a measurement target address (see detail page) has been sent is check all To: addresses in each email we receive. Technically, all 29 measurement destinations should be in the To: header of all measurement mails. Specific emails not arriving is actually the signal we use to determine, e.g., DNSSEC support. But we added the To: check to distinguish between 'DNSSEC used' and 'specific mail not sent'. You did not check 'store my emails', though, so i cannot check how you did it for your test. I'd suspect something along the lines of 'one mail with one To: per measurement destination'? If you'd like to look into this a bit more, could you maybe run another test, but check the box for 'store my emails'? > (Also, I think maybe that last quote needs rewording - looks like > it's missing one or more words?) Yeah, good catch, fixing in a second. > Further, all the nice little icons on the report page are Unicode > characters, which works fine on Linux, and probably Windows, but on > my workstation, which runs NetBSD, I don't have whatever font that > is, so I just get those little boxes with the Unicode code point > numbers in them. I guess actual graphics would be more portably > rendered. Given the high portion of the measurement setup running on BSD, this is somewhat embarrassing. ;-) I would have expected the specific fonts to be delivered with the site. (UI stuff is somewhat difficult... and "not my core-strength". Will see if something can be done to make this render well on netbsd as well. Which browser are you using? w3m/links(2) with fb rendering or something with a gui? With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mail Sending Self-Test Platform
Heho, > Will do - have been waiting for the web site to send me another mail > for a while, now, but it seems I'll have to leave it until morning. > I'm guessing it's rather busy, with lots of people wanting to try it? Gnah... seems like i got ratelimited at LE's staging environment for (somewhat good) reasons; Hot fixed it for now and will migrate to a self-signed cert later. (It _would_ be cool to have actually valid LE certs to properly test MTA-STS rpt sending; But then again... unlikely). If you try this again tomorrow you have to start a new test, as tests that do not receive a reply within an hour get removed (minimizing data storage etc.) > > It's Firefox. Hrm, will give that a shot later, iirc the fonts should come with the site. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] DKIM tlsrpt Service Tag
Heho, going through results of my measurement setup, i noticed that from three organizations that so far delivered TLS-RPT, exaclty none have the tlsrpt DKIM service type used as SHOULD'ed in RFC8460. Looking at the errata, Errata ID: 5889 notes that this tag was never registered (and indeed wasn't until now), and should be registered either using an additional document only doing the reg either through DISPATCH or an AD sponsored doc; That was ~3y ago. Does anyone know if this just slipped off the table somewhere, or if there was consensus to just skip on the servicetype given it is just 'SHOULD be present' 'MAY ignore' in the RFC (given the observable number of users of TLS-RPT so far, calling it "consensus" might be a stretch, though ;-))? Wondering, because dkimpy at least by default verifies the tag, and i currenlty have this as a 'could improve' rating. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mail Sending Self-Test Platform
Heho, the 'issue' was indeed that you moved the addresses to Cc: instead of To:; Us not checking there is actually somewhat of an oversight. Fixed and pushed. With best regards, Tobias On Thu, 2023-03-02 at 09:13 +0100, Tom Ivar Helbekkmo wrote: > Tobias Fiebig via mailop writes: > > > If you try this again tomorrow you have to start a new test, as > > tests > > that do not receive a reply within an hour get removed (minimizing > > data > > storage etc.) > > I just did - same results, and test ID is > gq7oj8xk44aw452j4e4fzf7vhpu4v3. > > -tih -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mail Sending Self-Test Platform
Hello Mark, > We got a ding on our DNSSEC score, because the PTR record isn't > signed. Is this really as big an issue as the explanatory test makes > out? The tool looks for a perfect world, which there isn't. Un-signed rDNS is not really a bad thing (of course, a hypothetical attacker could temper with your rDNS to make fcrDNS fail to get your mails rejected... but that is erm... "mildly unlikely".) Still, if i'd not deduct points for those things, everyone would get a 10. ;-) > We also got a ding on our MTA-STS record, > but https://esmtp.email/tools/mta-sts/ said the only problem is a > missing CRLF at the end of our txt file; easy enough to fix. This > tool however just said that our system doesn't support MTA-STS. > After I add the CRLF I'll rerun the test; if it still fails, I'll > report back. Actually... you did not get anything for your MTA-STS record, because we're not testing that. You got that for your validation of and adherence to MTA-STS policies when _sending_ mails. I.e.: You don't validate/follow _our_ MTA-STS policy when sending emails. Besides: The CRLF thing is actually a bit funny; The RFC iirc just says 'delimited by', so i am not too sure whether it really must be at the end of the file; And then there is an errata clarifying that you can also delimit with LF instead of CRLF as mentioned in the RFC. With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM tlsrpt Service Tag
On Wed, 2023-03-01 at 22:02 -0500, John Levine via mailop wrote: > In retrospect the service tag was a mistake. It's not widely > implemented, so if you use anything other than s=email you will lose > mail because recipient systems will get confused. The MTAs that > receive mta-sts messages generally have no idea there is supposed > to be something special about those messags. I am still not really sure what to make of it; Based on (the three) TLS-RPT i have seen so far, 'not using s=tlsrpt' is actually the lived practice. With the state of the RFC, i am not even sure whether s=tlsrpt would be valid to set in the first place. With the state of things missing s=tlsrpt should still give a passing score (with note, though, listing this whole situation). What i am not overly sure about is whether it might not make sense to set a 'could improve' if i ever encounter the unicorn of an entity sending TLS-RPT _and_ having that record set. Any suggestions? With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mail Sending Self-Test Platform
Heho, > ...and now it gives me 9 out of 10, acknowledging that my MTA > verifies DNSSEC and honors TLSA records. My own domain (and the sending for email-security-scans.org) scores 9/10 as well; Mostly because OpenSMTPd lacks DANE and MTA-STS validation... and TLS-RPT sending... that is a whole nother beast. > Of course, I'll never get a 10 out of 10. I'll implement TLS > reports, by and by, but MTA-STS will be supported here over my dead > body. :) I share your sentiment. I am not a fan of MTA-STS, and honestly not really sure which problem it solves. > This is the most impressive email testing system I've ever seen. Thanks. The todo is still long, and the code bad. ;-) But i am trying to get it into a robust state; It can be rather surprising how emails look in the wild. Newest find: Bump message storage in the DB from BLOB to LONGBLOB, because apparently there are 167KB(!) bounces these days... size mostly added by the NDR. -.-' With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mail Sending Self-Test Platform
Heho, > If I recall correctly, POSIX says that a line of text is not a line > of text unless it ends in a proper line ending marker. I'm unsure of > the details, here, but I am sure that when, a few years ago, I dug > deeply into this, I concluded that the last line of a UNIX text file > absolutely has to end with an LF for the line to be unequivocally > part of the file. If I read RFC8461 correctly, this is not required for MTA-STS policies: RFC8461, Sec. 3.2. > sts-policy-record= sts-policy-field *WSP >*(sts-policy-term sts-policy-field *WSP) >[sts-policy-term] ;-) With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM tlsrpt Service Tag
On Thu, 2023-03-02 at 14:53 -0500, John Levine via mailop wrote: > In my experience very few DKIM verifiers know what to do with > s=tlsrpt. I wouldn't look for it. Well, the looking code is already there; But given this is essentially a unicorn i am unlikely ever to see, i'll just go with 'Ok' for now. If i ever see one in the wild, i'll metion it here. With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mail Sending Self-Test Platform
Heho, no, i at least make the assumption that the people who get themselves to implement MTA-STS (in either direction) will also have PKIX valid certs. And that group of orgs is relatively small. In contrast, you can, e.g., just enable dane for you N-thousand customers by adding records to _your_ MXes. But, as said some years ago when i first complained about this: I wasn't there to give this input when it was spec'ed; So my complaining now also has _some_ limits. ;-) With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mail Sending Self-Test Platform
Heho, On Fri, 2023-03-03 at 17:02 +0100, Ángel via mailop wrote: > Note you could use a a refresh-every-10-seconds functionality. (meta refresh could be > blocked as well, though) Briefly considered that; However, contrary to JS (which is often ignored by screenreaders) the HTML manual put a warning marker on that in terms of accessibility. So i decided to skip on that. > I was kinda surprised that whitespace was allowed here in javascript, > btw: “window .location.reload();” "ups"; Fix is in staging (along with a better description for reverse DNS being unsigned, making clear that signing that is more in the 'because we can' realm and "some _theoretical_ attacks". Also currently setting up an open v6 only resolver that will be referenced for v6 only resolution. ;-) With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [EXT] - Re: New member, trying to bring our mail server inline.
Heho, > Check that no other filters alter those fields after signing. Can > you sign messages off-line? Do Bcc: copies verify? (Use any off-line > dkim verifier.) You can also give https://email-security-scans.org/ a try and (important!) select "Store my emails so I can download them later." before requesting the test mail. Then, when you click 'Download Data', you get the mbox files of the messages as we received them; You can then try to further debug this with dkimverify locally, i.e., edit the mbox file to change things, run dkimverify, and see if that was what made the sig fail. Of course, even if you store emails, as soon as you click 'Delete Test', they are removed. ;-) With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mail Sending Self-Test Platform
Heho, > Heh, it turns out that actually works, so not a big deal :-) Not tooo sure; There were a lot of timeouting tests which looked like 'did not reload page'; Wouldn't be surprised if _some_ browsers are fine with it, while others aren't. Anyway, for good measure, it's fixed now. ;-) And thanks again for finding it. :-) With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Bell.ca servers disconnecting before 250 OK
On Tue, 2023-03-07 at 14:34 -0500, Bill Cole via mailop wrote: > What is happening in that 125-second gap? Why are *you* timing out > after 125 seconds? To add to Bill's suggestion, given this happens after DATA: Check the (path) MTU. Btw, is there any hypothetical chance that your mailer might be running on a KVM/QEMU virtualized platform and might be using rtl8139 virtual NICs (no offense meant; this is a very wild guess, but from the looks of it, your org. might fit the unlikely arrangement of stars and a full moon that could lead to that.) With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] IP RBLs and large cidr blocks
> Heho, > > I mentioned to Michael -- in a direct email -- that I wonder if > > there is an opportunity to put something in parent DNS zones in the > > .arpa sub-domains, much like DS records for DNSSEC go in parent > > zones, so that an IP provider (or at least naming authority) can > > specify that a range is delegated to another entity. > > Usually this is ONLY done for a /24 or greater by upstream > providers.. (While it can get done for smaller blocks, you end up > with that ugly double PTR record, one from the provider and one from > your DNS server) _This_ is what the IRR system/'rwhois' is for, no? I usually put objects for v4 i delegate into IRR, same for v6; I recall that hetzner also does (used to do?) this for delegated networks in their dedicated server product. At least the RIPEDB comes with an API. ARIN even says explicitly that ISPs only have 7(!) days to submit reassignments of v4/29 v6/56 or shorter to the database. > > I also mentioned that miscreants would be likely to abuse this and > > artificially divide their IP space so that bans on some parts would > > not effect other parts. Hence the need to have a larger addressing > > /naming authority provide this. Yeah, like, the LIRs? (Granted, the bar to become a LIR in RIPE is not that high (and an LLC not that much more difficult to get for the other RIRs; But you can technically nuke bad-faith LIRs from orb... er ASPATH). With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Sometimes I hate Microsoft :)
heho, i actually occasionally get NDRs from them; One of them actually broke parsing for my funny mail measurement setup recently, because it was way in excess of 100kb... and i thought 640kb should be enough for everyone^Wmail. -.-' With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] vrfcanaclu03.rfcanalyzer.net / 2001:470:1f14:fa5::2 / tunnel613353-pt.tunnel.tserv11.ams1.ipv6.he.net
Heho, i am currently looking at a weird set of (reoccurring, but i only have a pcap of one) log events related to an SMTP connect from rDNS tunnel613353-pt.tunnel.tserv11.ams1.ipv6.he.net with v6 IP 2001:470:1f14:fa5::2 ehlo'ing as vrfcanaclu03.rfcanalyzer.net. It has a funny interaction with my network, which lets it descent into a +1.5k PPS / 50mbit+ pmtud exceeded/retransmit storm (which might not entirely be their fault, though...). Still, i'd like to get to the bottom of things, and if this is a benign service, i'd like to get in touch with the people running it. Googling tied rfcanalyzer.net to a measurement system of the Dutch tax authorities' SOC (dropped them a mail already), but given that this is behind HE, i'd be surprised if this was _actually_ them. So, has anyone else seen this in mail.logs/has an idea what that host is doing? With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] vrfcanaclu03.rfcanalyzer.net / 2001:470:1f14:fa5::2 / tunnel613353-pt.tunnel.tserv11.ams1.ipv6.he.net
Heho, yeah, the two versatel addr. also have vrfcanaclu01.rfcanalyzer.net- vrfcanaclu03.rfcanalyzer.net as fDNS. $database yielded a mix of Dutch gov/academia IPs and random ISP stuff under rfcanalyzer.net. For me connections are either the same, or an IO-Error/Worst case the packet storm. However, i just get the v6 inbound. Let's see what their SOC says to this. With best regards, Tobias On Sat, 2023-03-11 at 20:34 -0600, Michael Rathbun via mailop wrote: > On Sun, 12 Mar 2023 02:54:56 +0100, Tobias Fiebig via mailop > wrote: > > > So, has anyone else seen this in mail.logs/has an idea what that > > host > > is doing? > > The connections here attempt STARTTLS, which fails with SSL error > 0x80090331. > > These come from 87.215.108.211 and .212, in .nl. > > This behaviour has been exhibited by a number of other hosts, mostly > originating from OVH netblocks geolocated in .fr. > > mdr -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] vrfcanaclu03.rfcanalyzer.net / 2001:470:1f14:fa5::2 / tunnel613353-pt.tunnel.tserv11.ams1.ipv6.he.net
Heho, ok, just had the confirmation in my inbox that this is a .gov measurement/research project. Will discuss the matter of 'probe attribution' with them. With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] vrfcanaclu03.rfcanalyzer.net / 2001:470:1f14:fa5::2 / tunnel613353-pt.tunnel.tserv11.ams1.ipv6.he.net
Heho, and a quick follow up on the root cause: The HE tunnel host continuously sent packet-to-big messages indicating an MTU of 1480. The packets that triggered the message had an MTU of 1476, so my openbsd just resent those packets as before (honoring RFC8201 by the letter, i.e., reducing the MTU to the value communicated in the ICMP packet; in this case not changing it, triggering the next ICMP message...): When a node receives a Packet Too Big message, it must reduce its estimate of the PMTU for the relevant path, based on the value of the MTU field in the message. The root cause seems to have been a pppoe link on path which dropped the MTU to 1472 effectively, while the tunnel was still configured at 1480. I am not yet sure whether this is a sit/gif implementation issue at HE or a general thing. I will try to reproduce the setup next week, also to test if this is maybe an OpenBSD only thing; Thinking about it, being able to make a system send ~1-3GB as long as you can make it open a tcp connection to you sounds like a rather not so fun thing. With best regards, Tobias On Sun, 2023-03-12 at 12:32 +0100, Tobias Fiebig via mailop wrote: > Heho, > ok, just had the confirmation in my inbox that this is a .gov > measurement/research project. Will discuss the matter of 'probe > attribution' with them. > > With best regards, > Tobias > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Tightening of delivery rules for Exchange Online
Heho, i just had this scrolling by: https://techcommunity.microsoft.com/t5/exchange-team-blog/throttling-and-blocking-email-from-persistently-vulnerable/ba-p/3762078 As i read that, microsoft will now first throttle, and then fully stop delivery from on-site exchange setups if these are (extremely) outdated and/or unpatched. While i do get the sentiment, i am somewhat worried about the box this mechanic opens. Are there any other thoughts on this? With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] linodeusercontent.com/googleusercontent.com, I'm so done with you
Heho, On Sat, 2023-04-08 at 17:25 -0700, Neil Anuskiewicz via mailop wrote: > > On Apr 7, 2023, at 9:26 PM, Jarland Donnell via mailop > > wrote: > > ... > > Blocking SMTP by default makes sense, but settling on the best way > > to handle opening it (automated? manual review?) is a discussion > > that is very easy to get stuck in. I don't know where they're at on > > that discussion by now, but when I left it was something I would > > have referred to as "on the table." That to say most of the > > stakeholders would entertain the discussion. > > ... > ... > As you said mom the current path is upward sloping expenses > undermining your price competitiveness. I don’t think you’d lose > many legit customers over a hoop to jump through for 25. You might > gain some good but previously hesitant customers. > ... To add on that: Hetzner recently introduced this for their cloud, with unblocking only being possible after the first invoice has been paid (iirc). So, at least one big competition in the .eu market already goes this path. If somebody from Hetzner is on the list, it would be interesting if they could chime in how that has been holding up so far. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: PSL: SOA record per subdomain required?!
On Tue, 2023-05-09 at 10:19 +0200, Stefano Bagnara via mailop wrote: > ... > > #1 host -t soa e.comune.bardolino.vr.it > e.comune.bardolino.vr.it is an alias for app.mailvox.it. > ... > > I guess it is not the missing SOA at #2 because all of our senders > share that step and most of them show no issues. > So maybe the issue are the missing SOA at #4/#5, but this would be > out of control by me or my customer (che municipality of Bardolino). It is actually the one at #1; or rather, at bardolino.vr.it, even though adding it at e.comune.bardolino.vr.it or comune.bardolino.vr.it should also help. Talking to a colleague about this; What you could do is move your current DNS setup behind powerdns frontends with a remote backend: https://doc.powerdns.com/authoritative/backends/remote.html https://github.com/PowerDNS/pdns/blob/master/modules/remotebackend/example.rb You could use that with a script to programatically inject SOA/NS/DS for names matching a specific pattern; At the same time, you could also use that to roll out DNSSEC. ;-) With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] United Airlines / mileageplus DNS/rDNS mismatch issue
Heho, hm, not sure. Looking at the 'email-security-scans.org' data, fcrdns is at ~95.5% of senders. For comparison: DKIM: ~55.2% SPF & Valid: ~91.0% TLS: ~96.0% Greylisting (attempting to resend): ~97.4% IPv4: ~97.9% IPv6 (sending): 56.2% IPv6 (sending+auth DNS+rec DNS): ~35.7% So even though that sample is a bit biased, i'd say that fcrDNS is more 'lived practice' than SPF. ;-) With best regards, Tobias On Tue, 2023-05-09 at 11:40 -0700, Michael Peddemors via mailop wrote: > Hi Laura, > > I think we have to disagree here. The PTR naming is set via > SendGrid. > It doesn't NEED to be the same as the A record. This is for those > MTA's > that do forward/reverse matching, which isn't always successful. > > Yes, doing that for a IPv6 email address to satisfy Google, go ahead. > > But nothing wrong with sending an email from a PTR with a name, that > doens't have the FQDN forward/reverse matched. > > As long as there is a URL associated with the domain name. > > eg. http://mileageplus.com (Redirect to UA site URL) > > Perfect forward/reverse FQDN matching is still a little aggressive > IMHO, > and especially problematic. Some people think they need 20 PTR > records, > one for each A record.. (No, that is worse) > > Postfix does allow forward/reverse checking, I would NOT enable that > for > the IPv4 space (yet) > > On 2023-05-09 10:22, Laura Atkins via mailop wrote: > > That’s a Sendgrid IP, they likely told UA to put in a DNS record, > > but UA > > never did. ¯\_(ツ)_/¯ n > > > > > On 9 May 2023, at 18:01, Stephen Frost via mailop > > > > > > wrote: > > > > > > Greetings, > > > > > > I'm getting some inbound email attempts that I believe are > > > legitimate > > > from United Airlines that are being rejected due to: > > > > > > May 9 12:55:38 tamriel postfix/smtpd[1221960]: warning: hostname > > > o1.email.smallbusiness.mileageplus.com does not resolve to > > > address > > > 50.31.61.242 > > > > > > Tracking this back, near as I can tell, postfix is correct here > > > in that > > > 50.31.61.242 / 242.61.31.50.in-addr.arpa resolves to > > > o1.email.smallbusiness.mileageplus.com but > > > o1.email.smallbusiness.mileageplus.com doesn't seem to actually > > > exist: > > > > > > dig o1.email.smallbusiness.mileageplus.com a > > > > > > ;o1.email.smallbusiness.mileageplus.com.IN A > > > > > > ;; AUTHORITY SECTION: > > > smallbusiness.mileageplus.com. 600 INSOA > > > vndcdf-fs-gma3-vip.ual.com. ualipconfig.united.com. 40 10800 > > > 3600 > > > 2592000 600 > > > > > > Hopefully someone on here is from UA or knows how to get in touch > > > with > > > someone there who could like into fixing that. > > > > > > Thanks, > > > > > > Stephen > > > ___ > > > mailop mailing list > > > mailop@mailop.org > > > https://list.mailop.org/listinfo/mailop > > > > -- > > The Delivery Experts > > > > Laura Atkins > > Word to the Wise > > la...@wordtothewise.com > > > > Email Delivery Blog: http://wordtothewise.com/blog > > > > > > > > > > > > > > > > ___ > > 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] [E] Re: PSL: SOA record per subdomain required?!
Heho, On Tue, 2023-05-09 at 20:20 -0400, John Levine wrote: > ... > There are millions of domains on the Internet and only a few thousand > in the PSL, so this is not a problem that most people need to worry > about. I am actually rather certain that 'not most people' approximately evaluates to two, with both of them being on this mailing list. ;-) That being said; Of course, just doing things correctly is (obviously) the right solution; The 'solution' I outlined is for the specific context of 'legacy system in place that does not do zone-breaks, how do we get this fixed while we figure out how to properly fix our tree because whatever set of scripts currently manages our zone(s) grew sentient roughly two decades before ChatGPT and is really skeptical of change'. ;-) With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] verifier.port25.com
Heho, On Tue, 2023-05-23 at 13:31 -0500, Blake Hudson via mailop wrote: > Looks like the email verification application at verifier.port25.com > described in this > ( > https://postmarkapp.com/blog/port25s-authentication-and-spam-assassin- > tool) > article may have been shut down. > > Anyone have any insight into this or alternative tools for testing > DKIM, > SPF, and similar in one go? Lemme throw email-security-scans.org into the list of tools for this. ;-) And for receiving mail, the tests over at internet.nl. With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] freenet.de routing issues anyone? (Cloudflare-OVH issue?)
Moin, to get a bit back to the networking part of things... Poking a few people, this looks like a return path issue on Freenet's side; So they likely fnorded something on their side. Guess the only way to get this fixed is for them to realize the issue. ;-) So if somebody can poke netops of AS5430,... Will try posting to denog to see if that helps. With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Mailbox Filling w. Opt-In/Sign-Up mails
Moin, over the past 2-3 weeks, I saw a slightly more filled queue for email- security-scans.org; A lot of users seemed to start tests, but never received the corresponding test mails; In most cases, the ESP hat shutdown delivery to these inboxes due to a sudden high volume of inbound messages, with most addresses hosted being under @gmail.com (and some outlook.com/yahoo.com as well). A bit of digging found several end-user reports of the following MO: - Get phished - Something expensive is bought - Mailbox is overflown right when the notification of the transaction comes, likely in a bid to hide the illicit purchase Naturally, there now have been some 'adjustments' to the service to make sure it no longer contributes to that... and maybe finds some insight into what is happening there... *loglog* However, I'd be interested in hearing whether I had just missed some very common spam reason here; So: - Did somebody else stumble over this in the past and/or did i simply miss this being a thing? - How is this handled for, e.g., all the other tools that allow generating "a lot" of mail only needing a request (signups in general, ticket systems, [...])? I never saw something like this (on my own or others systems), even when dealing with services equally easy to motivate into mailsending. With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailbox Filling w. Opt-In/Sign-Up mails
Moin, > How do you prevent that abusers will enter many mail addresses and > you send out many test mails to people who never requested them? Now? Block-List skipping mail-sending for the most common providers and limiting in-flight tests for other domains. But with a sufficiently large botnet and enough different targets, you can still make the system send out quiet some mails. Still, I believe it should be more restrictive in that than the mailop@ ML signup form; Furthermore, even before some tighter limits i hardly saw more than one mail being send to one remote address. Which is part of the reason for this mail; Are there any best practices beyond what i did above for preventing this form of abuse (apart from 'wanna do "Captcha & Cloudflare" tonight' ? I mean, from the top of my head i can think of a ton of services that will more conveniently send more mails than mine; Not to speak of all the stuff you can do with recipient delimiters to make services send more mails to the same mailbox. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailbox Filling w. Opt-In/Sign-Up mails
On Tue, 2024-03-12 at 15:46 -0700, Michael Peddemors via mailop wrote: > Tobias, > > This does sound like a typical 'mail bomb', and there are even > services you can rent to mail bomb an enemy.. > > Used to only see it in the gamer community, kid stuff.. but it is > more rare than you think.. sometimes it can go on for several days.. More rare? You mean frequent; What kind of took me by surprise is the MO described in several reddit/etc. posts, which hints at mailbombing being used to hide other activity. > Lot's of single sign on mailing lists, and poorly written contact > forms are abused in a script kiddie style run.. Thing is: A single, badly implemented, contact form is kind of nice; Big volume, many to the same mbox. Mail quickly dropped for that sender, person complains online about bad delivery, all good. However, the volume i saw with my previous rate-limits was around ~10 mails/day getting through. Even now, logging all rate limited requests, what i see is around four mails an hour for the whole service (or would be without any limits applied; those mails now just end up never being send). Thing is, it is incredebly hard to limit below the previous rate of limiting, but there is still an abundance of services on the Internet that can be motivated to send mails like that. > Have to look at examples to be sure.. (feel free to share off list).. What do you mean with examples? I just see target mail addresses (which, incidentally, google finds listed with credentials in some 280- page mail:password dump pdf on scribd.com). Btw, if anyone at google is interested in getting those streamed, so they can take more effective action to protect mailboxes, let me know; This is also why i was wondering whether there is honeypotting going on for this. > Like I said, a lot more rare than you think, but a pain when it > happens. So, from the current logs of 2-4 mails/day, I'd say it happens to at least 40-80 people a day. ;-) > > On 2024-03-12 11:19, Tobias Fiebig via mailop wrote: > > Moin, > > > > over the past 2-3 weeks, I saw a slightly more filled queue for > > email- > > security-scans.org; A lot of users seemed to start tests, but never > > received the corresponding test mails; In most cases, the ESP hat > > shutdown delivery to these inboxes due to a sudden high volume of > > inbound messages, with most addresses hosted being under @gmail.com > > (and some outlook.com/yahoo.com as well). > > > > A bit of digging found several end-user reports of the following > > MO: > > > > - Get phished > > - Something expensive is bought > > - Mailbox is overflown right when the notification of the > > transaction > > comes, likely in a bid to hide the illicit purchase > > > > Naturally, there now have been some 'adjustments' to the service to > > make sure it no longer contributes to that... and maybe finds some > > insight into what is happening there... *loglog* > > > > However, I'd be interested in hearing whether I had just missed > > some > > very common spam reason here; So: > > > > - Did somebody else stumble over this in the past and/or did i > > simply > > miss this being a thing? > > - How is this handled for, e.g., all the other tools that allow > > generating "a lot" of mail only needing a request (signups in > > general, > > ticket systems, [...])? I never saw something like this (on my own > > or > > others systems), even when dealing with services equally easy to > > motivate into mailsending. > > > > With best regards, > > Tobias > > > > ___ > > mailop mailing list > > mailop@mailop.org > > https://list.mailop.org/listinfo/mailop > > -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailbox Filling w. Opt-In/Sign-Up mails
Moin, > Create a random generated mail address that the person needs to send > an email to. Verify SPF/DKIM/DMARC strictly, so forging is much > harder and reject it with a proper message, maybe with a link that > explains the result. Yeah. I thought about that. _Technically_ the whole thing can also be done by just presenting links for users to click on on the web page. However, that reduces the usability of the service a lot, as some clients do funny things for mailto: with a lot of Cc:, and users apparently struggled a bit with it as well. Being able to hit 'reply all' seems to be a bit easier, in general. :-/ Concerning the strict verification mail-in before: I thought about that; But given that this is a service to test whether you configured spf/dkim/dmarc correctly... making that being correctly configured a prerequisite would be kind of... difficult. ;) > Use a captcha to make it harder for non-humans. Actually, looking at the access logs for those requests, i am not 100% convinced that this is automated and not some shady 'clickworking'. > That should massively reduce the amount of unsolicited mail. Yeah; Luckily 'disable mail sending for gmail/MS/Yahoo' already is surprisingly effective at that (getting close to 0 mails getting through; Even though it seems it needs a bit more fine-tuning.) With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Debugging fwd issue meta.com to zoho.com (Help from user under meta.com needed)
Moin, tl;dr: Could someone do https://email-security-scans.org from meta.com, storing mails on the server and sharing the link with me to help me debug a deliverability issue? I just got a report in that a user's mail bounced when writing from '@meta.com' to an alias on a domain I operate, which forwards to a third party hosting on zoho.com. The NDR is for a DMARC reject; In my logs, I see that: - ARC verification already failed on inbound with a bh mismatch - DKIM seems to have passed, though, at least according to the logs (with a selector hinting at it being for Q4 2021) zoho.com then rejects with "550 5.7.1 Email rejected per DMARC policy" Given that SPF obviously fails, the question is why DMARC does no longer validate when hitting zoho.com; I currently suspect that there was either a tmp-error for the lookup of the DKIM key, or that meta/outlook.com signs some headers that may be affected during a normal forward. Also, there are no issues with other DKIM signing p=reject domains being forwarded via the setup. To help me debug this; Is there anyone from meta / with an account under meta.com on the list who could do a test on https://email-security-scans.org (ideally checking the 'store my mails' checkbox)? (Already asked into the direction of the user as well, but this is a multi-hop conversation through a user of mine; And it somewhat bugs me and i'd like to resolve this asap. ;-)) With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ 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)
Moin, got it, thx. With best regards, Tobias On Mon, 2024-06-03 at 21:36 +0200, Tobias Fiebig via mailop wrote: > Moin, > > tl;dr: Could someone do https://email-security-scans.org from > meta.com, > storing mails on the server and sharing the link with me to help me > debug a deliverability issue? > > I just got a report in that a user's mail bounced when writing from > '@meta.com' to an alias on a domain I operate, which forwards to a > third party hosting on zoho.com. > > The NDR is for a DMARC reject; In my logs, I see that: > - ARC verification already failed on inbound with a bh mismatch > - DKIM seems to have passed, though, at least according to the logs > (with a selector hinting at it being for Q4 2021) > > zoho.com then rejects with "550 5.7.1 Email rejected per DMARC > policy" > > Given that SPF obviously fails, the question is why DMARC does no > longer validate when hitting zoho.com; I currently suspect that there > was either a tmp-error for the lookup of the DKIM key, or that > meta/outlook.com signs some headers that may be affected during a > normal forward. Also, there are no issues with other DKIM signing > p=reject domains being forwarded via the setup. > > To help me debug this; Is there anyone from meta / with an account > under meta.com on the list who could do a test on > https://email-security-scans.org (ideally checking the 'store my > mails' > checkbox)? > > (Already asked into the direction of the user as well, but this is a > multi-hop conversation through a user of mine; And it somewhat bugs > me > and i'd like to resolve this asap. ;-)) > > With best regards, > Tobias > -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Contact to zoho.com
Moin, is somebody from zoho.com here and could contact me off list? With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ 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)
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). While rspamd on my machine did not have an issue, forwarding recipients were unable to parse this. Incidentally, it seems like dkimpy also is unable to parse such headers, even though the email modules decodes them just fine. I added support to test for this to email-security-scans.org, i.e., if your DKIM header contains UTF8 encoded fields, it now shows a warning. With best regards, Tobias On Mon, 2024-06-03 at 23:11 +0200, Tobias Fiebig via mailop wrote: > Moin, > got it, thx. > > With best regards, > Tobias > > On Mon, 2024-06-03 at 21:36 +0200, Tobias Fiebig via mailop wrote: > > Moin, > > > > tl;dr: Could someone do https://email-security-scans.org from > > meta.com, > > storing mails on the server and sharing the link with me to help me > > debug a deliverability issue? > > > > I just got a report in that a user's mail bounced when writing from > > '@meta.com' to an alias on a domain I operate, which forwards to a > > third party hosting on zoho.com. > > > > The NDR is for a DMARC reject; In my logs, I see that: > > - ARC verification already failed on inbound with a bh mismatch > > - DKIM seems to have passed, though, at least according to the logs > > (with a selector hinting at it being for Q4 2021) > > > > zoho.com then rejects with "550 5.7.1 Email rejected per DMARC > > policy" > > > > Given that SPF obviously fails, the question is why DMARC does no > > longer validate when hitting zoho.com; I currently suspect that > > there > > was either a tmp-error for the lookup of the DKIM key, or that > > meta/outlook.com signs some headers that may be affected during a > > normal forward. Also, there are no issues with other DKIM signing > > p=reject domains being forwarded via the setup. > > > > To help me debug this; Is there anyone from meta / with an account > > under meta.com on the list who could do a test on > > https://email-security-scans.org (ideally checking the 'store my > > mails' > > checkbox)? > > > > (Already asked into the direction of the user as well, but this is > > a > > multi-hop conversation through a user of mine; And it somewhat bugs > > me > > and i'd like to resolve this asap. ;-)) > > > > With best regards, > > Tobias > > > -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ 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)
Hello John, > If you're not sending SMTPUTF8 mail, the DKIM signature headers > should be ASCII with no encoding needed. But if you are ending > SMTPUTF8 mail, you can put UTF-8 directly in the header and it > doesn't need any futher encoding either. Yeah, even more odd, the actual data did not contain any UTF-8 anyway. Meta now also fixed this. > Can you give an example of the signature headers that caused a > problem? They just sound wrong. See attached. dkimpy/dkimverify failed on the original mail with: dkim.MessageFormatError: b'=?UTF-8?Q?v=3D1' However, when fixing the header manually, the mail correctly validates: % cat ascii.mbox|dkimverify signature ok rspamc is also able to verify the original mail: # cat 36751.mbox| rspamc Results for file: stdin (2.36 seconds) [Metric: default] Action: no action Spam: false Score: 1.10 / 15.00 ... Symbol: DKIM_TRACE (0.00)[meta.com:+] Symbol: R_DKIM_ALLOW (-0.20)[meta.com:s=s2048-2021-q4] ... My understanding, though, is that encoding _should_ be permissible here, as it would be needed, e.g., when receiving a message from a server with SMTPUTF8 which then must be forwarded via a server that does not support it. Would be nice to know, though, as that influences how I should score such headers being there (error vs. warning) for the test-website. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl --- ascii.mbox 2024-06-04 18:52:56.213538681 +0200 +++ 36751.mbox 2024-06-03 23:44:21.342406024 +0200 @@ -13,7 +13,16 @@ Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 453LCtYI010400; Mon, 3 Jun 2024 14:24:06 -0700 -DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meta.com; h=content-type:date:from:in-reply-to:message-id:mime-version:references:subject:to; s=s2048-2021-q4; bh=+u8G0t/3N3vkyvfnVsE3LmLsnsfDjQZbrcpl03e4/lw=; b=b/+Or8DXaJuDThOsxHzXoSEPgs595iO+fF50NpcmYH0/FyZ7YbDAASqsssKGp3A2P0+H P9Ed7gY8QrH4kb5PydaPnO7aHOd/ggqaDszuxXqzTpwN6WYNpEsjG0Rci4J+CaMClpR4 MmDT9lkvErV1LzKBr2CeVOmjlcoY9DDXV58W7LF8ChcBolXb5jphrn/kjsT3wUNAADjC qXuiaK8XjckdThchqrAhaaqmjTrym8iFMcwmYcnxtlxdMc0vDAcj1L9OwaTJF2orIBEu gqyoY4Kp5wmXZMEMKbb4n8AphX4fbWJBSENovqYfaBAzFJZUghkfrlW+4pN7qYxf7i6d 5w== +DKIM-Signature: =?UTF-8?Q?v=3D1;_a=3Drsa-sha256;_c=3Drelaxed/relaxed;_d=3Dmeta.com;_h=3Dc?= + =?UTF-8?Q?ontent-type:date:from:in-reply-to:message-id:mime-version:refer?= + =?UTF-8?Q?ences:subject:to;_s=3Ds2048-2021-q4;_bh=3D+u8G0t/3N3vkyvfnVsE3L?= + =?UTF-8?Q?mLsnsfDjQZbrcpl03e4/lw=3D;_b=3Db/+Or8DXaJuDThOsxHzXoSEPgs595iO+?= + =?UTF-8?Q?fF50NpcmYH0/FyZ7YbDAASqsssKGp3A2P0+H_P9Ed7gY8QrH4kb5PydaPnO7aHO?= + =?UTF-8?Q?d/ggqaDszuxXqzTpwN6WYNpEsjG0Rci4J+CaMClpR4_MmDT9lkvErV1LzKBr2Ce?= + =?UTF-8?Q?VOmjlcoY9DDXV58W7LF8ChcBolXb5jphrn/kjsT3wUNAADjC_qXuiaK8XjckdTh?= + =?UTF-8?Q?chqrAhaaqmjTrym8iFMcwmYcnxtlxdMc0vDAcj1L9OwaTJF2orIBEu_gqyoY4Kp?= + =?UTF-8?Q?5wmXZMEMKbb4n8AphX4fbWJBSENovqYfaBAzFJZUghkfrlW+4pN7qYxf7i6d_5w?= + =?UTF-8?Q?=3D=3D_?= Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2169.outbound.protection.outlook.com [104.47.59.169]) by mx0a-00082601.pphosted.com (PPS) with ESMTPS id 3yhg8jtq5u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); DKIM-Signature: =?UTF-8?Q?v=3D1;_a=3Drsa-sha256;_c=3Drelaxed/relaxed;_d=3Dmeta.com;_h=3Dc?= =?UTF-8?Q?ontent-type:date:from:in-reply-to:message-id:mime-version:refer?= =?UTF-8?Q?ences:subject:to;_s=3Ds2048-2021-q4;_bh=3D+u8G0t/3N3vkyvfnVsE3L?= =?UTF-8?Q?mLsnsfDjQZbrcpl03e4/lw=3D;_b=3Db/+Or8DXaJuDThOsxHzXoSEPgs595iO+?= =?UTF-8?Q?fF50NpcmYH0/FyZ7YbDAASqsssKGp3A2P0+H_P9Ed7gY8QrH4kb5PydaPnO7aHO?= =?UTF-8?Q?d/ggqaDszuxXqzTpwN6WYNpEsjG0Rci4J+CaMClpR4_MmDT9lkvErV1LzKBr2Ce?= =?UTF-8?Q?VOmjlcoY9DDXV58W7LF8ChcBolXb5jphrn/kjsT3wUNAADjC_qXuiaK8XjckdTh?= =?UTF-8?Q?chqrAhaaqmjTrym8iFMcwmYcnxtlxdMc0vDAcj1L9OwaTJF2orIBEu_gqyoY4Kp?= =?UTF-8?Q?5wmXZMEMKbb4n8AphX4fbWJBSENovqYfaBAzFJZUghkfrlW+4pN7qYxf7i6d_5w?= =?UTF-8?Q?=3D=3D_?= ___ 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)
Moin, > I wouldn't verify that either. It's just wrong. You're not allowed > to MIME encode strings in a DKIM-Signature header.* Yeah, I misread 8616 there, then; My brain somewhat autoclicked to "well, if there can be UTF8 you must be able to mime encode." > * - I'm pretty sure that if you asked the author of RFC 8616, he'd > say the same thing. Yes, thank you. I am currently discussing with the author and he gave valuable input on where I misread 8616. Based on his feedback, I'll change the evaluation for such headers to 'error' instead of 'warning' in the mailtest system. > Unfortunately there is a lot of badly written mail processing code > that tries to be helpful by MIME encoding headers without checking > whether the headers allow it. 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. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ 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)
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? With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ 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)
Moin, On Thu, 2024-06-06 at 12:44 +1000, Viktor Dukhovni via mailop wrote: > The distinction is essential, because it would be a terrible mistake > to, for example, RFC2047-encode the "mailbox" construct in "From", > "To", ... headers. An RFC2047-ignorant MUA or MTA can still > correctly decode the addresses in those headers without caring about > the display name encoding. Kind of a point; However, if I got John correctly, an SMTPUTF8 mail having to go through a system that does not support it should simply bounce? On Wed, 2024-06-05 at 11:00 +0200, John R Levine via mailop wrote: > Nope. You cannot downgrade a SMTUTF8 message to an ASCII message. > The experimental versions of EAI tried to do that and it never worked > so they took it out of the standards track EAI RFCs. To be fair... if my students working on 'normal' security stuff complain about things being to confusing, inconsistent, and complex... I threaten them with the proposition that they could _also_ be working on DNS. If those working on DNS complain, I suggest they could also do BGP instead. Now, if the ones working on BGP complain, I threaten them with the prospect of working on mail. And if the ones working on mail complain... I usually just say "I'm sorry; At least look at the bright side: It can't get worse." ;-) (This is a joke.) On Thu, 2024-06-06 at 12:44 +1000, Viktor Dukhovni via mailop wrote: > It seems to me, that you may not have thought through the issues > deeply enough. I would, indeed, argue that this issue has a few more facets that need to be discussed; With some of those potentially being somewhat supportive of Vsevolod's point. On Thu, 2024-06-06 at 12:44 +1000, Viktor Dukhovni via mailop wrote: > On Wed, 2024-06-05 at 17:29 +0100, Vsevolod Stakhov via mailop wrote: > > As Rspamd author, I will not change the existing logic, as it works > > with headers as with black boxes making the following steps: unfold > > -> rfc2047 decode -> process specific data. > > This, IMNSHO, is not a reasonable stance to take... I am not so sure, at least IMSSANSMBLAHSIDTO (in my somewhat-stupid- and-not-so-my-but-looking-at-how-some-implementations-do-this opinion) the sketched approach is also how, e.g., Python handles RFC2047 headers. In fact, it was somewhat messy to convince python to rewrite an RFC2047-ized DKIM header to not mime encoded text, as the email module would read the header correctly, print it in ASCII/UTF8, but writes it back mime encoded (this is for email-security-scans.org; So a specific case sometimes requiring doing weird things not advisable anywhere else, i.e., here the rewriting.). On Thu, 2024-06-06 at 12:44 +1000, Viktor Dukhovni via mailop wrote: > Such willful disregard of essential interoperability requirements... To be fair, rspamd was the _more_ interoperable mail handling software in this case. > I've heard "rspamd" otherwise has some appealing features, but this > is show-stopper. :-( It does. Especially when it comes to DKIM (ed25519 support, not injecting funny whitespaces breaking signatures), ARC (well, it _does_ ARC, contrary to many other implementations), DMARC reporting (which also tends to be more slim in other implementations) etcetc. And, contrary to many other milters, it is really scalable. So, personally, big fan of rspamd. So, the stance, which I would abbreviate as 'in case of doubt, I do anything to get an email reliably processed and delivered' is not only Vsevolod's; In fact, Gmail--for example--also tends to be 'a bit more lenient' to get an (outbound) email delivered. Including, up until recently, 'ignore DNSSEC being broken' (even though that _does_ seem to have changed, at least when testing this morning; Or it is attached to a timer for a domain, i.e., if a domain has been seen with working DNSSEC for $time, it starts to get enforced; Anyway, tangential.). My point here is, that 'deliverability' is often more of a priority for ESPs than 'following all documents to the letter'. Granted, for the bigger ones, usually more like 'outbound deliverability' than 'inbound deliverability', though. Hence, I am not completely sure if the stance is outright unreasonable, even if it disagrees with the documents. After all, the 'drift' between documents and 'what is being done on the wire' has been getting larger for some time already. And if I have the choice between 'no commits for six years' (OpenDKIM; Good candidate for next xz, imho, btw.), 'something involving python' (dkimpy), and rspamd, I am somewhat inclined to use rspamd, i.e., there is not that many alternatives to recommend, when recommending people not to use rspamd. (The last comment is observational concerning that drift, and not a suggestion to outright change the documents, a call for rspamd to change, or a statement in support for either direction; I am marveling the problem, suggesting that this drift might need some discussion (again), and ultimately, some form of approach to fix it.) With best regard
Re: [mailop] Debugging fwd issue meta.com to zoho.com (Help from user under meta.com needed)
Moin, On Thu, 2024-06-06 at 17:53 +1000, Viktor Dukhovni via mailop wrote: > It is also, IIRC, a DKIM *signer* and verifier. DKIM signing and > verification needs to interoperate. > ... > To a degree, but not to the point of accepting total garbage > (RFC2047-encoded DKIM-Signature headers), or especially, generating > total garbage (producing RFC2047-encoded DKIM-Signature headers). Just to clarify here: rspamd creates correct DKIM signatures when working as a signer; The broken DKIM sig was somebody else's accomplishment. rspamd ingested it and was ably to verify it. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ 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)
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? With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] heads-up: Exchange Online: validation issues with Let's Encrypt DANE
Moin, are you sure the RRset is not inadvertently bogus? Can slip by rather easily for a set of reasons; Old RRSIGs vor example after one of the entries got updated? If not; Out of personal curiosity; can you test where 'the boundary' is to trigger the error? should be doable with like 4 test domains max (bin-search starting at 7 RR in the set). With best regards, Tobias On Mon, 2024-06-10 at 12:36 +0200, Kirill Miazine via mailop wrote: > Apparently exchange online would provide an error to the user like > this: > > dnssec-invalid: Destination domain returned invalid DNSSEC records > > https://learn.microsoft.com/en-us/exchange/troubleshoot/email-delivery/ndr/non-delivery-reports-in-exchange-online > > explains what this really means: > > The destination domain indicated it was DNSSEC-authentic, but > Exchange > Online wasn't able to verify it as DNSSEC-authentic. > > So the guess is that Exchange Online is getting in trouble when there > are more than a few TLSA records... > > • Kirill Miazine via mailop [2024-06-10 12:06]: > > Although there are better alternatives to 2 1 1 with Let's Encrypt, > > some > > still use 2 1 1, and it seems Exchange Online is not happy when > > there > > are 14 TLSA records (why 14? because > > https://letsencrypt.org/certificates/)... A good reason to not use > > 2 1 > > 1 > > > > ; TLSA - LE certs published at > > https://letsencrypt.org/certificates/ > > -_le-tlsa TLSA 2 1 1 > > 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10 ; > > LE E1 > > - TLSA 2 1 1 > > bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270 ; > > LE E2 > > - TLSA 2 1 1 > > 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d ; > > LE R3 > > - TLSA 2 1 1 > > e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03 ; > > LE R4 > > +_le-tlsa TLSA 2 1 1 > > 3586d4ecf070578cbd27aedce20b964e48bc149faeb9dad72f46b857869172b8 ; > > LE > > + TLSA 2 1 1 > > d016e1fe311948aca64f2de44ce86c9a51ca041df6103bb52a88eb3f761f57d7 > > + TLSA 2 1 1 > > 2bbad93ab5c79279ec121507f272cbe0c6647a3aae52e22f388afab426b4adba > > + TLSA 2 1 1 > > 6ddac18698f7f1f7e1c69b9bce420d974ac6f94ca8b2c761701623f99c767dc7 > > + TLSA 2 1 1 > > cbbc559b44d524d6a132bdac672744da3407f12aae5d5f722c5f6c7913871c75 > > + TLSA 2 1 1 > > 885bf0572252c6741dc9a52f5044487fef2a93b811cdedfad7624cc283b7cdd5 > > + TLSA 2 1 1 > > f1440a9b76e1e41e53a4cb461329bf6337b419726be513e42e19f1c691c5d4b2 > > + TLSA 2 1 1 > > 919c0df7a787b597ed056ace654b1de9c0387acf349f73734a4fd7b58cf612a4 > > + TLSA 2 1 1 > > 025490860b498ab73c6a12f27a49ad5fe230fafe3ac8f6112c9b7d0aad46941d > > + TLSA 2 1 1 > > f1647a5ee3efac54c892e930584fe47979b7acd1c76c1271bca1c5076d869888 > > + TLSA 2 1 1 > > 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d > > + TLSA 2 1 1 > > 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10 > > + TLSA 2 1 1 > > e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03 > > + TLSA 2 1 1 > > bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270 > > ___ > > mailop mailing list > > mailop@mailop.org > > https://list.mailop.org/listinfo/mailop > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ 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)
Moin, > 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. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
