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
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
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
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
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:
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
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
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
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
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
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/
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?
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/
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
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
>
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
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
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
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
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
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,
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
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
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
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
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.
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
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
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
--
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,
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,
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
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.
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
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
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
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
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
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
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,
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
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,
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
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
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
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"
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
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
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
>>(
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
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
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
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)
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
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
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/
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:
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
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
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
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".
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),
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
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/
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
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
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
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
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?
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
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/
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
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 w
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
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
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
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
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
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
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 **
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
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
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
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.
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
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
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
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/
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
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
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
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/
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
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",
Hi,
Dňa 13. júla 2023 23:42:15 UTC používateľ Grant Taylor via mailop
napísal:
>I absolutely think that it's quite possible to apply SPF independently
>nowadays.
Possible? Yes. Expected? Hard to tell... See latter.
>Is it better to fail soft and slow or hard and fast?
From which point of
Dňa 14. júla 2023 7:16:43 UTC používateľ Thomas Mechtersheimer via mailop
napísal:
>I guess he means filtering based solely on the existance of a SOA record.
Of course, that is what this thread about... Thanks to clarify behind me ;-)
>Do you have any numbers that suggest that this specific
Dňa 13. júla 2023 17:41:51 UTC používateľ Marcel Becker via mailop
napísal:
>On Thu, Jul 13, 2023 at 10:35 AM Robert L Mathews via mailop <
>mailop@mailop.org> wrote:
>
>
>> I still think this is a check that's prone to false positives
>>
>
>Or other issues. Yes. That's why we are also helping
Ahoj,
Dňa Wed, 12 Jul 2023 10:04:10 -0500 Grant Taylor via mailop
napísal:
> In my opinion, if a domain's DMARC has a p=none, then you don't
> filter on DMARC. But you still independently apply your site's
> local SPF filtering policy preferably following the sending domain's
> stated SPF
Dňa 12. júla 2023 13:34:42 UTC používateľ Grant Taylor via mailop
napísal:
>I then tried to have my primary client using my primary email system (VPS with
>Sendmail) send a test message to my user at the test domain. That didn't work.
> I think that Sendmail in the MSA role rejected things
Dňa 11. júla 2023 18:23:45 UTC používateľ Grant Taylor via mailop
napísal:
BTW, my English is not best, don't take me word by word, please...
>I suspect that one of the things that makes email harder is that it
>encompasses many other interrelated and interdependent things. So if
>you're
1 - 100 of 313 matches
Mail list logo
