On 26/06/2024 19:25, Scott Mutter via mailop wrote:
> What would cause an IP address to not show as being available for Outlook's
> JMRP?
IP addresses can only be a member of one feed. You should be able to see
all JMRP feeds that directly contain an IP address you have access to,
even if you
On 19/02/2024 14:15, Fernando MM via mailop wrote:
> I was wondering if anyone else is also experiencing this type of issue?
It still happens every 10-12 weeks for me. It's getting increasingly
difficult to get them to implement "mitigation".
For example (these are all responses over 24 hours
On 19/01/2024 00:33, Randolf Richardson, Postmaster via mailop wrote:
> The blacklists seem to be blocking mostly the ones that send
> directly from @.onmicrosoft.com addresses, which
> should make filtering easy if we can confirm for certain that no
> legitimate eMail has these as the
On 31/12/2023 16:02, John Levine via mailop wrote:
> A message with a dozen recipients in the same SMTP session is a very
> strong spam signal. So don't do that, do single deliveries like
> everyone else does.
Except that Google and Microsoft don't do single deliveries. Yahoo does.
"Do as I say,
On 17/12/2023 15:01, Jarland Donnell via mailop wrote:
> I “think” these new messages represent a clarification on the reasons
> more than a change of the internal reasons. I’ve long suspected their IP
> rate limit message of only sometimes being an actual IP based rate
> limit. I just never
This happens every 3 months now:
2023-10-29T19:22:20.569+00:00 1qxBMV-0086ua-AC ** @hotmail.com
P= R=dnslookup_ipv4 T=remote_smtp
H=hotmail-com.olc.protection.outlook.com [104.47.58.161]:25
I=[209.16.157.42]:40134
X=TLS1.2:ECDHE_SECP384R1__RSA_SHA256__AES_256_GCM:256
On 09/10/2023 07:44, Kirill Miazine via mailop wrote:
> 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
On 30/09/2023 09:35, Carsten Schiefner via mailop wrote:
> But would you happen to have any more details wrt. the withholding and
> the 50%?
https://seclists.org/oss-sec/2023/q3/254
"< jgh> one's in the resolver library. I find it questionable that it's
being raised against Exim, as if we
On 30/09/2023 08:50, Andrew C Aitchison via mailop wrote:
> I see that there is an Exim release candidate out on test at the moment
>https://lists.exim.org/lurker/message/20230926.174111.cb403675.en.html
> but know nothing about whether it fixes any of these vulnerabilities.
It doesn't fix
On 02/06/2023 08:45, Gellner, Oliver via mailop wrote:
> the Google admin toolbox claims our DKIM keys and MTA-STS entries are
> invalid. Example:
> https://toolbox.googleapps.com/apps/checkmx/check?domain=dm.de_selector=dmglobal4
> reports "Invalid format of DKIM record" and "MTA STS is
On 22/05/2023 19:49, Jim Popovitch via mailop wrote:
> DO use Mailman's built-in DMARC mitigations for re-writing From for
> DMARC identified domains, including p=none.
For a DMARC (p=reject) domain, if the From: header is rewritten, the
presence of a failing DKIM signature still causes Apple to
If you're running a mailing list that retains the original DKIM
signatures [that will fail because the message subject and body have
been modified] you might want to strip/hide them because it can cause
Apple iCloud Mail to increment the spam score by 1 which can cause it to
be delivered to Junk
On 14/04/2023 12:26, Cyril - ImprovMX via mailop wrote:
> What is the best approach here?
Identify the forwarders your customers are using and for those origins
either assume SPF passed or lookup the SPF result in the headers.
--
Simon Arlott
___
On 06/04/2023 17:22, Scott Mutter via mailop wrote:
> But when I go to add the IP under the Junk Mail Reporting Program, the IP
> address is not shown.
>
> "If you want to add any IP addresses not shown below, please request access
> to those IPs"
>
> There's no IP addresses listed. And like
On 30/03/2023 16:48, Michael Peddemors via mailop wrote:
> Now, if you could get EVERYONE to block them for a day, or find some
> other way to hit their pocket books, maybe we could see some relief.
Co-ordinate deferring all email from them for a 30 hour period (UTC
00:00 to UTC 32:00, so that
On 07/02/2023 16:08, Michael Peddemors via mailop wrote:
> Yes, the spammers are picking up on the Hetzner networks again..
> Maybe a priority abuse line is needed for those in the threat detection
> industry..
Maybe when people like Return Path stop sending in false abuse reports?
I've had two
On 16/09/2022 04:46, Bill Cole via mailop wrote:
>> Anyone recognize them?
>
> Looks like the same vt.edu bozos who have at least 2 prior rounds of bad
> research behavior.
I've blocked them previously:
2020-03-17 3.104.129.119 comment "proxy-research.com"
2020-03-17 15.164.73.143 comment
On 02/09/2022 16:16, Carl Byington via mailop wrote:
> Years ago I setup automation for tlsa records to support smtp dane here.
> However, something is now broken, and I am not sure what is wrong.
>
> _25._tcp.mail3.five-ten-sg.com. IN TLSA 3 0 1 (
>
On 25/08/2022 11:39, Tobias Fiebig via mailop wrote:
> An attacker may use an infinite number of SPF referrals in their SPF setting
> and can send an email to a vulnerable mail server which would make the SMTP
> server make a whole lot of DNS queries. By exploiting this vulnerability, an
>
On 12/08/2022 17:22, Jesse Hathaway via mailop wrote:
> Back in 2013[1] we changed our mail config to force MX lookups for gmail
> to only use IPv4 addresses. We made these change after hearing reports
> of higher spam scoring when sending mail via IPv6. Would anyone from
> Google be able to
On 03/08/2022 21:05, Jarland Donnell via mailop wrote:
> I don't understand why Firefox did this:
> https://hacks.mozilla.org/2019/05/tls-1-0-and-1-1-removal-update/
>
> Clients can clearly click the lock, check the details, and see which SSL
> version they're using. So if the site says it's
On 03/08/2022 20:01, Jarland Donnell via mailop wrote:
> End users get headers which is admittedly not useful to most, but the
> "lock" on Gmail is at least fast becoming an accepted thing, seeing more
> email clients latch onto that is a bit slow but is happening. Of course,
> it should only
On 03/08/2022 16:46, Jarland Donnell via mailop wrote:
> It's a pretty big and well respected security practice to consider plain
> text to be more secure than insecure SSL for one reason: A plain text
> connection isn't logged or reported as a secure connection. Both being
There's nothing
On 22/07/2022 10:21, Laura Atkins via mailop wrote:
>> After that there should be an integrated opt-in process to verify any
>> new email address for that ESP customer's list.
>
> While this sounds simple and like a no-brainer, it doesn’t account for how
> complex many companies email programs
On 21/07/2022 10:01, Andrew C Aitchison via mailop wrote:
> On Sun, 9 Jan 2022, Atro Tossavainen via mailop wrote:
>
>> The basic problem is allowing an ESP customer to import a list that
>> existed before the customer became a customer of this ESP. I can't
>> think of an ESP that would not allow
On 02/03/2022 18:00, Edgaras | SENDER via mailop wrote:
> We did, several times actually.
> Does nothing.
It doesn't look like you're able to provide an example of an email where
Google have accepted it as belonging to you when the DKIM signature
fails.
Do you only have the IP addresses that
On 02/03/2022 18:09, Edgaras | SENDER wrote:
>> No, that's quite clearly not literally true. Stop DKIM signing the spam
> email and the problem goes away.
> Yep, and go directly against all the best email practices, guidelines and
> so on.
You're ignoring my point that you should stop sending
On 2 March 2022 17:12:14 GMT, Edgaras | SENDER via mailop
wrote:
> To clarify further, I will walk through the case where an attacker abuses
> Getresponse (getresponse2.eml).
> What happens here:
> 1. Attacker creates an account at Getresponse using a throwaway spam site
> storagemodels.org.uk
>
On 02/03/2022 15:44, Edgaras | SENDER via mailop wrote:
> Sorry for losing my nerve, but it is harming our reputation for a month
> now, tried all possible channels to report this, and the issue is being
> completely ignored.
These examples have the same problem that the original one in January
On 14/12/2021 18:53, John Levine via mailop wrote:
> I think this is different and really is a botched survey from a grad student.
> Poking
> around his department's web site, it seems like the sort of stuff he is
> interested in.
The way the content is phrased makes them almost identical.
On 12/11/2021 18:56, Slavko via mailop wrote:
> I am using bl.0spam.org and nbl.0spam.org RBLs in my custom RBL check
> script, but in more days their DNS server returns SERVFAIL.
>
> Please, are these RBL gone or it is only mistake in its configuration?
The DNSSEC RRSIG for the SOA RR is out of
On 12/10/2021 06:19, John via mailop wrote:
> The answer is yes, it's not good practice to block messages containing long
> lines in emails. That will likely cause problems at either the sender or
> recipient. Senders may receive non-delivery notifications, recipients may
> miss mails.
>
>
On 17/10/2021 11:15, C A via mailop wrote:
> On Sun, Oct 17, 2021, Simon Arlott via mailop wrote:
>
>> confirmation process only if your email passes SPF/DKIM (or DMARC). If
>
> And if the sender doesn't use either?
If there are no SPF or DMARC records published then you can
On 20/01/2021 10:50, Stefano Bagnara via mailop wrote:
> I'm looking for brainstorming and updated industry "standards" from people
> handling outgoing SMTP services or ESP exporting APIs to "request
> subscriptions" (confirmed opt-in).
For mailing lists, it occurs to me that we should now be at
No, there's no forwarding involved at all.
eBay failed to deliver it and then sent a bounce directly to my server.
--
Simon Arlott
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
This is a bounce from eBay for an email they tried to deliver that uses
my domain for both the envelope sender and From: header. Not sure what's
going on here because they normally mask email addresses even when
sending a copy to yourself.
Delivery status notification:
From: Mail Delivery
On 06/10/2021 02:15, Brandon Long via mailop wrote:
> Generally speaking, outside of the obvious differences, most of our spam
> rules are agnostic to IPv4/IPv6.
The frustrating problem with Google's treatment of IPv6 is that the
"must have reverse DNS" requirement means it will return a 5xx
I received a scam email from mail-ma1ind01on060c.outbound.protection.outlook.com
(2a01:111:f400:fea4::60c) so I reported it to the RIR contact,
ab...@microsoft.com and got the following reply implying that they
intend to ignore the problem entirely and expect me to feed it as input
to their spam
On 2021-06-10 16:00, Vytis Marciulionis via mailop wrote:
This is not a new process and we did not encounter any issues before.
However, initially this particular range came with geolocation being
registered to Turkey in RIPE.
Check all of the providers on this list have updated the location:
RFC 6376 does not define what happens when there are multiple TXT
records for _domainkey selectors.
Some implementations allow this but Yahoo doesn't. It's considered a
permanent failure.
In my case I accidentally added a second _domainkey TXT RR with an empty
"" value and only noticed this
On 12/05/2021 04:08, Michael Wise via mailop wrote:
> S3150 is throttling.
>
> Open a ticket and ask for a more realistic hourly/daily throttle limit.
I'm now having this problem too. My email volume is so small it never
appears on SNDS. There have been 10 messages to Hotmail this month (4
On 14/03/2021 07:43, Hans-Martin Mosner via mailop wrote:
> The report also claims that SPF failed, although our SPF record included the
> outgoing mailserver from the beginning, of
> course.
Did it fail for your IP or another IP?
> So this report looks like a red herring to me - not enough
On 19/02/2021 16:45, Michael Peddemors via mailop wrote:
> For instance, have to shout out to the Linode guys for really improving
> their reputation, over the last couple of years.. (still wish they
> provided 'rwhois' entries, at least on customer demand, would make it
> easier to see when
On 15/02/2021 18:25, Bill Cole via mailop wrote:
> On 15 Feb 2021, at 12:53, Jaroslaw Rafa via mailop wrote:
>> Dnia 15.02.2021 o godz. 15:43:56 Matthew Stith via mailop pisze:
>>> 127.255.255.252 - Typing error in DNSBL Name
>>> 127.255.255.254 - Query via public/open resolver/generic
>>>
On 2021-02-04 19:04, Graeme Fowler via mailop wrote:
On 4 Feb 2021, at 15:26, Benoît Panizzon via mailop
wrote:
But I also think EXIM is screwing up the order of the received
messages
in pipelining mode.
There is a bug introduced in Exim 4.94 when using pipelining and some
recipients are
On 04/02/2021 10:37, Benoît Panizzon via mailop wrote:
> So how to reproduce... The focus is on the MAIL FROM / RCPT TO lines in
> the SMTP dialogue.
Can you now reproduce this with your own installation of Exim and
with addresses that do not need to be redacted?
It's not going to be practical
On 21/01/2021 09:15, Stefano Bagnara via mailop wrote:
> Of course a DNS method to let domains opt-in to such a generic system would
> be cool, but unless we think 100% of domains will adopt openid we'll still
> have the subscription bombing issue around, for every form not using this
> "new
On 20/01/2021 10:50, Stefano Bagnara via mailop wrote:
> I'm looking for brainstorming and updated industry "standards" from people
> handling outgoing SMTP services or ESP exporting APIs to "request
> subscriptions" (confirmed opt-in).
How about a web-based process to confirm opt-in?
Domains
On 14/01/2021 18:53, Pascal HOARAU via mailop wrote:
> From https://toolbox.googleapps.com/apps/checkmx/check
>
> The SPF string can not be parsed, do you have any typos in it?
> Decision permanent error in processing
> Explanation SPF Permanent Error: redirect domain has no SPF record:
>
On 14/01/2021 14:27, Pascal HOARAU via mailop wrote:
> __spf.campaign.adobe.com. 120 IN TXT "v=spf1 ip4:66.117.16.0/22
> ip4:192.243.225.0/24 ip4:192.243.228.0/24 ip4:192.243.229.0/24
> ip4:208.67.42.0/24 ip4:192.243.244.0/22 ip4:63.140.47.0/24
> ip4:185.34.188.0/24
Thanks for helping me with Yahoo, Lili.
On 31/07/2020 23:16, Chris Woods via mailop wrote:
> Incidentally, are you also able to try sending via IPv6 or only IPv4?
Neither of those providers have any IPv6 addresses for incoming
messages.
If any server for the domain has an IPv4 addresses, I
Could someone from Microsoft and Yahoo help me resolve this issue with
209.16.157.42?
550 5.7.1 Unfortunately, messages from [209.16.157.42] weren't sent.
Please contact your Internet service provider since part of their
network is on our block list (S3150). You can also refer your provider
to
On 18/03/2020 22:18, Grant Taylor via mailop wrote:
> On 3/18/20 3:10 PM, Miles Fidelman via mailop wrote:
> I agree that the report was sub-optimal at best. Especially considering
> that your server (207.154.13.48) did NOT send an email purporting to be
> from googlegroups.com.
If you look at
53 matches
Mail list logo
