Am 24.04.2024 um 10:08:53 Uhr schrieb Marco Davids via mailop:
> However, the IPv6-address in the error below resolves to two names:
>
> ;; ANSWER SECTION:
> 0.0.7.0.0.0.0.0.0.0.0.0.0.0.0.0.b.1.6.2.3.0.4.f.1.1.1.0.1.0.a.2.ip6.arpa.
> 3165 IN PTR
Am 22.04.2024 um 09:28:20 Uhr schrieb Paul Menzel via mailop:
> The SPF of molgen.mpg.de has `~all` (soft fail):
>
> $ dig txt molgen.mpg.de +short
> "v=spf1 ip4:141.14.0.0/16 ~all"
>
> and I would expect `~all` to result in Google Mail not rejecting the
> message, when another
Am 19.04.2024 um 12:21:47 Uhr schrieb Sebastian Arcus via mailop:
> I would have to look further into this, but I was under the
> impression that Exim uses the VRFY command for callout verification?
Most sites have disabled that, and implementations of Exim are known
that use RCPT TO. Stop using
Am 18.04.2024 schrieb Sebastian Arcus via mailop :
> On 18/04/2024 13:44, Marco Moock via mailop wrote:
> > Am 18.04.2024 schrieb Sebastian Arcus via mailop
> > :
> >> The mention of HELO is what threw me off - and I kept on thinking
> >> that it's not possi
Am 18.04.2024 schrieb Bill Cole via mailop :
> I can't say that Spamhaus lists IPs that engage in the abusive
> practice of remote sender verification but I would be happy to hear
> that they are doing so and CSS+XBL listing is a reasonable expression
> of that sort of world-hostile behavior.
If
Am 18.04.2024 schrieb Sebastian Arcus via mailop :
> The mention of HELO is what threw me off - and I kept on thinking
> that it's not possible, as port 25 is blocked. But I completely
> missed the point that even authenticated connections on 587 will use
> HELo - I think?
They require auth, so
Am 18.04.2024 schrieb Sebastian Arcus via mailop :
> However, if keeping outbound port 587 open turns out to be causing
> real headaches, I could take a look at revising the existing approach.
If that is an issue, they should inform your ISP about the abuse and
that should forward that to you,
Am 18.04.2024 schrieb Sebastian Arcus via mailop :
> A few days ago I started having issues with the public IPv4 address
> of one network I look after ending up on the Spamhaus XBL and CSS
> blacklists.
https://www.spamhaus.org/blocklists/exploits-blocklist/
Listings there are not related to
Am Wed, 10 Apr 2024 07:14:41 -0700
schrieb Russell Clemings via mailop :
> There was an outage starting Sunday on indra.net and although they
> say it's up again now, I'm still getting no response from their
> nameservers and mail for their users (or user, as I see only one) is
> still stacking
Am 22.03.2024 um 19:07:00 Uhr schrieb Michael Irvine via mailop:
> NOTE: IPs are dedicated from SendGrid
Sendgrid is a company that at least doesn't care about abuse from their
systems.
Assume that they are listed at various dnsbl or manually blocked by
postmasters.
--
Gruß
Marco
Send
Am 16.03.2024 um 17:44:09 Uhr schrieb John Levine:
> It appears that Marco Moock via mailop said:
> >> But who will follow 13 years old standard... ;-)
> >
> >When Google and Co. make DKIM mandatory, this will be hard, because
> >those messages are likely to
Am 16.03.2024 um 20:31:33 Uhr schrieb Slavko via mailop:
> 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
Hello!
Since enabling DKIM outgoing and verify incoming, I notice the DKIM
fails (although, I don't reject).
One of them is this mailing list.
Is there a reason for changing the content of the mail AND keeping the
original DKIM signature?
Wouldn't it be better to remove that and add mailop's
Am 14.03.2024 um 11:58:24 Uhr schrieb Slavko via mailop:
> 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,
Am 16.03.2024 um 13:08:52 Uhr schrieb Benny Pedersen via mailop:
> Marco Moock via mailop skrev den 2024-03-16 12:46:
> > Am 14.03.2024 um 10:28:13 Uhr schrieb Julian Bradfield via mailop:
> >
> >> Their latest daftness (latest in my noticing it, anyway) is
> &g
Am 14.03.2024 um 10:28:13 Uhr schrieb Julian Bradfield via mailop:
> Their latest daftness (latest in my noticing it, anyway) is
> rate-limiting on the basis of too many recipients for a single
> message-id, where "too many" varies from 6 to 30. You'd think they'd
> never heard of organization
Am Thu, 14 Mar 2024 10:04:42 +0100
schrieb Marco Moock via mailop :
> Although, I send only a very small amount of mail to Google. Do they
> use that to calculate the rate?
I got that error again. I participated in some mailing lists with
gmail subscribers.
One of those subscribers has a f
Am 14.03.2024 um 16:15:11 Uhr schrieb ml+mailop--- via mailop:
> Looks like there is no default (maybe your OS uses some startup
> command with a "default" retry time).
That is the case.
It is a cronjob that runs every 20 minutes.
That applies to Debian and most likely to Ubuntu too.
--
kind
Am 14.03.2024 schrieb Julian Bradfield via mailop :
> On 2024-03-14, Marco Moock via mailop wrote:
> > sendmail tried to deliver it 20 times during the night - this
> > morning I deleted the mail from mqueue.
>
> That's a fairly aggressive retry strategy.
That is th
Am 14.03.2024 schrieb Julian Bradfield via mailop :
> They don't reject with 5xx because they're not rejecting that message,
> they are rate-limiting you or the network you're on.
> I get this often, because one user forwards their mail to
> gmail, including all the spam. Google rejects the spam,
Am 14.03.2024 schrieb Stefano Bagnara via mailop :
> On Thu, 14 Mar 2024 at 10:09, Marco Moock via mailop
> wrote:
> > Mar 14 06:54:17 srv1.xyz sm-mta[498019]: 42DK6aqc496761:
> > to=, delay=09:47:40, xdelay=00:00:03, mailer=esmtp,
> > pri=5370980, relay=alt4.gmail-sm
Hello!
Yesterday I replied somebody directly on debian-users (he uses a crappy
mailer and sends to the author and the mailing list...).
Gmail doesn't like this mail, but rejects it with a tempfail. I've now
deleted it from mqueue.
Mar 14 06:54:17 srv1.xyz sm-mta[498019]: 42DK6aqc496761:
to=,
Am 14.03.2024 schrieb Cyril - ImprovMX via mailop :
> But in my opinion, moving the needle upward by not accepting
> deprecated versions would force those users to be compliant and
> improve the general security.
Most of them will simply fall back to no encryption. That is the
default setting
Am 13.03.2024 um 17:06:03 Uhr schrieb Johann Klasek via mailop:
> Is it not condescending to question to reason why someone has not
> already the opportunity to switch to TLS 1.2?
Can you name some reasons?
I currently don't know one.
--
Gruß
Marco
Send spam to 1710345963mu...@cartoonies.org
Am 13.03.2024 um 10:43:27 Uhr schrieb Bill Cole via mailop:
> Without one, disabling them is a cargo-cult praxis that is worse than
> any false sense of security provided to oblivious peers who can't do
> TLSv1.2 or better.
What are legitimate reasons today not to use TLS 1.2 or 1.3?
--
Gruß
Am 13.03.2024 um 10:43:27 Uhr schrieb Bill Cole via mailop:
> Without one, disabling them is a cargo-cult praxis that is worse than
> any false sense of security provided to oblivious peers who can't do
> TLSv1.2 or better.
What are legitimate reasons today not to use TLS 1.2 or 1.3?
--
Gruß
Am 13.03.2024 um 08:39:33 Uhr schrieb Michael Orlitzky via mailop:
> Whose sense of security is improved by sending those messages in
> plaintext?
None. If you want to transfer something making eavesdropping possible,
encrypt the content end to end. Everything else must be considered as
Am 13.03.2024 um 11:28:18 Uhr schrieb L. Mark Stone via mailop:
> FWIW, our view is that poor encryption can be worse than no
> encryption, as it can give the participants a false sense of
> security. This seems like a good move to us.
>
> We have configured Postfix in our Zimbra MTA servers to
Am 13.03.2024 um 12:04:22 Uhr schrieb Matus UHLAR - fantomas via mailop:
> Iirc sendmail honored these settings, postfix hasn't.
8.18.1/8.18.1 2024/01/31
OpenSSL version 3.0.x is supported. Note: OpenSSL 3 loads by
default an openssl.cnf file from a location specified
Am 13.03.2024 um 08:39:17 Uhr schrieb Tobias Fiebig:
> Which is part of the reason for this mail; Are there any best
> practices beyond what i did above for preventing this form of abuse
> (apart from 'wanna do "Captcha & Cloudflare" tonight' ?
Create a random generated mail address that the
Am 12.03.2024 um 19:19:50 Uhr schrieb Tobias Fiebig via mailop:
> over the past 2-3 weeks, I saw a slightly more filled queue for email-
> security-scans.org; A lot of users seemed to start tests, but never
> received the corresponding test mails; In most cases, the ESP hat
> shutdown delivery to
Hello!
We had the situation that we got mail that wasn't RFC-compliant and our
listserv rejected it.
MAIL From:
Listserv replies to the From: header and not to the Return-Path.
It doesn't see MAIL FROM because the mail is being piped to the
application, but it could use Return-Path.
MAIL FROM:
Am 08.03.2024 schrieb Paul Gregg via mailop :
> They do claim to use RBLs, but my OVH IP isn't on any RBLs (not even
> uceprotect-L3 amazingly right now) - and based on my home 'DUL' IP not
> being able to connect, they're certainly using RBLs on port 25.
Can you test 53/udp and 53/tcp on their
Am 08.03.2024 schrieb Stefano Bagnara via mailop :
> I can't even lookup the domain as I cannot reach their NS, but the
> same happens even if I try to ping their email server IP address:
I can reach them properly from AS8820.
Do you get any ICMP messages back?
tcptraceroute 194.97.8.138 53
Am 04.03.2024 um 02:25:08 Uhr schrieb Gareth Evans via mailop:
> From
>
> https://www.mailop.org/best-practices
>
> "Having SPF for your own domains is usually considered a weak signal
> ..."
>
> Eh?
That sounds completely wrong. SPF makes forging the MAIL FROM: address
much harder. Some
Am Sun, 03 Mar 2024 17:23:22 +
schrieb Gareth Evans via mailop :
> I am curious about the exact mechanism of PTR checks, and couldn't
> find it in RFC5321 so presume it's not actually part of SMTP.
Most server require that the PTR points to a domain name like
mail.example.org and that has
Am Tue, 27 Feb 2024 16:54:31 -0600
schrieb Jarland Donnell via mailop :
> Is it plausible that Google had a temporary issue reaching your DNS
> servers?
If so they should give an error message that says that.
___
mailop mailing list
mailop@mailop.org
Am Fri, 23 Feb 2024 13:39:46 -0800
schrieb Mark Fletcher via mailop :
> My question to you all is, do you think that the
> List-Unsubscribe=One-Click header is supported well enough these days
> such that I can replace the one-click unsub link in the message
> bodies with a link that requires
Am Fri, 16 Feb 2024 14:49:12 -0600
schrieb Jesse Hathaway via mailop :
> Does probing for recipients work these days, is it considered abusive?
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.
Some dnsbl (e.g.
Am 12.02.2024 um 15:35:30 Uhr schrieb Sebastian Nielsen:
> >>If you forward spam (automatic forwarding), you will be listed as
> >>the spammer because even DKIM is valid.
> That’s why you do spam filtering in the forwarding server.
There is no 100% solution for that and even a small amount of
Am 09.02.2024 um 13:59:57 Uhr schrieb Andy Smith via mailop:
> When these people are your paying customers, or you are being paid
> to get email to these people, there is limited up side in berating
> people about their choice of mail service. A fact which of course is
> used and abused by the
Am 09.02.2024 um 22:06:05 Uhr schrieb Sebastian Nielsen via mailop:
> Or people could stop forwarding emails in idiotic ways, because when
> you forward an email, you are actually forging the original sender.
>
>
> Ergo, if you forward a email from genuineu...@genuineserver.com to
>
Am 10.02.2024 um 15:52:22 Uhr schrieb Andre van Eyssen:
> On Fri, 9 Feb 2024, Marco Moock via mailop wrote:
>
> > Outlook supports that and knowing about it is a question of
> > training.
>
> I'd like to suggest that understanding of email is declining in the
> ge
Am Fri, 09 Feb 2024 22:09:45 -0800
schrieb Hal Murray via mailop :
> I expect that there would be a protocol to handle it. I can't be the
> only one who has thought of this. After a handshke to set things up,
> the sender adds a forwarding header and the receiver verifies that a
> forwarded
Am 09.02.2024 um 18:06:41 Uhr schrieb Slavko via mailop:
> 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...
Outlook supports that and knowing about it is a question of training.
At our university,
Am 09.02.2024 um 08:50:52 Uhr schrieb Scott Mutter via mailop:
> This is part of the issue I have with all of these band-aid solutions
> when it comes to "fixing" the spam problem with email. You're going
> to continue to have these issues with email until people realize that
> they are going to
Am 09.02.2024 schrieb Jaroslaw Rafa via mailop :
> Dnia 9.02.2024 o godz. 07:13:31 Marco Moock via mailop pisze:
> > S/MIME exists and I really don't understand why banks and online
> > shops don't consequently use it.
>
> I must say that my bank is and always was using
Am 09.02.2024 schrieb Julian Bradfield via mailop :
> On 2024-02-09, Marco Moock via mailop wrote:
> > I don't know if any MTA out there supports [DKIM] directly or
> > supports Milter.
>
> Exim supports it, even in the rather old version in Debian 10 that I
> use.
Am 09.02.2024 schrieb Matus UHLAR - fantomas via mailop
:
> It was noted that not using DKIM can be used for preventing of
> forwarding because of legal requirements.
A rather bad solution for that because it depends on the checks of the
receiver of the forwarded message.
Am Fri, 09 Feb 2024 13:17:48 +1100 (AEDT)
schrieb Andre van Eyssen via mailop :
> The bulk of problematic email now -- I see phishing as the concern
> rather than spam that gets easily tagged -- comes with valid SPF and
> is signed with DKIM.
S/MIME exists and I really don't understand why banks
Am Thu, 8 Feb 2024 10:46:51 -0800
schrieb Michael Peddemors via mailop :
> The only way this will stop, is when the network operators are forced
> to be accountable for outbound traffic
dnsbl exists and some lists (e.g. uceprotect L3) entirely list ISPs
that have a huge amount of spammers in
Am Thu, 08 Feb 2024 10:20:50 -0800
schrieb "Randolf Richardson, Postmaster via mailop" :
> > Am 08.02.2024 schrieb Cyril - ImprovMX via mailop
> > :
> > > But forwarding an email from a domain that have DMARC enabled
> > > (with a policy different than "none") could still work if the
> > >
Am Thu, 8 Feb 2024 17:10:57 +
schrieb Andy Smith via mailop :
> Last month there was a complaint on the NANOG (North American
> Network Operator's Group) that changing the subject line of an email
> mid-thread disrupted the way emails are grouped, the implication
> being that the way gmail
Am Thu, 8 Feb 2024 16:33:58 -0500
schrieb Stephen Frost via mailop :
> Agreed- this is an issue and we've seen it too. I've ended up having
> to suggest to some that they remove their SPF DNS entries as that
> actually ends up helping with deliverability, which seems odd but is,
> in fact, true.
Am 8 Feb 2024 21:06:27 -
schrieb John Levine via mailop :
> It is not hard to deliver the mail locally and tell Gmail to poll that
> mailbox and show it with your Gmail, optionally with a tag. You can
> also arrange to send mail from Gmail with your other address and Gmail
> will submit it
Am 08.02.2024 schrieb Jaroslaw Rafa via mailop :
> Dnia 7.02.2024 o godz. 20:51:15 Jarland Donnell via mailop pisze:
> > Nearly 100% of
> > users who forward email do so because they want it in Gmail.
>
> I am always wondering - as Gmail gives so many problems that have been
> discussed
Am 08.02.2024 schrieb Cyril - ImprovMX via mailop :
> But forwarding an email from a domain that have DMARC enabled (with a
> policy different than "none") could still work if the sender signed
> their email with DKIM. Isn't it correct?
That is true. But not all domains have DKIM.
> In order
Am Wed, 07 Feb 2024 20:51:15 -0600
schrieb Jarland Donnell via mailop :
> Is it time to throw in the towel on email forwarding?
I think so.
Every mechanism has its own disadvantages.
> Nearly 100% of users who forward email do so because they want it in
> Gmail.
Which type of users?
Due to
Am 06.02.2024 um 23:50:14 Uhr schrieb Odhiambo Washington via mailop:
> Today morning I woke up to all emails being rejected as I was using
> zen.spamhaus.org in my dnslists.
> Almost all incoming emails - even from gmail.com - were being
> rejected. Did I maybe miss something?
Most likely your
Am 29.01.2024 um 14:05:30 Uhr schrieb Michael Peddemors via mailop:
> And of course, this 'could' be caused by backscatter on their
> servers, if the emails originated from your server ;)
>
> Ensure your domains have SPF records of course, but we need more
> information on the list to determine
Am 27.01.2024 um 13:46:34 Uhr schrieb Gellner, Oliver via mailop:
> If I as a customer or business partner would receive emails which are
> coming from apa...@webserver1.company.tld then I‘d be under the
> impression that this company lost control of their infrastructure.
> But maybe that’s just
Randolf Richardson, Postmaster via mailop schrieb:
Have you inspected the SMTP headers and grepped mail server logs?
Of course.
It comes from the ebay servers and the RCPT TO is root@our.domain.
___
mailop mailing list
mailop@mailop.org
Hello!
Does anybody of ebay reads here?
At work we receive mails from ebay (SPF valid) to an address that isn't
assigned to an account and can't be registered by the ebay user because
he can't access the inbox, it is root@our.domain.
I already called their customer service and they said the
Hello!
At work we are currently deploying DKIM.
Do people here have experience with messages from sub.example.org
signed with d=example.org?
That way is much easier to handle for us because we have a lot of
domains (machines sending with r...@hostname.example.org etc.).
Will Google accept such
Am 24.01.2024 um 21:48:39 Uhr schrieb Grant Taylor via mailop:
> I knew that Google was going to start requiring SPF or DKIM (in
> addition to other sender guidelines [1]. But I thought they were
> starting February 1st, per their own sender guidelines.
IIRC Google starts to require DKIM for
Am 17.01.2024 um 01:47:20 Uhr schrieb Jarland Donnell via mailop:
> 450 Error connecting to 17.57.156.30. Unexpected socket close
m@ryz:~$ telnet 17.57.156.30 25
Trying 17.57.156.30...
Connected to 17.57.156.30.
Escape character is '^]'.
Connection closed by foreign host.
m@ryz:~$
Same here.
Am 09.01.2024 um 12:02:52 Uhr schrieb Paul Menzel via mailop:
> Since a while we noticed unsolicited messages from cloudfilter.net.
Did you contact their abuse desk?
Proofpoint is maybe just selling those servers to customers (that may
have hacked accounts/systems) and doesn't know about the
Am 02.01.2024 um 06:34:27 Uhr schrieb Michael via mailop:
> blocking AUTH from cloud providers that don't quickly respond to
> abuse complaints, is the way to go
Blocking SMTP generally from such providers is considerable if they let
abusers continue to abuse their services. :-)
Am 01.01.2024 um 20:25:54 Uhr schrieb Slavko via mailop:
> 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
Am 01.01.2024 um 15:56:02 Uhr schrieb John Covici via mailop:
> Thanks much -- that version is not in my repository yet, but I will
> keep an eye out for it.
That is a snapshot - a release for testing - and such releases are
normally not in the normal repos of the distributions.
I dunno when
Am 01.01.2024 um 10:17:25 Uhr schrieb Randolf Richardson, Postmaster
via mailop:
> > > On 28.12.2023 at 20:29 Marco Moock via mailop wrote:
> > >
> > > Am 28.12.2023 um 18:15:39 Uhr schrieb Tom Perrine via mailop:
> > >
> > >> Has anyone
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
Am 01.01.2024 um 17:58:47 Uhr schrieb Gellner, Oliver via mailop:
> The vulnerability is not super critical, but it has been fixed only
> for a very small subset of affected systems. All kind of MTAs from
> Postfix to Sendmail, Exim and various proprietary systems are
> affected and the
Am 01.01.2024 um 01:46:44 Uhr schrieb Randolf Richardson, Postmaster
via mailop:
> Is anyone seeing large numbers of dictionary attacks from
> 20.42.100.251 (which is owned by Microsoft)? I'm curious if they're
> engaging in large-scale targeting.
Doesn't have a PTR, so no regular mail
Am 28.12.2023 um 18:15:39 Uhr schrieb Tom Perrine via mailop:
> Has anyone detected or seen any evidence of SMTP smuggling in the
> wild?
>
> I’m trying to get an independent read on how quickly the bad actors
> have (or haven’t) picked up on this, yet.
According to the information I read, it
Am 19.12.2023 um 17:20:20 Uhr schrieb Slavko via mailop:
> Please, understand i properly, that it is no vulnerabiliy in SMTP
> itself, but in (some) implementations/servers only?
According to the stuff I read, sendmail and Postfix (and more) are
affected, for sendmail a patched version exists
Am 17.12.2023 um 10:45:04 Uhr schrieb Benny Pedersen via mailop:
> false, every forwarder changes envelope sender, so if spf should keep
> pass, its the new forwarding host job to ensure this new envelope
> sender have spf working
That depends on the setting of the forwarder. Some organizations
Am 17.12.2023 um 09:28:16 Uhr schrieb Andrew C Aitchison via mailop:
> On Sun, 17 Dec 2023, Marco Moock via mailop wrote:
>
> > Am 16.12.2023 um 16:07:19 Uhr schrieb Jarland Donnell via mailop:
> >
> >> Obligatory: We don't intend to send any email their way t
Am 16.12.2023 um 16:07:19 Uhr schrieb Jarland Donnell via mailop:
> Obligatory: We don't intend to send any email their way that could be
> perceived as unsolicited, but our users do use forwarders and we'll
> never completely match their filters.
If they use forwarders, SPF will fail in the
Am 12.12.2023 um 09:56:00 Uhr schrieb Tobias Herkula via mailop:
> Most likely root cause: "dns.hiskp.uni-bonn.de." does not answer
> queries via UDP,
It also doesn't answer tcp queries, but replies to ICMPv6 echo request.
Sadly, I also don't get an ICMP error message for that.
Check the
Am 11.12.2023 um 09:26:36 Uhr schrieb Kirill Miazine:
> • Marco Moock [2023-12-11 09:13]:
> [...]
> > >
> > > Anyone has any experience with this list or who the operator is?
> > >
> >
> > The latter is something they hide because spammers would threat them
> > otherwise.
>
> Then does
Am 11.12.2023 um 12:04:44 Uhr schrieb Kirill Miazine via mailop:
> The IP belongs to Hetzner which have a full lack of abuse handling.
> A broad range of IP addresses within the block the IP address you are
> requesting about s constantly being abused to spam and scam campaigns,
> and Hetzner
Am 10.12.2023 um 14:27:35 Uhr schrieb Kirill Miazine:
> • Marco Moock via mailop [2023-12-10 11:24]:
> > Am 10.12.2023 um 10:55:21 Uhr schrieb Kirill Miazine via mailop:
> >
> >> The block is quite new, I guess spam.fail operators just took
> >> Hetzner's
Am 10.12.2023 um 10:55:21 Uhr schrieb Kirill Miazine via mailop:
> The block is quite new, I guess spam.fail operators just took
> Hetzner's IP ranges and put in their lists
https://spam.fail/search?ip=65.108.153.125
It really seems that the entire /15 IPv4 net is on the blacklist.
You IPv6
Am 28.11.2023 um 15:15:51 Uhr schrieb Andy Smith via mailop:
> COI is right and proper, no argument from me, but the willingness of
> bad actors to ignore what is right and proper makes it very hard for
> anyone in the same industry to do what is right and proper.
Such companies will land on
Am 27.11.2023 um 11:04:33 Uhr schrieb Randolf Richardson, Postmaster
via mailop:
> > Without a confirmation, everybody can simply subscribe any address
> > and that will be abused.
>
> I agree. What I'm trying to do is convince non-technical
> management to side with taking care to
Am 27.11.2023 um 10:42:58 Uhr schrieb Randolf Richardson, Postmaster
via mailop:
> Many marketing people seem to be terrified of the idea of
> users having to confirm their consent when subscribing to a mailing
> list (e.g., by following a unique link in an eMail message to
> complete the
Am 18.11.2023 um 10:46:52 Uhr schrieb John R Levine via mailop:
> We have a fake estate scam, a fake Celsius crypto scam, and a fake
> Bittrex crypto scam, along with the usual deluge of ads that my users
> don't really want.
>
> I'm trying to remember why I accept any mail from them at all.
Am 11.11.2023 um 10:52:26 Uhr schrieb hg user via mailop:
> Do you have a list of IPs that are known to be used for this legit
> service ?
No, but you can create test accounts and then intentionally use the MS
service to find the networks. The block the entire ASN for login via
SMTP/IMAP.
> My
Am 10.11.2023 um 17:08:33 Uhr schrieb Andrew C Aitchison via mailop:
> Is this new Microsoft version significantly different ?
It is because it isn't that clear like the "import" feature of gmail
for the user.
___
mailop mailing list
mailop@mailop.org
90 matches
Mail list logo
