Re: [mailop] Debugging fwd issue meta.com to zoho.com
Dňa 5. júna 2024 9:49:11 UTC používateľ Viktor Dukhovni via mailop napísal: >For maximal simplicity and robustness use the same encoding of domain >names (U-labels or A-labels) in "d=" and "i=" as you do (or would, if >there was "alignment") in "From:". Thanks to both, i think i got it now. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Debugging fwd issue meta.com to zoho.com
Dňa 5. 6. o 11:00 John R Levine via mailop napísal(a): I wouldn't verify that either. It's just wrong. You're not allowed to MIME encode strings in a DKIM-Signature header.* I don't argue, i am just curious, as i never think about it yet. Do you want to tell, that if d= and/or s= tags contains internationalized domain name/label, it must be in A-label (ASCII encoded) form? Or how it is supposed to be handled please? -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [STATE OF THE UNION] Tales from the Trenches..
Dňa 31. mája 2024 15:35:36 UTC používateľ Alessandro Vesely via mailop napísal: >Lots of queries, aren't they? I only use Smpamhaus zen and DNSWL for >whitelisting, for receiving SMTP. My own RBL blocks via iptables. Note: my MSA is separated from MX, but both use the same (caching) DNS server. I do't think that it is a lot of queries. Of course, it is more than two, but they are done in paralel (more precise async) and DNS queries are cheap. Thease RBLs overlaps only in ~50 - 60 %, thus more probability that bad actor will get hit, when i combine them. I abandon ZEN (only DROP from its codes) for auth, after i hit some false positives. Initialy i got panic (not really), as it was my daughter's partner, but then we identified, that it was IP change, and then again, and again... >At the end of the day I check all login addresses against abuseIPDB, which is >not an RBL; it has a web interface. I am aware of it, i had account there, but then i removed it. But yes, i investigate results too, not on daily base, only when i "feel" that it is needed. But as i mention, my user base is low and i know personaly all of them, no problem to inform about problem... >Nice graphics! Thanks, python + mathplotlib, the code, if you are interested, is here: https://git.slavino.sk/ipcartog.git/ but some Slovak strings are hardcoded... >I don't block based on country, because users sometimes travel. I have per user country list (no user interface too), by default whole EU + some popular destinations (i don't know to name them in English from head), and i usually know when users will travel, no problem yet. Some years ago i was against GeoIP blocking, but then i changed my minds, but only for email AUTH (yet?). >The opposite for me. They doubled in the last three weeks. Perhaps they just moved from me to you :-P But i afraid, that they will return... Currently is my web server abused, for about 10 days... I am only not sure if i am target, or i am used to abuse others (just SYNs, but not as high to be flood)... I noticed it only from TCP retransmission monitoring (increased by ~100 times), it is ~100 IPs daily, most of them from AS20473. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [STATE OF THE UNION] Tales from the Trenches..
Dňa 31. 5. o 11:51 Alessandro Vesely via mailop napísal(a): > What RBLs do you configure? Beside my own RBLs i use DROP & AuthBL from SpamHaus, BIP from virusfree.cz, and multiple codes from dronebl.org. They are queried in paralel, thus count doesn't have big inpact. But rejects based on RBL are tiny part of rejects, almost all are (was) by GeoIP here, namely (from my head, without order) AR, BR, US, ID, RU and some others. You can see some monthly cartographs here: https://foto.slavino.sk/index.php?/category/msa_blok (I stop to generate them, as attempts count significantly decreased in last months) > I'd be curious how you have your users whitelisting IPs or domain names... No interface for users exists. I remember only one problem, it was false positive from SpamHaus XBL, then i add possibility to define min. positive RBL answers count, but finally i stop to use XBL for auth at all (it was wrong idea). regards -- Slavko https://www.slavino.sk/ -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [STATE OF THE UNION] Tales from the Trenches..
Dňa 30. mája 2024 19:56:01 UTC používateľ Michael Peddemors via mailop napísal: >However, it isn't as simple as blocking every IP that bangs on your door. If >you block large CGNAT IP's for instance, one compromised IoT device behind >that IP can stop hundreds of legitimate users. Yes, that is a problem and i am aware of it. Fortunately i needn't to bother with it yet. But, of course, IPs can be white listed, as partial solution in it... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [STATE OF THE UNION] Tales from the Trenches..
Dňa 30. mája 2024 18:23:25 UTC používateľ Michael Peddemors via mailop napísal: >I am sure there are many others that are dedicated to strictly AUTHentication >abuse.. The key is to be able to do the check at all levels of authentication, >whether by using an RBL, or static lists.. I hope, that it isn't problem to promote own software here... Two or three years ago i was target of a lot of leaked passwords attempts (it was XMPP passwords, but they tried it as email), i was looking into weakforced solution for dovecot, but i meet multiple problems with it, thus i did my own dovecot's auth daemon, its initial intent was to check RBLs, but over time it evolved to count success login IPs (to detect account compromise) and GeoIP block (per user). Any one can use it (GPL licensed) from my git repo https://git.slavino.sk/dovepolicy.git/ It is in Python (flask app) + redis, i use it for my dovecot (and exim authed via dovecot). I cannot tell about performance, my user base is low, but works well for me and in spikes it was blocking ~800 IPs daily (+ normal user logins). In conjunction with fail2ban it was very success and most attempts are now gone for more months. It is not in state of full app (one click install), some manual steps are required to setup it and only some features are manageable by CLI interface, thus not intended for not experienced users, but i use it in git HEAD state. Hope it will be useful for someone... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI
Dňa 18. mája 2024 16:07:51 UTC používateľ Bill Cole via mailop napísal: >Who uses it? I feel as the problem lies elsewhere. Perhaps just mentioned gigants fails properly parse the l= tag (or even do not parse it at all) and their UI shows whole message (or all its parts) as signed, despite that only part of it was signed. And instead to fix that, they decided to force all others do not use it, RFC or not RFC... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI
Dňa 17. mája 2024 14:12:41 UTC používateľ "Taavi Eomäe via mailop" napísal: >A longer description with images is available here: >https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/ I didn't get what is **new** in it, nor how length of RSA keys is related... The l= DKIM tag was problematic in time of RFC, the Content-Type constructs core of message, thus have to be (over)signed already. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Problems with invoices.premierinn.de and postmas...@premierinn.de
Dňa 26. apríla 2024 12:52:51 UTC používateľ Benny Pedersen via mailop napísal: >MX is optional not required if A/ exists with same domain, many admins say >if MX does not exists. then domain does not want email, this is fails also, >hope more mta admins know this AFAIK it is clearly defined in RFC 5321, sect. 5.1: ... If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host. In other words, no MX (eg. for example.net) is the same as: example.net. IN MX 0 example.net. If some admins are smarter, it is their problem... IMO Null MX is way to tell: "we do not accept mails", IIRC the Null MX's RFC warns, that it can imply: "we don't send mails" too, but that is side efect only (as no bounce can be delivered). regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Reason for being listed at Spamhaus CSS and XBL unclear
Dňa 18. apríla 2024 11:22:10 UTC používateľ Sebastian Arcus via mailop napísal: >However, if keeping outbound port 587 open turns out to be causing real >headaches, I could take a look at revising the existing approach. IMO, one don't need to block 465 port (or 587) from inside LAN, as it is near to impossible without breaking real users connections. But consider: + ratelimit it -- one user will not create a lot of connections, IMO good start can be 10 connections in 10-15 min + log over limit connections, this will allow to see if limit is too low and/or reveals infected hosts That will not prevent rogue connections, but will unhide them and thus one can do something with infected machine (block/clean or even trash it) relative quickly (my router FW logs are propagated over XMPP). And consider to include the POP3(S) and IMAP(S) too. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone from Google - Sudden Gmail bounces??
Ahoj, Dňa Sun, 31 Mar 2024 12:29:54 -0600 Richard W via mailop napísal: > 41.212.32.14 is PBL only. Other IPs in the /24 have other listings yes, now. the CSS & XBL was at time of previous check, as posted... regards -- Slavko https://www.slavino.sk pgprDduQ9ZmeR.pgp Description: Digitálny podpis OpenPGP ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone from Google - Sudden Gmail bounces??
Dňa 31. marca 2024 17:06:30 UTC používateľ Richard W via mailop napísal: >That Spamhaus listing is PBL, not an indication of bad. Your ISP must have >decided, or Spamhaus decided you shouldn't be sending mail. Looks like the >whole /24 is on PBL. PBL is not (bigest) problem, the worse part is XBL & SBL... I guess, that despite of PBL, the mail (ML) server has stable IP (as indicated by "all DNS auth", thus i expect PTR too), thus that cannot be bad actor previously used that IP. If not, then any effort will be reset on nect IP change... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone from Google - Sudden Gmail bounces??
Dňa 31. marca 2024 15:02:31 UTC používateľ Odhiambo Washington via mailop
napísal:
>> Something bad seems to have gained the ability to use that IP...
>>
>
>Not that easy unless there is some recent exploit that I am not aware of.
Don't seems as neighbor problem...
checkrbl 41.212.32.14
Found in "Spamhaus ZEN DQS" (zen.dq.spamhaus.net):
* CSS, Snowshoe SPAM (127.0.0.3)
* XBL, exploited, open proxy or botnet (127.0.0.4)
* PBL, end user (from Spamhaus) (127.0.0.11)
checkrbl 41.212.32.15
Found in "Spamhaus ZEN DQS" (zen.dq.spamhaus.net):
* PBL, end user (from Spamhaus) (127.0.0.11)
checkrbl 41.212.32.16
Found in "Spamhaus ZEN DQS" (zen.dq.spamhaus.net):
* PBL, end user (from Spamhaus) (127.0.0.11)
regards
--
Slavko
https://www.slavino.sk/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled
Ahoj, Dňa Sat, 16 Mar 2024 16:53:23 +0100 Marco Moock via mailop napísal: > Forwarding (e.g. forwarding as attachment etc.) is still a thing and > if it is about security, I only trust e2e encrypted mails to be not > eavesdropped. Everything else is just a guess and nothing else. TLS is *Transport Layer Security*, that means exactly what it has in name, up to L4 is secured (with some limitations in STARTTLS). What happens in higher layers is not covered, and that is exactly true for many others L7 protocols, including HTTPS (someone mentioned it), as HTTP(S) server can forward traffic to everywhere too, it is only less known. Would you consider to avoid modern TLS for HTTP, just because it is only guess what happens after TLS termination point? IMO E2E is not holy grail of computer security, yes it can secure all seven network layers, but has its own disadvantages and can make false security feel too, if not done properly/with care. regards -- Slavko https://www.slavino.sk pgpcv9wCmPF7N.pgp Description: Digitálny podpis OpenPGP ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] mailop and DKIM signatures
Dňa 16. marca 2024 19:19:21 UTC používateľ John Levine via mailop napísal: >The DKIM RFC very clearly says that an invalid DKIM signature is >equivalent to no signature. I suppose there may be people who wrongly >misinterpret an invalid signature as saying something bad about the >message, but there's not much we can do about people who don't bother >to read the spec. And the same RCF clearly suggests to leave other (even invalid) signatures untouched. But who will follow 13 years old standard... ;-) regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [spamhaus] de-listing requests successful, but only for a couple of days.
Dňa 14. marca 2024 19:15:14 UTC používateľ John Levine via mailop napísal: >It would not be hard to use a different address for every message. More precise, one can get/use new temporary IPv6 address every 5 s (less is ignored on Linux), but IMO with custom kernel even more often can be possible. Thus blocking/listing whole /64 is wanted. As the /64 is twice of whole IPv4 mask, plenty "spammers" with minimal effort, just two/three kernel setting values... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Google unsolicited mail rejected with 421
Dňa 14. 3. o 12:03 Marco Moock via mailop napísal(a): Is there any standard that defines the retry rates or at least a best practise? RFC 5321, sect. 4.5.4.1: In general, the retry interval SHOULD be at least 30 minutes... -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled
Dňa 14. 3. o 10:21 Andrew C Aitchison via mailop napísal(a): Given that TLS encryption in SMTP is hop-by-hop rather than end-to-end, I am not convinced that this is a significant reduction in security. Of course, SMTP is hop-by-hop by design, but how important is that hop-by-hop nowadays? Open relays are gone, source routing is gone, forwarding is not as simple as it was in past (it must be done properly)... I mean, that one will delivery message to recipient's MX host directly, not over random (unknown) hops, in worse case it will delivery it to backup MX (but that haven't be random hop). Thus we can assume target MX as final target in public net. Of course, in some (most?) cases the target MX host will not be final delivery target and will forward message to some MDA, eventually over multiple MTAs, but i will consider that as internal thing (secured by some way). IMO in most cases it is reasonable to forget about hop-by-hop nature in SMTP as argument nowadays. Or i miss something? -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled
Dňa 13. marca 2024 18:22:55 UTC používateľ Robert Giles via mailop napísal: >Sort of surprising, but I don't think JPMorgan Chase (large U.S. bank) is able >to do TLS 1.2+ Seems, that Central Europe banks are in better TLS condition ;-) regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled
Dňa 13. marca 2024 16:32:42 UTC používateľ Andrew C Aitchison via mailop napísal: >Has anyone checked what traffic is still using TLS 1.0 or TLS 1.1 ? Yes, some infected machines from DZ, BR, AR, ID and so :-) I checked last 90 days log now, i found only small number of plain text deliveries to me, but no one legitimate host with failed TLS attempt before plain text, thus i guess no fallback, just no TLS. As i have disabled TLS1.0 & 1.1 for long time, i check that from time to time, just to be sure. BTW i have one old debian 7 (wheezy, 2013) and its openssl provides TLS1.2, thus even that host must be fain (but it is not involved in mail nor any other public network services)... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled
Dňa 13. marca 2024 14:43:27 UTC používateľ Bill Cole via mailop napísal: >Every time I see this argument, I am struck by an important question: > > What is "poor" or "weak" about TLSv1.0 and TLSv1.1 which is relevant > in the context of SMTP, other than their easily-disabled support for > weak ciphers? Exactly that. When i disable CBC mode ciphers, i got empty cipher list for both, the TLS1.0 and TLS1.1, from my GnuTLS: gnutls-cli -l --priority "NORMAL:-VERS-ALL:+VERS-TLS1.0:+VERS-TLS1.1:-AES-128-CBC:-AES-256-CBC" It is empty even on ancient debian 10... AFAIK difference in result is only error message (unsupported version vs. no common ciphers). regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Rejected by bounce verification
Dňa 12. marca 2024 11:53:39 UTC používateľ Marco Moock via mailop napísal: >Is it ok that Listserv behaves like that? I don't use fortinet at all, but all bounces (empty MAIL FROM:) will be rejected here, if they fail BATV (prvs=) verification. AFAIK, bounces have go to Return-Path:, not to From: address. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Filter out emoji from email adresses
Dňa 7. marca 2024 20:01:09 UTC používateľ Yuval Levy via mailop napísal: >Have you considered the opposite approach? there must be somewhere a list of >the blocks used by conventional alphabets/glyphs. Assign negative score if >there is at least one character NOT WITHIN that fairly static pre-existing >list. No, i didn't try that approach. IMO working with unicode letters is not as easy, as one needs to normalize it first and then work with that normalized form... Too many work, with not as useful result... I afraid, that scoring of emojis in subject is not proper way, as i see a lot of legitimate mails with emoji in subject, thus it seems as pointless in SPAM filtering at all. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Filter out emoji from email adresses
Dňa 7. marca 2024 14:22:21 UTC používateľ "Yuval Levy ✅ via mailop" napísal: >My most important reason to "filter" emojis in email addresses and subject >lines would be to assign them higher spammyness scores in rspamd or >SpamAssassin. Are there already such rules? If not, how do I add them? I got similar idea, many months ago... Not to block nor filter them, but to add some score into message. I abandon it as too hard to maintain (for me), as emoji (graphics) are not in one continuous block of code points, nor regexp library(ies) assign one "category" (as eg. controll or currency symbols/chars) into them and their list continues to grow. And to be honest, i fail to build regexp for that, as i cannot found proper syntax for that in rspamd (hyperscan library). But if someone is interested to continue, here is list of CPs ranges from my notes from that time: + - # symbols & pictographs + - # emoticons + - # transport & map symbols + - # others It is quite many CPs, thus i am not sure if it is right and it will be not complete... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Filter out emoji from email adresses
Dňa 7. marca 2024 12:18:36 UTC používateľ Alessandro Vesely via mailop napísal: >On 06/03/2024 20:18, Slavko via mailop wrote: >> Dňa 6. marca 2024 18:13:34 UTC používateľ Bill Cole via mailop >> napísal: >> >>> support for SMTPUTF8 *in MTAs operating as MXs* is not widespread enough to >>> be useful >> >> Only exim (+ Python and ClawsMail) is usable in that... > > >Courier-MTA + Thunderbird work fine as well, for another one. I am sorry, of course i mean that these i tested, not that all others doesn't work... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Filter out emoji from email adresses
Dňa 6. marca 2024 18:13:34 UTC používateľ Bill Cole via mailop napísal: >Absolutely true. However, I believe that what John meant to point out is that >support for SMTPUTF8 *in MTAs operating as MXs* is not widespread enough to be >useful except for mail to Indian and Thai addresses, because even the rest of >the non-ASCII world has broadly not yet decided to allow SMTPUTF8. Hence, you >are likely to not have success sending high-bit-set bytes in headers unless >you have a narrowly limited audience of receivers. Unfortunately, you are right. I tried to allow it here and it was fiasco, i cannot create UTF-8 users/mailboxes as dovecot doesn't support delivery to it, i cannot receive SMTPUTF8, as rspamd loudly assign very high score to it, K-9 is not able to reply to UTF-8 address, etc, etc. Only exim (+ Python and ClawsMail) is usable in that... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Filter out emoji from email adresses
Dňa 6. marca 2024 15:52:47 UTC používateľ John Levine via mailop napísal: >There's an extension called SMTPUTF8, informally known as EAI for >Email Address Internationalization, that in principle allows any UTF-8 >in addresses, but unless you are sending mail to people in India or >Thailand, you don't want to try it. AFAIK, for most of the world is US-ASCII not enough, not only for India or Thailand. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Recommended ciphers used for ESMTP connections
Dňa 5. 3. o 0:15 Christer Mjellem Strand via mailop napísal(a): That said, we still decided to deviate from them *only* for SMTP (and not for i.e. Submission). The reason for this decision comes down to the number of poorly configured servers out there, and the fact that TLS in SMTP is still opportunistic. While requiring sane crypto at Mozilla's level will no doubt weed out a fair bit of spammers, unfortunately it is (still) likely to also weed out stuff it shouldn't. And since you won't know before the other side initiates STARTTLS whether you'll be able to agree on a common handshake, and poor crypto is still better than no crypto at all (which SMTP generally will happily allow), this ended up being the compromise. It can be not as bad as it can seems. I have allowed only TLS1.2+ and ciphersuites limited to AEADs, with limited groups and sigalgs, and from my MX (MSA is much worse) for long time i have logged in the whole february: + 9x Error in the pull function (i guess connect scans or so) + 5x A TLS fatal alert has been received: User canceled + 2x A packet with illegal or unsupported version was received + 2x No supported cipher suites have been found Yes, my MTA is not representative, but anyway it is less than 0,1 % of total connections (but not all bads reach STARTTLS stage). I didn't inspect these IPs in details in that month, but i did detailed inspection before and after i disabled TLS1.1 and TLS1.0 for long time, an all these attempts was from (at least) suspicious IPs. The main problem here is, that there are multiple hosts requesting only RSA ciphersuites, thus i have to maintain dualstack certs (RSA/ECDSA)... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Recommended ciphers used for ESMTP connections
Dňa 4. marca 2024 21:15:23 UTC používateľ John Levine via mailop napísal: >It appears that Ken O'Driscoll via mailop said: >>Transport encryption is not for confidentiality anyway. > >Agreed. My MTA uses "NORMAL:-VERS-SSL3.0" Then why you are disabled SSL3? And why you do not build own openssl with SSL2 support? regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Dot as the first character of a line ? (RFC 5321, Section 4.5.2)
Dňa 4. 3. o 11:09 Cyril - ImprovMX via mailop napísal(a): Pointing out the fact that the dot-stuffing works on the two sides (adding then removing) shows that in the current scenario, the issue is either caused by the sender or by us, and not between us and Gmail. And what does aiosmtpd with message after it receive it? I guess, that it is sending it out (to gmail), thus it acts as client... Does it quote (double) that dot when message goes out? regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Contact of postmaster for hostedemail.com domains
Dňa 26. februára 2024 17:57:16 UTC používateľ John Levine via mailop napísal: >I'm not surprised that they aren't interested in complaints from >senders. If the recipients don't care whether they get the mail, >there's no problem to be solved. I understand, that any spammer can complain and it can be not easy to distinguish spammer from real sender, but... I feel that we are going in circle. Sender complains are ignored, users can be (and IMO often are) not aware where to complain, or even do not know that they didn't received something. The only solution is to break the circle, but how? IMO people will soon or latter realize, that email is unreliable and will stop to use it at all. That is scenario already desribed in RFC 821 (in mean of interoperability). Done, circle is gone, but it is really way, which those providers (ignoring sender's complains) want? Perhaps they do not care -- once one business is gone, they move to another... And perhaps they only cannot realize, that they are not as smart as they think. The remaining question is: who won? IMO nobody, but we lost one of most freedom remote communication channel... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] One click unsubscribe in mailing list messages
Dňa 25. februára 2024 3:10:51 UTC používateľ Philip Paeps via mailop napísal: >Not being able to present information in the Subject: or body clearly isn't >ideal, but it's better than breaking DKIM. List-* headers have been in >widespread use for over twenty years. The bad part is, that eg. exim by default (over)signs List-* headers nonexistence, thus adding them will break its DKIM anyway. I don't know how many exims (providers) uses that default, but our job's email provider do that. When i complained, i got response, that it is right and i do not understand DKIM... :-D regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Outgoing Spam from Microsoft IPs
Dňa 19. februára 2024 12:46:51 UTC používateľ "Gellner, Oliver via mailop" napísal: >...the big email services providers need to make the first step in a >coordinated procedure. Otherwise the sender is unlikely going to fix his setup >and rather blame the receiver, because obviously he can deliver his emails >everywhere, just not to our place. Why big only? If cooradination have to be success (almost) all have to be involved. Something as was DNS flag day... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Verifying receipients?
Dňa 16. februára 2024 21:03:18 UTC používateľ Marco Moock via mailop napísal: >Use the VRFY SMTP command for that. If the remote site doesn't provide >it, they don't want that somebody probes for the mailboxes. IMO only between own servers, if at all. Disabling it (for public access) is suggested by RFC 2505 (25 years ago). >Some dnsbl (e.g. uceprotect) list servers that probe wit RCPT TO. Of course, one simple cannot use my resources for own security (nor harvesting)! regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] CloudSererblocks - was Re: Outgoing Spam from Microsoft IPs
Dňa 16. februára 2024 19:42:08 UTC používateľ Andrew C Aitchison via mailop napísal: >AMAZON > https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html > https://ip-ranges.amazonaws.com/ip-ranges.json Please, is somewhere described what "service" values means in it? regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Dňa 12. februára 2024 15:41:58 UTC používateľ Laura Atkins via mailop napísal: >In the face of those facts, what value does this bring to email? It seems as very good question, targeting the root of problem, as nobody was enough brave to argue... I ask more or less the same. Despite the fact, that SPF/DMARC can stop the obvious/simple spoofing, they are only "better than nothing" and i feel, as when target was not to win with spoofing, but fight with it (as fight for fight). And i feel, that personal/small bussines was not (enough) considered (in some of them). Perhaps it is time to stop playing SPAMers's game and start to play own one. How many providers was arested (or at least disconnected from Internet) for supporting of bad actors? How many shops/vendors was closed due selling defective (insecure) devices? How many people was penalized due damage from their own devices? Nobody is responsible, thus nobody care... Yes, sometime things doesn't work as intended, but if car is defective, either its vendor or owner must ensure that it is repaired (or so). Cars must often go to preventive check of its state (here every two years), etc, etc. And network devices? Again, nobody care... To drive car, one needs licence, but every stupid can connect own device to Internet... If we will not change something, we will waste more power in fighting, than for providing service. And IMO providing service have to be goal... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Dňa 11. februára 2024 19:06:31 UTC používateľ Sebastian Nielsen via mailop napísal: >>>On my site, users can use only own address/aliases, but i can use any >>>(including any domain)... > >Of course since you are administrator. Nothing strange with that. It was not meant as self-presentation, but as particular example that one site can have multiple different rules. >It all about trust. Choose providers you trust. But i asked as receiver how to verify, not as domain owner. As receiver i cannot choose from which provider message arrives, but i have to decide if i will accept it or not. The DMARC (etc) is tool to help me to choose properly/better, but in case of shared site its success can be as useful as dice roll... Anyway, what is trusted for domain owner not necessary must be trusted for receiver too and vice versa... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Dňa 11. februára 2024 17:33:30 UTC používateľ Sebastian Nielsen via mailop napísal: >>> because SPF is too easy to forge.) >Wrong. When a shared space is used, its up to that particular space, to >enforce so customers cannot use other customer’s email addresses. And how you can know if site enforces that? And i don't mean guess, nor believe, but really **know** with particular message? On my site, users can use only own address/aliases, but i can use any (including any domain)... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Dňa 9. februára 2024 16:06:36 UTC používateľ Marco Moock via mailop napísal: >A good solution for phishing is S/MIME. Sadly, the adoption is very low. >If all banks, online shops, government would use that, users could >simply check the sender and forging messages would be much, much harder. Hmm, and are you sure that regular users know what S/MIME is and are able to reliable distinguish email with and without it? I don't think so... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Dňa 9. februára 2024 6:11:29 UTC používateľ Marco Moock via mailop napísal: >dnsbl exists and some lists (e.g. uceprotect L3) entirely list ISPs >that have a huge amount of spammers in their network. >The more servers that block those ISPs, the less customers will use >them for mail. No, that is wrong understanding of UCEPROTECT's L2 & L3, they are for signaling to ISPs, that something is wrong in their network(s). As i prove some months ago, L2 listed whole /22 block due 4 or 7 (i don't remember exactly, you can search archive) issues. Do you consider that as huge? I don't... But yes, using its L2/L3 to reject will solve all your issues with incoming mails and you save a lot of disk space :-D regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Dňa 8. 2. o 10:38 Archange via mailop napísal(a): No, I agree with you (I’m running two forwarders that have no issues so far). And having a DMARC enforcing policy without DKIM is a bad idea. IMO not bad idea, only sometime missused idea. I see preventing of forwarding as legal requirements in some cases. But yes, often it is by misconfiguration, or doing something without understanding all of consequences... regards -- Slavko ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] zen.spamhaus.org
Dňa 7. februára 2024 22:09:18 UTC používateľ Atro Tossavainen via mailop napísal: >Now if that was a problem and this private secret got out because of >a query that was just done through Google a few minutes ago, we'd >find out in no time at all because Spamhaus would shut this private >secret down. I also expect we wouldn't have been the first ones to >explore this "problem" if it was one. DNS traffic is not encrypted, only encoded in public format, thus any router/hop (in public net) can see yout DQS, or any other, key included in query name. And without qname minimisation, you will share it with root & TLD nameservers too (and with hops to them). While i preffer do not share anything with google, IMO it doesn't matter, as the key is not private by any way. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] zen.spamhaus.org
Dňa 7. februára 2024 9:27:50 UTC používateľ Bjoern Franke via mailop napísal: >host whoami.akamai.net There are multiple services doing that, some even IPv6 capable, but if you know any IP which doesn't run DNS server (or blocks it), you can do connect/syn scan to its port 53/tcp too, if redirected you will see it as open... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] zen.spamhaus.org
Dňa 7. 2. o 7:29 Odhiambo Washington via mailop napísal(a): I have my local instance of unbound resolver. It can be not enough. Some time ago i noticed, taht my ISP intercepts (and redirects) all my DNS requests. Check carefully... regards -- Slavko ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Hotmail blocks mail to postmaster in violation of 5321/2821/821
Dňa 5. februára 2024 18:20:01 UTC používateľ "Randolf Richardson, Postmaster via mailop" napísal: > A few of the lesser-known lists show that your IP address has been >hitting spam traps. (I believe you deserve the white gloves, which IMO, the precise of that on some RBLs is at least discutable. My IPv4 is listed on one or two as "sending SPAMs" (hello v4bl.org). I can be sure that my server is not sending of any SPAMs. As my outgoing messages count rarely exceeds 10 messages **per week** (no mass mails, pure familly/friends), thus it is really easy to check as most of recipients are repeating (and most of messages are from me). And yes, my FW limits outgoing 25 port to my main MTA, thus no unnoticed mails can go out.. The only exceptions are DMARC reports (not in that count), where one have near to zero knowledge where message ends -- thus i can imagine that if some bad person adds mailtrap address into his rua= one can end in these RBLs, but anyway... I was dissapointed by that listing, as i used that RBL previously on my MSA to filter bads logins attempts, and it showed high success rate, but then i realized, that its content is not as reliable and abandon it. My IP is on it for several months, i don't care too much, i only check it (from time to time) to see how long it will remain there... just my 2 cents about "some" RBLs... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DMARC on srs forwarding domains?
Ahoj, Dňa Sun, 4 Feb 2024 16:02:31 +0100 Matus UHLAR - fantomas via mailop napísal: > Does anyone blindly trust ARC signatures from random domains? How one can trust that, if one don't know how (or if at all) original was checked? If i will blindly trust to that, i don't need to check SPF, DKIM, DMARC nor ARC at all and save world... > I find it a huge difference between DKIM signatures (I sign this mail > being from my domain) and ARC signature (I sign that this mail was > received from whitehouse.gov properly verified and signed). Yes, DKIM is slightly more reliable, as one sign own mails, ARC signs others/foreign mails... The only one, who is worst to trust (for me) am i, or perhaps partially trust on per-user base, in mean to trust particular ARC signer for particular recipient (user's own forwarded mails), but my environment is not prepared to this. rspamd has allows to define trustworthy ARC signers, but built-in system is on per ARC's domain only, to get it per user, one have to develop something own (IMO not as complicated as it can sound, but i never try that). regards -- Slavko https://www.slavino.sk pgpIUjfv9XZpM.pgp Description: Digitálny podpis OpenPGP ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM signed with parent domain
Dňa 27. januára 2024 3:59:54 UTC používateľ Byung-Hee HWANG via mailop napísal: > >Google Gmail accept such email: (source from soyeo...@gmail.com) >https://gitlab.com/soyeomul/Gnus/-/raw/d73303d3f304a275bb6f129c0d4934ce30680629/DKIM/gmail-forwarding-header-20240126.txt AFAIK: + standalone DKIM has no dependency on any email header + DMARC has option how strictly verify DKIM alignment Thus, make sure proper settings and it should be ok (RFC compliant). If some site will not accept that, it is its bug. To be sure, one can setup separate DMARC record for subdomain with separate rua= target defined and watch (inspect) reports for some time. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM signed with parent domain
Dňa 26. 1. o 10:49 Jörg Backschues via mailop napísal(a): Sorry, but there are issues with AboutMy.email when using multiple DKIM signatures e.g. RSA & Ed25519. I was curious, and no, there are not issues with dual signed DKIM, both my signatures are in pass state, the only missing thing is, that detail page about signature(s) lacks the key algorithm, but that is cosmetic. regards -- Slavko ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [External] seeking a spamtrap milter
Dňa 23. januára 2024 21:25:14 UTC používateľ Michael Peddemors via mailop napísal: >But, in reality not really worth the trouble.. domains are easy to forge, and >innocent companies maybe trying to verify the address, because a bad guy used >it in a contact form.. >Not to mention, how does that stop Gmail or o365 spammers from targeting your >traps.. we auto blockling gmail now? (oh, yeah it might be time soon, but not >yet) You are right, analyzing, whitelisting, etc for preventing of damage is not task for small company, nor personal/familly servers. But spamtraps are not only about that. I am happy with filling bayes (fuzzy/neural) filter with message contents, calculating DKIM reputation, etc. Any of spamtrap received message is contributing to overall SPAM filtering with fresh content. And that is great, and wanted result, without false positives (yet) and with minimal cost. And it doesn't matter who is sender... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Samsung and SIZE
Dňa 14. januára 2024 7:55:13 UTC používateľ Bastian Blank via mailop napísal: >On Sat, Jan 13, 2024 at 07:44:22PM +0000, Slavko via mailop wrote: >> Dňa 13. januára 2024 19:14:58 UTC používateľ Sebastian Nielsen via mailop >> napísal: >> >Then you need to reconfigure server to ignore said parameters. >> IMO, in other words, server (SHOULD reject) is RFC compliant, client >> is not (MUST NOT send). > >Also section 4.5.3.1.7: > >| SMTP server systems that must impose restrictions SHOULD implement the >| "SIZE" service extension of RFC 1870 Not all, only when they "must impose restrictions". In other words, it is not mandated -- in the same section one can read "message size restrictions should be avoided if at all possible". regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Samsung and SIZE
Dňa 13. januára 2024 19:14:58 UTC používateľ Sebastian Nielsen via mailop napísal: >Then you need to reconfigure server to ignore said parameters. RFC 5321, sect. 4.1.1: ...In the absence of specific extensions offered by the server and accepted by the client, clients MUST NOT send such parameters and servers SHOULD reject commands containing them as having invalid syntax. And section 4.1.1.2: If service extensions were negotiated, the MAIL command may also carry parameters associated with a particular service extension. IMO, in other words, server (SHOULD reject) is RFC compliant, client is not (MUST NOT send). regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?
Dňa 1. januára 2024 21:31:19 UTC používateľ Marco Moock via mailop napísal: >True, although, that can be used to send mail to local mailboxes only. >To relay to an external sender, MX must be allowed to relay via the >final destination MTA. I will consider that by "relay to an external sender" you mean external recipient... a) local mailbox is enough, that is always target ;-) b) smuggled message was relayed without notice over at least one hop (in described case MX MTA) c) all MTAs before MX relayed message to external recipient In other words, for attacker it is almost every time external recipient. But relaying itself doesn't imply external... AFAIK term "relay" is in RFC described as transfer from one MTA to another (without defining reason). regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?
Dňa 1. januára 2024 19:38:08 UTC používateľ Marco Moock via mailop napísal: >Am 01.01.2024 um 17:58:47 Uhr schrieb Gellner, Oliver via mailop: > >> To exploit the issue, an email message needs to traverse two MTAs >> that treat the EOM marker differently. The MTAs do not need to be in >> a special trust relationship or allowed to relay to each other. > >Sorry for the second reply, but how does this work? > > >Assumption: >2nd MTA doesn't allow MX to relay through it. > >If the MX ignores LF and a second intra-site MTA acknowledges it, it >would reply with "Relying denied" if the recipient address of the >second mail is not local (Cw) or is allowed to be relayed through that >MTA in any other way (e.g. access db To:j...@example.org RELAY). > >Please explain me how unauthenticated relaying works here. >I am aware that this creates a bounce an can be used for backscatter >(without checking DKIM nor SPF because MX sees only one message Consider to have 2 MTA, the first one receives message from public net and does all checks and then delivers to second MTA for final delivery. Thus, the second MTA doesn't need to check that again, trusts the first one and just does final delivery. If both treats end of DATA differently, the first can see only one message (thus does only one check), but second MTA see two (or even more) messages, but trusts that first MTA's checks, thus just delivers them all. No SPF nor DMARC checks happens with smuggled message(s). Or vice versa. First is MSA, which checks, that sender (MAIL FROM) is allowed for that (authenticated) user and if yes, allows to relay that (one) message, but confused receiver will again see two (or more) messages. The smuggled message can thus bypass sender checking on MSA and if smuggled message uses another domain hosted on the same system, its SPF will pass, and thus its DMARC will pass... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Malformed To: header
Hi, recently i see messages from this ML rejected by my MTA, due malformed To: header (from postmas...@inter-corporate.com): To: mailop@mailop.org AFAIK, the display name have to be quoted (@ char in it), thus my MTA is right, but... Please, am i too strict with this syntax check or this ML is too lax in that (or both)? regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM validity period
Dňa 23. decembra 2023 21:20:22 UTC používateľ John Levine via mailop napísal: >According to Slavko via mailop : >>Plausible deniability is good for cryptographers and lawyers only. For >>rest of world it is hard to find/realize, that private key was published >>(someone must complain). > >Not at all. Check the DKIM key record that validates the signature on this >message. Interesting usage of n= tag ;-) Yes, it is better than nothing and simplifies task to find published keys, if one will check the record's value. Perhaps adding standardized tag with URI for this purpose can help with teaching users and/or admins to publish them, something as kpu= (aka Key Publish URI). Please, how many verification tools will show that by default? Are you preserving all old records (selectors) in DNS? And if yes, do you clear (revoke) their public key tag? regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM validity period
Dňa 21. decembra 2023 21:26:34 UTC používateľ "Gellner, Oliver via mailop" napísal: >If Google would have published their DKIM private key after it was rotated in >2016, checking the DKIM signature in 2020 would have proven nothing. Yes, checking that signature in 2020 is pointless. But if you checked it before rotation it was fully validated. The all magic then matter only on fact how to prove, when you did the check. I am sure, that you are aware of systems which can prove time of operation, eg. accounting... (again, hard to name them in English for me) But my point was (mostly) not about courties cases, i mean usual users tracking/spying (contacts, shoppings, opinions, etc), where signature is checked once (at receive time), but used/stored forever. And that cannot be solved by rotation nor by publishing nor by any cryptographic method (which i am aware of). Sure, DKIM doesn't identifies individual users, but signed message has significantly higher value than (random/faked) not signed. >Yes, I agree. Because the users have no control over the DKIM signature and >often don’t even know it exists, it would be especially important for large >ESPs to publish their old keys. Try to ask regular users (and not only gmail/outlook/etc) if they searched if his/her ESP published keys. I ask them (from time to time) and i almost always get: "What? DKIM? Keys???" :-) regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] ECDSA DKIM validation?
Dňa 21. decembra 2023 15:05:08 UTC používateľ Alessandro Vesely via mailop napísal: >It seems only (few) small servers dare implementing ed25519. > >I don't understand why. Do you really don't understand that or do you afraid of what is comming into mind? AFAIK: + collaboration of NSA & RSA (and results) is known + question about selection of EC curves are unanswered + no known doubts about Ed curves It seems, that Edward curves are not as good for some parties as are for others, thus they want to preserve current state as long as possible. Perhaps once new Snowden will reveal reason... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM validity period
Dňa 20. 12. o 22:38 Gellner, Oliver via mailop napísal(a): I’m not 100% sure what you mean by „signed forever“, but to change the topic of this thread once more (and still stay on topic for this mailing list): While the DKIM signature of an email will of course exist forever, it can lose its meaning if you regularly switch DKIM keys and publish the old secret keys. That way DKIM still allows for plausible deniability, so this is not really an argument against it. Hard topic to write about in English for me... Plausible deniability is good for cryptographers and lawyers only. For rest of world it is hard to find/realize, that private key was published (someone must complain). And even when one will publish old keys, the signature becomes deniable only after publishing it. If one can prove that message and public key was fetched before private key was published... The one solution can be to publish private keys before start of using them, but that will negate whole DKIM purpose. The worst part is, that this signature is often added without user's knowledge/acceptance, thus it is hard to complain if one don't know/is not aware of DKIM... regards -- Slavko ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP smuggling
Dňa 19. decembra 2023 12:31:11 UTC používateľ Mark Alley via mailop napísal: >Hey all, recently saw this mail server SMTP vulnerability that popped up on >a blog yesterday. Sharing here for those interested. Please, understand i properly, that it is no vulnerabiliy in SMTP itself, but in (some) implementations/servers only? thanks -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DMARC processing
Dňa 19. decembra 2023 15:29:43 UTC používateľ Mark Alley via mailop napísal: >Is that on Github somewhere? I'd be glad to add it to the list. Thanks, but no, it is not published (officially). But if someone (small/personal/family domains) is interested, i can share it. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DMARC processing
Dňa 19. decembra 2023 15:02:15 UTC používateľ Mark Alley via mailop napísal: >https://dmarcvendors.com/#Self-Hosted_Solutions I use own python script (piped from exim), which extracts report's attachment, stores XML in directories (by month) and reports are shown/parsed by nginx and its autoindex & xslt module. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] ECDSA DKIM validation?
Dňa 19. decembra 2023 11:11:28 UTC používateľ Alessandro Vesely via mailop napísal: >Won't any Google insider shred some lite on why a generally technically sound >company lags like that? Especially, when they de facto require DKIM ... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM / slippery slope gmx.de
Dňa 18. decembra 2023 16:00:17 UTC používateľ ml+mailop--- via mailop napísal: >On Mon, Dec 18, 2023, Paul Smith* via mailop wrote: >> Amazon, etc. They send mail pretending to be from someth...@amazon.com. > >That's why DKIM can be useful for those who want to prevent forgeries. From: s...@amazon.com DKIM-Signature: ... d=spammer.com If signature (and related DNS record) is valid, AFAIK that will result in "pass" (by RFC). How that will prevent forgery, please? With DMARC the forgery is another story. >Why should everyone else be forced to do that? IMO for tracking purpose... Either, for good reason -- to track DKIM's domain reputation, or other reason, as signed user@domain is more reliable source than random user@domain (and signed forever). regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Changes to Validity Reputation Data Through DNS
Hi, Dňa 11. decembra 2023 16:52:43 UTC používateľ Tom Bartel via mailop napísal: >Starting March 1, 2024 we will allow up to 10,000 requests per user over a >30-day time period. After 10,000 requests, users must create a MyValidity >account to continue using this free service. You asked for feedback, here is my opinion about that limit with some real numbers. I have personal MTA, with <100 (usually not more than 50) incoming mails daily, thus 10 000 checks per 30 days seems OK. In last 30 days i see ~1 600 accepted mails (not IPs) and ~2 100 rejected mails/IPs and it is relative peaceful 30 days, I will skip MSA's login attempts counts here, where DBL can be usefull too, but for usual 30 days that limit will be enough too. But from time to time, i am target of extortion (or so) wave, it is about 3 000 unique IPs in 1-2 days. I am able to indentify allmost all of them at first attempt and fill IPs to firewall, thus only small percentage of them gets chance to repeat (connect multiple times), usually no more than 3 times per IP. Thus i will guess about 4 000 DBL requests per one that wave. That will result with only 2 (extortion) waves + usual connections per 30 days, and then my server becomes unprotected by this DBL... IMO if you really want to help with security of small (anonymous) MTAs, that limit should be applied only to NXDOMAIN (not listed)/good reputation responses, as no one attack's target is able to limit attack volume. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Outlook.com losing eMail messages and SNDS reporting failures
Dňa 3. decembra 2023 8:58:23 UTC používateľ Thomas Walter via mailop napísal: >I haven't heard about issues like these for a while, but it was also difficult >to recognize them in the past. Unless people expected an email, they didn't >report them as lost. IMO that is expected, one cannot complain about missing of not expected mails ;-) And sometime nor about expected, as even if it is expected, it can be not sent... >Most mailops I talked to expected it to be a spamfilter issue: E-Mails that >got too bad of a score for random reasons were just not delivered, not even >into the spamfolder. Of course, too obvious SPAMs i don't deliver to users at all too, but instead of swallow (blackhole) them, i reject them after data. But perhaps i am doing that wrongly, and i have to learn from MS how to do it better :-P regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail deferrals resolved by transit encryption
Dňa 17. novembra 2023 22:42:58 UTC používateľ Michael Orlitzky via mailop napísal: >> > Google probably wants you to enable STARTTLS, so reducing sending >> > limits for non STARTTLS senders can make sense from Google's POV. >> >> That thread makes me wonder, how come anybody is sending mail without >> STARTTLS now? When all major MTAs do it just by default? > >If you're sending junk from a custom MTA, it avoids a lot of >programming and saves a little CPU. IMO that question was not about sending junk, but about real MTA, and i have the same question, as it is year 10 after Snowden now... I increase score for nonTLS connections for long time and it is very success for usual junk connections. Not enough to reject, but in conjunction with other marks, just great here. And that rule is based exactly on what you wrote... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail deferrals resolved by transit encryption
Dňa 15. novembra 2023 17:50:16 UTC používateľ Omar Thameen via mailop napísal: >Last night, when the deferrals increased to 25-30%, we deployed TLS >for deliveries, and the deferrals immediately went to zero. Please, can you explain, what do you mean by "we deployed TLS for deliveries". regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] valid DKIM-signed email spam-classified @gmail only; correct PASS @ other server recipients ?
Dňa 30. októbra 2023 15:42:35 UTC používateľ "Gellner, Oliver via mailop" napísal: >John and you had that discussion already in >https://list.mailop.org/private/mailop/2023-April/025022.html. The net result >was: Yes, but until now i didn't realize that he is RFC's author (or i forgot that), and that is what opens new questions for me. I will not ask them here, as it is hard for me to formulate them even in my native language and thus i will not try to do it in English at all. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] valid DKIM-signed email spam-classified @gmail only; correct PASS @ other server recipients ?
Dňa 30. októbra 2023 12:01:41 UTC používateľ "L. Mark Stone via mailop" napísal: >If you browse to https://www.rfc-editor.org/rfc/rfc8463 and scroll to the >bottom you'll see the author's name and contact information. > >Things should become a bit clearer then... Yes and no. For me it opens more new questions, than it answers. Anyway thanks. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] valid DKIM-signed email spam-classified @gmail only; correct PASS @ other server recipients ?
Dňa 30. októbra 2023 10:11:11 UTC používateľ John R Levine via mailop napísal: > By the way, have you asked the author of RFC8463 which defines ed25519 > signatures what his opinion is on this? No, i idn't. Please, can you share that? regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] valid DKIM-signed email spam-classified @gmail only; correct PASS @ other server recipients ?
Dňa 29. októbra 2023 18:40:37 UTC používateľ pgnd via mailop napísal: >in each case, the same "dkim=neutral (no key) header.i=..." anomaly is >presence in headers I cannot tell what gmail's "no key" means, but in our country it means, that key cannot be fetched/parsed for some reason. AFAIK the neutral result can be problem with signature syntax too or so... Is that domain the same as you post here from? I ask, because your email was signed only by one key and you mentioned dualsign previously. Did you publish rua address for that domain? There can be more about DKIM... BTW, my Ed25519 keys are reported as failed by gmail's reports or are missing at all (in some report items) -- i didn't care why. If you want be sure, just stay on RSA only for some time, just to see difference. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] valid DKIM-signed email spam-classified @gmail only; correct PASS @ other server recipients ?
Dňa 28. októbra 2023 12:39:59 UTC používateľ pgnd via mailop napísal: >i suspect the culprit is that GMail's mis-handling the ed25519 dkim key, but i >can't verify it since no response from @Google Postmaster. >but, only @gmail recipients seems to be having this issue AFAIK gmail doesn't understand ed25519 DKIM keys (nor other big players). One must do dual sign (my suggestion) or stay on RSA. I didn't notice any problem with dual sign (i do it for ~3 years), except some DKIM checkers, but these big players just ignores unsupported algo. One can see that in rua reports... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Success MiTM attack
Dňa 24. októbra 2023 8:44:49 UTC používateľ Christof Meerwald via mailop napísal: >On Tue, Oct 24, 2023 at 12:17:30PM +0800, Philip Paeps via mailop wrote: >> crt.sh provides a handy service you can poll. >> >> They provide JSON output. > >They also provide an Atom feed you can use with your favourite >RSS/Atom feed reader. If someone is interested with my experience... I abandon the idea of running own certspotter, it consumes significant bandwitch and CPU, i was using older version (run from cron), every its run saturated my 100 Mb/s link for ~10 min (+ more at lower speed) and tooks more than 40 min (on 4 core J3455) to finish, thus pointles to run it more often than hourly. I am not willing to use more powerfull machine (nor dedicated one) for it. Then i took look on crt.sh RSS. It is better idea for my setup (small amount of domains), pooling it every hour will provide near the same result as certspotter, with mutch less bandwitch & CPU (as it provides way to exclude precerts & expired). I tried to parse it with python (feedparser lib) without any problem, i was only surprised, that one have to parse cert (included in feed entry) to get details as validity time or CN/SAN (especially the CN/SAN are not in entry title). The only downside (which i see), is that RSS URL doesn't provide Last-Modified nor ETag headers, thus no way to check without download (and parse), but download size is pretty small, thus it is not important. IMO it must be pretty simple to setup certbot hook, to be able to exclude self issued certs and alert on any other, i will play with that to get something as dedicated feed reader/alerter. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Success MiTM attack
Dňa 24. 10. o 4:04 Ian Kelling via mailop napísal(a): Anyone know how to monitor C-T logs? I looked around a bit and didn't see how to actually do it for let's encrypt certs. I recently installed https://github.com/SSLMate/certspotter Hard to say any opinion yet, as i install it on one my sparse machine with debian old stable, thus somewhat old certspotter version, and it is too soon to know something useful. First result i expect in next week or two, when some of my certs have to be renewed (i don't want to force that). When o tried recent debian's version of it on my desktop, it tooks minimal RAM (~30 MB) and consumes 10-30% of CPU (not permanently, but in waves), thus it is doing something. I will continue to try it... regards -- Slavko ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Success MiTM attack
Dňa 23. októbra 2023 10:26:57 UTC používateľ Jaroslaw Rafa via mailop napísal: >However, all this discussion is hardly related to email, as - as many have >noted - there's hardly any certificate checking at all between MTAs. Do you want to tell, that MUAs communications are not part of email? Do our MTAs works only for self and mails ends nowhere or they provides transport channel for end users and thus end users are what matter? Or all your users still authentificate and sends/reads own mails over plaintext and TLS is important only in MTA-MTA? As someone other pointed, MUAs doesn't do DANE, nor SCT, nor anything extra to check certs. AFAIK support of SCRAM+ auth is not common (if any). In other words, that XMPP incident is fully applicable to email and it is possible to intercept your users connections and one can only very little to do, to avoid that. Mary: the server authentication is required part of TLS, thus that was success break of TLS. As with the chain, the TLS is only as secure as its individual parts are... Yes, it is nothing new, and yes, the server's auth was success due valid (but rogue) certificate. That cert was issued due MiTM, that is known problem too, but then it can be insufficience in ACME (or PKI), but anyway it shows as can be TLS breaked. AFAIK in the TLS 1.3 significantly reduced amount of cipher suites (beside other), thus it significantly reduces possibility to use of weak ciphers, or opposite, increases encryption security. But the TLS is (or should be) not only about encryption. The question, which comes into my mind is, if ommiting other parts of TLS was not intended... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Success MiTM attack
Dňa 22. októbra 2023 19:18:33 UTC používateľ Jeroen via mailop napísal: >...most MTAs and MUAs support it out of the box. Is list of these availeble somewhere? regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Success MiTM attack
Dňa 22. októbra 2023 12:50:52 UTC používateľ Philip Paeps napísal: >Note that, as far as email is concerned, plaintext downgrade attacks are much >more likely than fraudulent certificates. Hmm, and what about MUAs? regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Success MiTM attack
Hi all, while not directly about email, recently was published details about success MiTM attack against XMPP server, the attacker was able to decrypt TLS communication without notice (from both sides, the server and client) and was success for at least three months, see https://notes.valdikss.org.ru/jabber.ru-mitm/ In short: The attacker used valid LE certificate (requested by self) to intercept traffic. The victims was services hosted on Hetzner and Linode and it seems as Germany government's action (not confirmed, but if true, it will never be). IMO, that attack can be success on any TLS service (including email) and for any place (clouds, own, ...), thus it is worth to be aware of it, as your service can be not as private as one can think. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Recent increase in GMail 421-4.7.28 responses
Ahoj, Dňa Fri, 6 Oct 2023 12:17:31 +0200 Slavko via mailop napísal: > Dňa 6. 10. o 9:39 Marco via mailop napísal(a): > > > Have you tried to inform the postmaster of them to notice about the > > problem? > > Not yet, if problem will persist for more days, i will try it. I send mail to postmas...@github.com, no response after ~week, except immediate (i guess automated) reply, that DMCA or term violations have to be reported via web form... Please have i contact them via some other address? regards -- Slavko https://www.slavino.sk pgp7uiSgnn4EH.pgp Description: Digitálny podpis OpenPGP ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] abuse.ch RPZ syntax error
Hi, recently i noticed, that one RPZ from abuse.ch floods my logs about syntax error in it. As i contributed to improve its RPZs syntax some (long) time ago, i go to their site to find email address as previously, to report that. I found no email address but link to contact form at spamhaus site. I was surprised, that i have to fill as many personal information, without which the form cannot be send. Interesting! Are they more interested in my personal details as they are in fixing own errors? Seems that yes... I will not fill it, not right, nor fake, i can live without that entry and with some extra lines in logs, and perhaps without that RPZ at whole as i will never fill random form which asks too many details... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] fastmail and sender score snafu
Dňa 9. 10. o 8:44 Kirill Miazine via mailop napísal(a): The reason for a long retry is that I have to manually decrypt mailstore partition in case of server reboot. Exim would accept the message, but defer delivery until the mount appears. I wanted to have some time in case of a reboot and me not being easily available to mount the partition. Consider to spend some time to setup auto decrypt on boot, doing that manually has little security enhancement on servers, as once decrypted, the content is available to OS and thus to potentional attacker too (the only restrictions are access rights). When you store decrypt key on separate disk (eg. USB stick), you are safe even after disk replace... regards -- Slavko ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] fastmail and sender score snafu
Dňa 8. októbra 2023 12:26:41 UTC používateľ "Marco M. via mailop" napísal: >> 550 5.1.1 : Recipient address rejected: User >> unknown in virtual mailbox table > >That is the right way to deal with that. Except that who know what "virtual mailbox table" means... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DMARC report rejections - was Re: Recent increase in GMail 421-4.7.28 responses
Dňa 6. októbra 2023 13:29:36 UTC používateľ Bernardo Reino via mailop napísal: >This is unrelated, but yes, I believe DMARC considers that when deciding >when/whom to send the reports. You can omit the believe, rspamd does that checks. i have mentioned gmx.* domains in noReportSend list due that (beside others)... It has other bug with opposite efect. If one send emails from subdomain, and that subdomain has own DMARC record (what is good practice IMO), rspamd will try to use base domain's record to send reports. Thus reports can be not send, eg. if base domain has not DMARC record at all. But it was addressed recently and i hope that will be fixed in next version... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Recent increase in GMail 421-4.7.28 responses
Dňa 6. 10. o 9:39 Marco via mailop napísal(a): Am 06.10.2023 schrieb Slavko via mailop : But this is not usual SPAM with fake or misconfigured rua mailbox, it is domain (github.com) where i send reports for long time and only last days it returns NDR... Have you tried to inform the postmaster of them to notice about the problem? Not yet, if problem will persist for more days, i will try it. regards -- Slavko ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Recent increase in GMail 421-4.7.28 responses
Dňa 5. 10. o 9:58 Bernardo Reino via mailop napísal(a): I have the same issue. Unfortunately there's a lot of servers which request DMARC reports, but then outright reject them (or use an invalid address). My list of no_dmarc_reporting_domains.txt (in RSPAMD) keeps growing, slowly. But this is not usual SPAM with fake or misconfigured rua mailbox, it is domain (github.com) where i send reports for long time and only last days it returns NDR... Its settings is strange in result, as they ask report and then refuse to delivery it. regards -- Slavko ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Recent increase in GMail 421-4.7.28 responses
Dňa 2. 10. o 18:34 Brandon Long via mailop napísal(a): I've raised a bug to take a look, this looks like a too broad dkim replay rule. I am not sure if that is the same, but in last two days i see these bounces from github's DMARC rua address for my DMARC reports: ** Message blocked ** Your message to dm...@github.com has been blocked. See technical details below for more information. The response was: Message bounced due to organizational settings. The latest one contains in message/delivery-status (if that helps): Reporting-MTA: dns; googlemail.com Received-From-MTA: dns; prvs=064225bada=dmarc_rp...@slavino.sk Arrival-Date: Wed, 04 Oct 2023 18:21:05 -0700 (PDT) X-Original-Message-ID: <84e154c2366c2...@primex.skk> Final-Recipient: rfc822; dm...@github.com Action: failed Status: 4.4.2 Diagnostic-Code: smtp; Message bounced due to organizational settings. Last-Attempt-Date: Wed, 04 Oct 2023 18:21:06 -0700 (PDT) regards -- Slavko ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Zero-day RCE for exim - whacky stats?
Ahoj, Dňa Sat, 30 Sep 2023 10:19:01 +0100 Simon Arlott via mailop napísal: > "< jgh> one's in the resolver library. I find it questionable that > it's being raised against Exim, as if we have to protect ourselves > against a library. But AFAIK it's still open. > > < jgh> whatever the system resolver library accesed via res_search() > is" Just to clarify, that are citations of one exim's dev from IRC... regards -- Slavko https://www.slavino.sk pgpAuyOv_9oHZ.pgp Description: Digitálny podpis OpenPGP ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Authentication Bounces by Gmail
Dňa 21. 9. o 9:27 Gellner, Oliver via mailop napísal(a):
The bugs don't have to be security related, they just lead to wrongly computed DKIM signatures,
because some implementations applied the steps defined in the RFC for the relaxed canonicalization
in a wrong way or wrong order or whatever. For example as reported on this very list ("We
already found some interesting bits, like [...] mail-in-a-box using relaxed/simple for DKIM, which
breaks signature validity on long To: headers")
https://list.mailop.org/private/mailop/2023-February/024443.html or with Ciscos appliances which
"fail signing and verification messages with an empty body on relaxed canonicalization"
(bug ID CSCvh84754, but not publicly visible).
I'm not arguing against the relaxed canonicalization, just saying that it is
merely a workaround for the quirks in different MTAs and the actual solution
lies at fixing the behavior of those MTAs.
That is pointless.
Any software can have bug, any verifier can have bug, any hash library
can have bug, any MTA can have bug, any router can have bug... Yes bugs
was here, and will be here. Some are fixed over time, some fixes
introduces new bugs, some stays here for years...
Simply, we all are doing mistakes, including HW/SW devs. Bugfree
computers are science fiction (or PR).
regards
--
Slavko
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] Increase of SSL/TLS errors
Ahoj, Dňa Tue, 12 Sep 2023 12:28:13 +0200 Camille - Clean Mailbox via mailop napísal: > └─# openssl s_client -connect mx.clean-mailbox.com:25 -starttls smtp I can do TLS1.0, TLS1.2 & TLS1.3 handshake with your server and GnuTLS reports certificate as valid, thus the certificate itself seems to not be the root of problem. Perhaps some administrative restrictions on sender side... regards -- Slavko https://www.slavino.sk pgpazp7ylUKeZ.pgp Description: Digitálny podpis OpenPGP ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Increase of SSL/TLS errors
Ahoj, Dňa Tue, 12 Sep 2023 09:25:59 +0200 Geert Hendrickx via mailop napísal: > The reason is likely the certificate itself, not the chain; this > server offers (only) an ECC certificate, and while the vast majority > of clients are compatible with this today, some still only support > RSA. Yes, i can confirm this. My MX's stats shows that one sender still requires RSA. Unfortunately it is my bank, thus i use dual certs ;-) In other words, the MX is only one my service with dual certs. When i start to use EC, i had dual certs for MSA too, but after some time, i abandon the RSA, as all clients was happy with EC... regards -- Slavko https://www.slavino.sk pgpV03nFlqpEL.pgp Description: Digitálny podpis OpenPGP ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Increase of SSL/TLS errors
Dňa 12. septembra 2023 6:18:56 UTC používateľ Camille - Clean Mailbox via mailop napísal: >Also I think it's normal that the client doesn't like the answer of my servers >if the client tries to initiate a SSLv3 connection, as I've disabled it in >Postfix. While i am not familiar with postfix (and its error reporting), the openssl errors can be really confusing. If error message contains sslv3, that can be not indication that SSLv3 was initiated, but only (old) function name which process particular cipher(suite). Do not forget, that TLS up to 1.2 shares some cipher(suite)s with SSLv3. IMO, one cannot be sure without some debug, eg. packet capture, or so. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Increase of SSL/TLS errors
Dňa 12. septembra 2023 6:12:16 UTC používateľ "Taavi Eomäe via mailop" napísal: >No. The chain may contain an expired root certificate. A client must only >validate the chain until the first trusted root. LetsEncrypt's should be >trusted first, certificate chain must be validated until that and accepted. AFAIK, modern openssl versions yes, but old (<1.0.1 or so) will fail... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Legit-looking mail to the wrong address with no unsubscribe
Dňa 26. augusta 2023 11:29:34 UTC používateľ Alessandro Vesely via mailop napísal: >On Fri 25/Aug/2023 23:12:56 +0200 postfix wrote: >> users either underuse, or overconsume. In both cases they are paying more >> than what a market without subscription would do. > >Aha, so that's why they tend to give the wrong address... Or people simple do not want to share own email, as it is not related for delivery, but required by the form. Thus they fill semi random email like string. This will prevent to receive (and bother with filter/delete) a) tons of marketing spams and b) tons of real spams after compromise, etc... And, from time to time, that random email can be real. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [STATE of the UNION] Tails from the trenches of the spam auditing team..
Dňa 25. augusta 2023 16:01:42 UTC používateľ Michael Orlitzky via mailop napísal: >In short: cheap implies bad but bad doesn't imply cheap. Yes, Windows is cheap. But Linux is even free, thus it must be really, really bad... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [STATE of the UNION] Tails from the trenches of the spam auditing team..
Dňa 24. augusta 2023 11:10:48 UTC používateľ Graeme Fowler via mailop napísal: >On 24 August 2023 11:12:07 Jaroslaw Rafa via mailop wrote: > > >> If it is just a random netblock of some ISP that just happens to contain >> some spamming IPs (even a lot of them) inside - no, never block the netblock >> as a whole. > >In all the years I've been running mail systems (which to my great >astonishment is now greater than 25!) I've used a variety of netblock sizes >and occasionally entire AS numbers in outright blocks. IIRC, Jaroslaw have bad neighbors... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] hotmail.com SPF forgot IPv6
Dňa 21. augusta 2023 14:51:14 UTC používateľ Al Iverson via mailop napísal: >The problem is that even if you have DMARC in place, it is VERY easy >to configure SPF checking so that SPF-failing mail is blocked at the >edge...you never get far enough to denote DKIM passing. Having >accidentally configured OpenDKIM and Python-PolicyD-SPF this way >myself in the past, I imagine others likely have to, and not >everybody's smart enough to notice when the edge cases are getting >weird. > >It also depends on whether or not you want to really rely on DMARC or >not. If so, ~all would stop SPF alone causing a bounce, but still >leave things up to DMARC as far as rejecting or not ... so DKIM would >be considered. Assuming it's all configured correctly on the receiving >side. So, ~all is the way to go given that if done in conjunction with >DMARC, you're still telling the world to reject faked mail, but in a >slightly more safe manner. IMO you are perfectly describe, what i tried to point some time ago. The sender cannot reliable satisfy both, the receivers doing standalone SPF (or SPF before DMARC) and receivers doing full DMARC. If one use -all, then those doing SPF rejects can reject valid mails with DMARC pass (+DKIM). If one use ~all, those not doing DMARC will not reject fake senders... And that all just because checking of SPF is as easy (lightweight). AFAIK, it is clearly mentioned in DMARC FAQ (don't do SPF action before DMARC discovery), but for some reason (unknown for me) that is missing in RFC. IMO, the DKIM + DMARC is more robust way to prove mail source, than SPF itself. To satisfy SPF one can simple use own MAIL FROM, really ease for attacker, more hard in legitime indirect mail flows. For that, i check standalone SPF at MAIL/RCPT stage only as part of scoring, and apply it only latter, and only if no DMARC record was discovered (or if DMARC policy is p=none). In other words i invest some resources to satisfy, what sender asked. But my MTA is too small to change anything... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM AUID and subdomains
Dňa 21. augusta 2023 7:44:45 UTC používateľ Alessandro Vesely via mailop napísal: >Are you actually moving email addresses to a subdomain? No, no changes in mail, only in DKIM. >It is also possible to set: > > DKIM-Signature: ... d=sub.example.org Yes, that i used, and that is what i want to avoid -- to maintain separate DKIM record/key for any subdomain. The per subdomain reputation is not needed, even IMO not wanted, due low traffic -- IMO nobody will build reputation for ~10 mails per year from subdomain... What i was not sure, if the i= is used for something or not. Or if it is know that someone go behind DKIM and chains d= with From: by same way... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM AUID and subdomains
Dňa 20. augusta 2023 19:35:35 UTC používateľ John Levine via mailop napísal: >It's only useful as documentation for the sender in case you get a >message back in a complaint. I add it but there's no need to do so. Ok, thanks. -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] DKIM AUID and subdomains
Hi all, i recently start to sign subdomain's (no bulk, nor mass, nor advertising, etc) mails by parent (main) domain key, mostly to simplify DNS setup, thus mails looks eg.: DKIM-Signature: ... d=example.org From: That works and AFAIK it is permited/mentioned in RFC and IMO have to work with DMARC's relaxed alignment. Now i think about DKIM identity (i=) tag in signature. I search across Internet and i found very little (near to zero) info if it is useful. I even found DKIM ML thread (~10 years old), where it was suggested to remove it from RFC at all (which doesn't happen). The only relevant part, which i found, is its usage with t=s tag/flag, but i didn't setup any t= value, thus that must not affect me. Please, is adding this i= tag into signature (eg. "i=@sub.example.org") useful and is it used for "something"? Or it is only historical fragment and it is not worth to bother with it nowadays? regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Guide for setting up a mail server ?
Hi, Dňa 14. júla 2023 18:36:53 UTC používateľ Grant Taylor via mailop napísal: >With this in mind, my opinion is that hard and fast is often better / less >problematic in the long term. I guess, that by "hard and fast" you mean reject early, thus in case of SPF as response to "MAIL FROM", right? Yes, that is big advantage of standalone SPF. >The DMARC implementations that I use don't do the SPF nor DKIM checks >themselves. Instead there are other independent filters that do those before >the DMARC filter and the DMARC filter uses the results from those tests. I was not clear enough, sorry. I tried to "repair" that by last sentence of this section, but i see that it doesn't solved it, thus i will try to rephrase it: Of course, it doesn't matter when the SPF/DKIM checks are done, if as part of DMARC or as separate checks. What i meant is, when result is applied... >I'm fairly certain that SPF checks significantly pre-date DMARC. Yes Of course, some receivers can still do SPF only, in mean no DMARC at all (i skip all other combinations). Beside that it is (IMO indirectly) mentioned in RFC, it is IMO common (not only in email environment) to not implement "new" techology immediately. Anyway, i would expect something as this in RFC: DMARC compliant receiver MUST NOT apply standalone SPF results, unless DMARC's policy is p=none. In case of p=none, they SHOULD/MAY apply standalone SPF. Beside my poor English, it will be then clear for both sides, what receivers can do and what senders can expect... For now receiver have freedom and sender can only guess, and that is not about interoperability... >There's businesses hosting their own email which only effects them and then >there are businesses that host other people's email as a service. I think the >two are quite different in many regards. E.g. Google does things quite >differently for @google.com email than their Gmail product does for @gmail.com >email. GSuite hosted email is even more different. But they are not doing that as differently, both, the @gmail.com and @google.com, connections are here over TLS1.3, in both directions. I didn't inspect their settings in more depth. >Sometimes MTAs are forced to modify messages. I usually see it when the MSA >or upstream MTAs support 8BITMIME and downstream MTA(s) don't. Thus the last >8BITMIME supporting MTA *MUST* convert to 7-bit messages if the sender >utilized 8BITMIME. IMO that modification is fully acceptable nowadays, i meant another modifications, eg. to qualify To:/From: addresses, add Date:/Message-ID: headers, etc. BTW, our alphabet has 43 letters, ASCII-US was not enough for us from start. Exim is 8bit transparent, even without asking it, i didn't meet server requiring to ask that (except postfix requiring to ask SMTPUTF8 due 8bit subject, but that was problem of friend's PHP site). While i know whole story behind email's 7bit, i do not understand why that problem still exists, but that is out of our discussion. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
