Am 27.08.2024 um 12:56:18 Uhr schrieb Eduardo Diaz Comellas via mailop:
> I think that sending the vacation messages with null sender is an
> standard practise and the best way to avoid loops. I've found no
> problems with any other email providers: only gmail is blocking this
> messages.
On T
On 28.08.24 07:46, Robert Giles via mailop wrote:
So dropping Google Groups entirely: since Google's infrastructure is
"unblockable", I'd suspect keying on a Google Groups-specific header,
but how are you (and other folks) accomplishing this?
I put into local rhsbl:
groups.google.com
googleg
On 2024-06-21 04:53, Jeff Pang via mailop wrote:
given currently I have 3000+ block IPs,
every normal client requests to submission,
the ip will be checked through those 3000+ list,
which slow down the normal client's connection certainly.
On 21.06.24 10:57, Anthony Howe via mailop wrote:
I th
On 21.06.24 07:20, Jeff Pang via mailop wrote:
today I clear up iptables rules, and run fail2ban again.
in half of an hour, it blocked 1400+ IPs.
$ sudo iptables -L -n|grep DROP|wc -l
1407
I use ipset:
REJECT tcp -- anywhere anywhere match-set
block-mail src rej
On 29.05.24 16:29, J Doe via mailop wrote:
Has anyone noticed a recent increase in the frequency of scans of their
mail servers by Censys ?
I am seeing the following in my logs more often:
May 29 01:49:13 server smtpd[50661]: 78d6ab67951b801a smtp
connected address=199.45.154.4
host=sc
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 o
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 AW
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
fra-smtp2.oracleindustry.com[138.1.67.161]:19
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, alb
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 ou
DKIM 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 ma
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 se
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 havi
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 a
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 neighbor
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 hel
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 and the
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 23-24-6-165
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. Hopefull
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 reci
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...
e
all 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
ed e-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 wh
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 th
34 matches
Mail list logo
