Re: [mailop] IDNA domain with ß

Dňa 7. októbra 2024 6:42:28 UTC používateľ Viktor Dukhovni via mailop napísal: >One can reasonably take the view that U-labels are largely a matter of >the user-interface (presentation) layer, the *real* domain name is the >A-label form! But users don't directly work with attrleaf names, these

Re: [mailop] IDNA domain with ß

Ahoj, Dňa 5 Oct 2024 16:29:26 -0400 John Levine via mailop napísal: > A domain name is a sequence of labels, with each label being a string > of 65 octets or less. Hostnames are a subset of domain names, where > each label consists only of letters, digits, and hyphens. Yes, from that point of v

Re: [mailop] IDNA domain with ß

Dňa 5. októbra 2024 18:29:10 UTC používateľ John Levine napísal: >Yeah, the python encodings.idna library has never been updated past IDNA2003 >for >reasons I find unpersuasive. If you import the external idna library, which is >maintained by one of the people at ICANN who manage the root zone,

Re: [mailop] IDNA domain with ß

Dňa 5. októbra 2024 13:35:01 UTC používateľ Viktor Dukhovni via mailop napísal: >The ICU library encodes domain names that consist of valid U-labels and >NR-LDH labels to A-labels, labels starting with "_" are neither >U-labels, nor NR-LDH labels, so should not be passed to the ICU library, I f

Re: [mailop] IDNA domain with ß

Hi, Dňa 5. októbra 2024 10:33:27 UTC používateľ Carsten Schiefner via mailop napísal: >would a specifically registered Umlaut-Domain be helpful. One member already send me existing domain, with which i was able to see how these libs works with IDNA, it has not PTR record, but for A record: +

Re: [mailop] IDNA domain with ß

Dňa 5. októbra 2024 8:10:50 UTC používateľ Marco Moock via mailop napísal: >I would volunteer to provide such a domain as subdomain of mine if that >is helpful for you. Thanks a lot, but don't worry, it will be too many work for my 3-4 DNS requests. I only need to see how these libs works with

[mailop] IDNA domain with ß

Hi all, i am playing with IDNA in python and i found, that these IDNA (2003/2008) related things are "underdocumented" in both, the idna library and aiodns/dnspython and there are various problems, which needs try-error game. For now i got some useful results, but i need to test it with real DNS

Re: [mailop] Trend Micro Contact

Dňa 23. septembra 2024 21:52:39 UTC používateľ "Brotman, Alex via mailop" napísal: >It appears as though TM has a segment of our network incorrectly listed as >"dial-up". I'm looking for a contact over there who might be able to resolve >that, and who I can supply with a list of what is curre

Re: [mailop] Ask for commercial smtp gateway

Ahoj, Dňa Sun, 22 Sep 2024 09:14:17 +0200 Bastian Blank via mailop napísal: > UCEProtect lists this ip in Level 2. So this not about the single IP, > but the whole net block (it even tells you, it's about 144.6.0.0/16). > And I found listings in Abusix for adresses within this block by > simple

Re: [mailop] [EXTERNAL] onmicrosoft.com customers forging @microsoft.com addresses for phishing

Dňa 20. septembra 2024 17:17:34 UTC používateľ Michael Wise via mailop napísal: > > X-Forefront-Antispam-Report: ...;SFV:SPM;... > >We have a policy on a per message basis of not blocking anything from leaving >the site, but we do send it out a different pool, and we do try to flag

Re: [mailop] [E] Re: Super dumb gmail request ...

Dňa 27. augusta 2024 15:25:57 UTC používateľ Bill Cole via mailop napísal: >Freemail accounts are free because they provide no reliable value. This has >been understood by many of us for a quarter century. Their broad acceptance >over the years has masked that fact, but it has not changed. Wh

Re: [mailop] Plain connections on SubmissionS port

Dňa 14. augusta 2024 13:48:38 UTC používateľ Dave Crocker via mailop napísal: >Making a distance-sensitive assumption about traffic behavior is a suprisingly >bad idea for anything having to do with the Internet.  Resources and their >uses can be -- and often are -- a long way away and using c

Re: [mailop] Plain connections on SubmissionS port

Dňa 12. augusta 2024 10:37:25 UTC používateľ Lena--- via mailop napísal: >I'm curious: do you get many legitimate connections to tls_on_connect port 465 >(instead of STARTTLS 587)? All (small number) my real users use 465 port. >Do you tell your users how to use 587, 465 or both? I tell them

Re: [mailop] Plain connections on SubmissionS port

Dňa 12. augusta 2024 8:20:20 UTC používateľ Viktor Dukhovni via mailop napísal: >I think it can be rather different for SMTP and SUBMIT services. Of course, i am talking about MSA, thus 465/tcp only in my case. >I'm tempted to propose 30s instead of 300s as still reasonable. It coresponds wit

Re: [mailop] Plain connections on SubmissionS port

Dňa 11. augusta 2024 23:46:43 UTC používateľ Viktor Dukhovni via mailop napísal: >I see some similar traffic (remote disconnects after ~8-30s) on my server: Please, what would be reasonable TLS handshake timeout nowadays? I know, it depends, but anyway i consider 5 min (IMO stanfard SMTP timeo

Re: [mailop] Plain connections on SubmissionS port

Hi, Dňa 11. augusta 2024 15:20:50 UTC používateľ "Scott Q. via mailop" napísal: >I've noticed this maybe 3-4 years ago. Could not tie it to any >legitimate customer or application. Yes, not real users, IPs are mostly from US (hi COMCAST), but othervise from ~60 countries, 219 ASNs... I am more

[mailop] Plain connections on SubmissionS port

Hi all, in recent months i see multiple "idle" connection attempts to 465 port. When i did tcpdump on it, i see that client does success TCP handshake, then nothing is sent over it and finally connection is cleanly closed by client (FIN after ~10 sec). I guess that it is plain SMTP connection to

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

Dňa 26. júla 2024 14:11:10 UTC používateľ "Daniel K. via mailop" napísal: >I've received replies to my online form submissions to GMX suggesting my >similar comments have been passed on to the developers. But I understand >you're on top of this already. Yes GMX has defined xmlns attribute, whic

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

Dňa 25. júla 2024 18:52:51 UTC používateľ "Daniel K. via mailop" napísal: >Any advice? Yust ignore garbage. I have own DMARC reports processor, i initially did it based on RFC rules, but soon i meet not conformant reports. I defined threshold, when i accept it and when i just log (and ignore)

Re: [mailop] Mailserver software

Dňa 17. júla 2024 13:37:23 UTC používateľ Jaroslaw Rafa via mailop napísal: >That's why it's good to develop a habit to use "reply to list" (Shift+L in >good old mutt ;)) and not "reply to all". My android's client(K-9) doesn't support "Reply to list" (my desktop client does it), thus i need to

Re: [mailop] Mailserver software

Dňa 15. júla 2024 21:37:07 UTC používateľ Jeff Pang via mailop napísal: >4. Exim has more built-in features such as Dkim and customized transmap, but >may be hard to setup correctly Hard? Sure, it has not click-click configuration, one must know what he want to setup, and then learn how to set

Re: [mailop] Help with handling backscatter

Dňa 12. júla 2024 20:45:30 UTC používateľ Jesse Hathaway via mailop napísal: >BATV seems like the best solution, but as said in my rely to Mark Alley, >I am a little wary of standing it up, given the lack of maintained open >source milters. I didn't notice which MTA you are using. Exim has tool

Re: [mailop] Help with handling backscatter

Dňa 11. júla 2024 20:01:17 UTC používateľ Jesse Hathaway via mailop napísal: >1. Why are the non-delivery notifications sent to > rather than to ? NDR have to be send to Return-Path of original message, thus it depends what was in its MAIL FROM. IMO including foreign (google) IP range open

Re: [mailop] Domains discrimination

Dňa 11. júla 2024 19:20:23 UTC používateľ John Levine via mailop napísal: >It appears that Ralph Seichter via mailop said: >>Personally, I don't factor the price of domains into the block/pass >>decisions, > >You should. There is a very strong correlation between cheap and bad. Of course, mor

Re: [mailop] Anyone from Namecheap on this list to stop a cat and mouse playing scamer?

Ahoj, Dňa Thu, 11 Jul 2024 08:37:05 +0200 Benoît Panizzon via mailop napísal: > The sender domain usually just got registered before the emails are > sent and is being deleted shortly after. did you try to identify new domains with zrd.dq.spamhaus.net, fresh.fmb.la or fresh*.spameatingmonkey.ne

Re: [mailop] Domains discrimination

Dňa 10. júla 2024 19:31:01 UTC používateľ Faisal Misle via mailop napísal: >https://info.spamhaus.com/botnet-threat-updates IIRC, top abused domain is .com for long time in SH C&C (botnet) stats, i hope that these TLD blockers will be enough brave to block it :-P My server stats confirm that,

Re: [mailop] Amazon SES senders

Hi, Dňa 29. júna 2024 17:08:33 UTC používateľ Al Iverson via mailop napísal: >I'm currently testing using Amazon SES for my outbound list mail. Thanks for reply >Maybe the first nine digits are some sort of client identifier? I am not I checked your theory right now, and i afraid that it is no

[mailop] Amazon SES senders

Hi all, please, is there some logic in AmazonSES sender? I (my user) recently start to get spams with envelope sender in form (last item): 01000190647ae455-a250a7c4-5c6b-4b0d-82a5-94f06382aa1f-000...@amazonses.com Mails has valid "amazonses.com" & "ionixdev.com" DKIM, they has "@ionixdev.c

Re: [mailop] too many bad IP blocked

Dňa 21. júna 2024 13:43:15 UTC používateľ Alessandro Vesely via mailop napísal: >Login attempts don't seem to follow any kind of decent dictionary attack >strategy, as they try random userid/ password combinations, and repeat failed >ones. My devocot's auth daemon (mentioned early) can distin

Re: [mailop] too many bad IP blocked

Dňa 21. júna 2024 11:50:23 UTC používateľ Alessandro Vesely via mailop napísal: >That db currently holds 2,014,973 records. Rather than ipset or single >iptables rules, the IPs are stored on a Berkeley DB. They get blocked by a >few iptables rules ending in -j NFQUEUE. That passes the packe

Re: [mailop] too many bad IP blocked

Dňa 21. 6. o 6:57 Viktor Dukhovni via mailop napísal(a): That said, it seemed reasonable to implement a recent suggestion from the Postfix list and block XBL-listed IPs from connecting to my submission services. This had a rather noticeable effect on the rate of failed SASL probes. The suggest

Re: [mailop] too many bad IP blocked

Dňa 21. 6. o 8:44 Matus UHLAR - fantomas via mailop napísal(a): Not sure about nftables. nowadays both, the iptables & ntables, share the same netfilter code/hooks. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.or

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

Dňa 8. júna 2024 10:36:44 UTC používateľ Alessandro Vesely via mailop napísal: >Yes, as it seems Tobias is going to file a bug against rspamd, I presume you >are going to somehow fix it (unless bugs in email-security-scans are just >decorative.) I have nothing to do with email-security-scans,

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

Dňa 7. júna 2024 14:37:24 UTC používateľ Alessandro Vesely via mailop napísal: >If I were Slavko I'd fix rspamd by adding bug reporting (if it's not already >there) rather than removing 2047-decoding. Are you sure, that you did mean me? I was just curious about IDNA syntax in this case... re

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. re

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 contai

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 serv

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 ar

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

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, th

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

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

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 defin

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 n

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áln

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

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

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 *Transp

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 t

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 possib

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/ __

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? Ope

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/ ___

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 t

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 >

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 Fr

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

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

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 MX

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 e

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

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 o

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

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 m

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

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.

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 del

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 suggest

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 -- S

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,

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,

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 en

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. Hm

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 i

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 i

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

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 redire

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 ___

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 d

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

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 DKI

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,

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 th

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 reconfigu

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 paramet

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"

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 specia

[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 M

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 m

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

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 (

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

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)

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 htt

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 autoinde

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/

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...@ama

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 f

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 com

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 wi

  1   2   3   4   >