Dnia 30.04.2024 o godz. 14:05:00 Stefan Bauer via mailop pisze:
Wow. Indeed. Thank you. The ip is 217.160.0.245 and yes, the complete ASN
is blocked.
On 30.04.24 14:18, Jaroslaw Rafa via mailop wrote:
That's why nobody should treat UCEPROTECT seriously (also due to highly
suspicious behavior
Matus UHLAR - fantomas via mailop
:
DKIM should help as well or even better.
_domainkey.newsletter.syniumsoftware.com produces NXDOMAIN which means domain
keys don't exist.
On 30.04.24 12:22, Mendel Kucharzeck via mailop wrote:
Thanks for your response. DKIM is set up according to the AWS SES
On 2024-04-29 08:02, Mendel Kucharzeck via mailop wrote:
- A newsletter campaign on January, 18th was successful with high
read-rates. DMARC and BIMI were not present during this campaign,
but DKIM and SPF. MAIL FROM domain was amazonses.com
- Another newsletter campaign was send on March 15th,
On Thu, 25 Apr 2024, Paul Menzel via mailop wrote:
Until now we rejected emails from donotre...@invoices.premierinn.de
2024-04-23.log:2024-04-23 17:48:53 194.95.238.12 <22>Apr 23
17:48:53 mgw6-erl postfix/smtpd[744016]: NOQUEUE: reject: RCPT from
On 24.04.24 17:00, Simon Branch via mailop wrote:
Thank you everyone for your input.
After reading the various comments, I decided to try creating a connector
in 365, specifically for emails going to the Gmail domain.
Funnily enough, the emails are now delivered to Google's servers,
On 24.04.24 07:28, Simon Branch via mailop wrote:
For the past 2 weeks, we have been unable to send mails to any gmail users,
nor any email domains hosted on Google's mail servers. We are using
Microsoft 365.
So I assume you send your mail through microsoft/outlook servers, you can't
your
will be valid.
On 22.04.24 10:39, Matus UHLAR - fantomas via mailop wrote:
The (ugly but working) possibility is to rewrite From: address to one
@uni-potsdam.de and dkim-sign that one.
It's the same mechanism this mailing list uses to deliver mail.
On 22.04.24 11:03, Laurent S. via mailop wrote
On 22.04.24 09:28, Paul Menzel via mailop wrote:
A users sends a message to x...@uni-potsdam.de, and the user X there has
a forward set up to their y...@gmail.com address. Now
smtpin.uni-potsdam.de returns a delivery failure from Google Mail:
The following message to was undeliverable.
On 18.04.24 12:22, Sebastian Arcus via mailop wrote:
I am not blocking outbound 587. I usually take the view that some user
devices - such as smartphones - could be configured to retrieve and
send email for their personal email accounts - and need to talk to
other email hosting providers. My
On 18.04.24 11:52, Sebastian Arcus via mailop wrote:
I hope this is within the allowable topics for this list. I tried
searching the archives, but haven't found an answer for the issue
below yet. If anyone could shed some light, it would be very much
appreciated.
A few days ago I started
Julian Bradfield via mailop skrev den 2024-03-31 17:35:
> It also thinks 41.212.32.14 has been very spammy in recent months.
On Sun, Mar 31, 2024 at 8:54 PM Benny Pedersen via mailop
wrote:
oh https://multirbl.valli.org/lookup/41.212.32.14.html dont send email
from pbl listed ips
OP should
Something bad seems to have gained the ability to use that IP...
Dňa 31. marca 2024 15:02:31 UTC používateľ Odhiambo Washington via mailop
napísal:
Not that easy unless there is some recent exploit that I am not aware of.
On 31.03.24 15:18, Slavko via mailop wrote:
Don't seems as
On Mar 22, 2024, at 10:58 AM, Matus UHLAR - fantomas via mailop
wrote:
the result code and the spamhaus search didn't provide any relevant info.
On 22.03.24 16:32, Robert L Mathews via mailop wrote:
Hmmm. Not relevant to you, perhaps, but it may be relevant to someone else
who can help. I
On Thu, 21 Mar 2024 18:40:16 +0100, Matus UHLAR - fantomas via mailop
wrote:
Are there any other checks or measures I can do?
On 21.03.24 13:58, Michael Rathbun via mailop wrote:
What exactly is the Zen result code? There are many reasons for such
listings.
the result code
Hello,
last few days we've had 2 diferent IP addresses listed in SpamHaus ZEN
1. monitoring server which rarely sends e-mail
- to single address in our internal network
- single address of our customer (outside our network)
- got listed after 4 e-mails within one day.
2. nextcloud server which
On 13/03/2024 16:43, Bill Cole via mailop wrote:
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?
On 13.03.24 18:09, Taavi Eomäe via mailop wrote:
If you disable all the weak ciphers
On 12.03.24 23:09, Andrew C Aitchison via mailop wrote:
https://discourse.ubuntu.com/t/noble-numbat-release-notes/39890#tls-10-11-and-dtls-10-are-forcefully-disabled-13
(which is mostly a template) suggests that TLS 1.0, 1.1 and DTLS 1.0
are "forcefully disabled" in the upcoming Ubuntu release
On Sun, Mar 03, 2024 at 05:23:22PM +, Gareth Evans via mailop wrote:
(Error NOERROR looking up 23.24.6.165 PTR,Error Error NXDOMAIN
looking up 23-24-6-165-static.hfc.comcastbusiness.net. A looking up
23-24-6-165-static.hfc.comcastbusiness.net. A,Error Error NXDOMAIN
looking up
On Tue, 13 Feb 2024 at 18:09, Matus UHLAR - fantomas
wrote:
- it has some redundant SPF records:
On 13.02.24 18:26, Stefano Bagnara via mailop wrote:
I'm not aware of issues with redundant SPF records, as long as I stay in
the 10 lookup: what are you talking about?
exactly this, I just have
On 05.02.24 14:56, Stefano Bagnara via mailop wrote:
we are a small ESP and every email sent from our system has SPF+DKIM
authentication from our system and most email also have a second DKIM
signature (one signature with our domain, one with the domain of the
sender).
is bago.org that domain?
Matus UHLAR - fantomas via mailop skrev den 2024-02-13 16:00:
I still think implementing SPF and SRS gives more value than ARC.
On 13.02.24 16:17, Benny Pedersen via mailop wrote:
oh dear, if you really need both spf and srs, your problem is more
deep then linux
OP stated they already do
On 02.02.24 16:26, Kai Bojens via mailop wrote:
Skip SRS and implement ARC for forwarded e-mails. This should
solve all these problems.
On 2024-02-04 23:02:31 (+0800), Matus UHLAR - fantomas via mailop wrote:
Does anyone blindly trust ARC signatures from random domains?
I find it a huge
On 08.02.24 21:51, Archange via mailop wrote:
Sorry if I wasn’t clear, I did not meant alignment when I wrote “require”.
Just that they are implemented and passing.
But indeed I am not sure of the value in SPF passing without alignment
though (in a context of DMARC and DKIM working — outside
On 2024-02-08, Archange via mailop wrote:
[...]
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.
I would have wished that DMARC would require both SPF and DKIM, but now
it is too late for that.
On 08.02.24 05:48, John Covici via mailop wrote:
I have sendmail set up for dkim, I don't see anywhere where you need
anything for dmarc. Right now the opendmarc.conf is just what comes
when you install.
DMARC on domain means setting DNS record in it.
In addition to SPF and DKIM provides
Dňa 7. 2. o 7:29 Odhiambo Washington via mailop napísal(a):
> I have my local instance of unbound resolver.
On Wed, Feb 7, 2024 at 11:32 AM Slavko via mailop wrote:
It can be not enough. Some time ago i noticed, taht my ISP intercepts
(and redirects) all my DNS requests. Check carefully...
these problems.
It appears that Matus UHLAR - fantomas via mailop said:
Does anyone blindly trust ARC signatures from random domains?
On 04.02.24 12:08, John Levine via mailop wrote:
No, but we don't blindly trust an SPF pass (SRS or otherwise) either.
we don't, but we can at least verify
mails. This should solve
> all these problems.
On Sun, 2024-02-04 at 16:02 +0100, Matus UHLAR - fantomas via mailop wrote:
Does anyone blindly trust ARC signatures from random domains?
On 05.02.24 01:27, Byunghee HWANG (황병희) via mailop wrote:
They(DKIM/ARC) are not distinguishing whether
Am 02.02.24 um 16:08 schrieb Mark E. Jeftovic via mailop:
We're having a bit of a theological debate internally on whether to
implement DMARC on our SRS forwarder domains.
On 02.02.24 16:26, Kai Bojens via mailop wrote:
Skip SRS and implement ARC for forwarded e-mails. This should solve
all
29 matches
Mail list logo
