On 2023-05-09 at 16:17:57 UTC-0400 (Tue, 9 May 2023 20:17:57 +)
Gellner, Oliver via mailop
is rumored to have said:
I’d be surprised if there are many members on this list whose
systems do not penalize connections from IP addresses without a fully
confirmed reverse DNS entry one way or the
Just to close this loop:
I resent my report this evening and got an autoreply as normal, so I
guess AT&T hasn't gone Twitter on us...
On 2023-05-06 at 16:53:58 UTC-0400 (Sat, 06 May 2023 16:53:58 -0400)
Bill Cole via mailop
is rumored to have said:
For unknown reasons, I got one of these to
Heho,
On Tue, 2023-05-09 at 20:20 -0400, John Levine wrote:
> ...
> There are millions of domains on the Internet and only a few thousand
> in the PSL, so this is not a problem that most people need to worry
> about.
I am actually rather certain that 'not most people' approximately
evaluates to tw
It appears that Tobias Fiebig via mailop said:
>Talking to a colleague about this; What you could do is move your
>current DNS setup behind powerdns frontends with a remote backend:
>
>https://doc.powerdns.com/authoritative/backends/remote.html
>https://github.com/PowerDNS/pdns/blob/master/modules
May 10, 2023 at 4:32 AM, "Gellner, Oliver via mailop" wrote:
> >
> > $ dig staff.sina.com.cn mx +short
> >
>
> >
> > 10 staffmx.sina.com.cn.
> >
>
> >
> > 10 staffmx1.sina.com.cn.
> >
> sina.com.cn does have a SOA record. Without creating a DNS zone, the MX
> records could not have been
> I think we have to disagree here. The PTR naming is set via
> SendGrid. It doesn't NEED to be the same as the A record. This is
> for those MTA's that do forward/reverse matching, which isn't always
> successful.
>
> Yes, doing that for a IPv6 email address to satisfy Google, go ahead.
>
> But
On 5/9/2023 4:17 PM, Gellner, Oliver via mailop wrote:
I’d be surprised if there are many members on this list whose systems do not
penalize connections from IP addresses without a fully confirmed reverse DNS
entry one way or the other. Maybe I‘m wrong, but then I‘d like to hear from
them.
T
On 09.05.2023 at 02:11 Ken Peng via mailop wrote:
May 9, 2023 at 4:07 AM, "Gellner, Oliver via mailop" wrote:
If a receiver only accepts emails from sender addressed domains for which MX or
A records exist (such checks are performed by many receiving servers), it means
a sender has to 1. set
> On 09.05.2023 at 20:46 Michael Peddemors via mailop wrote:
>
> But nothing wrong with sending an email from a PTR with a name, that doens't
> have the FQDN forward/reverse matched.
>
> As long as there is a URL associated with the domain name.
>
> eg. http://mileageplus.com (Redirect to UA site
Yeah.. always take stats with a grain of salt..
Besides, we know that spammers adopt these things faster than real
companies.. hehehe..
But the ones that don't have it (fcRdns) are often the emails that
people scream the most about missing.
oaky, going back to looking at the threat research
Heho,
hm, not sure. Looking at the 'email-security-scans.org' data, fcrdns is
at ~95.5% of senders. For comparison:
DKIM: ~55.2%
SPF & Valid: ~91.0%
TLS: ~96.0%
Greylisting (attempting to resend): ~97.4%
IPv4: ~97.9%
IPv6 (sending): 56.2%
IPv6 (sending+auth DNS+rec DNS): ~35.7%
So even though th
Hi Laura,
I think we have to disagree here. The PTR naming is set via SendGrid.
It doesn't NEED to be the same as the A record. This is for those MTA's
that do forward/reverse matching, which isn't always successful.
Yes, doing that for a IPv6 email address to satisfy Google, go ahead.
But
That’s a Sendgrid IP, they likely told UA to put in a DNS record, but UA never
did. ¯\_(ツ)_/¯ n
> On 9 May 2023, at 18:01, Stephen Frost via mailop wrote:
>
> Greetings,
>
> I'm getting some inbound email attempts that I believe are legitimate
> from United Airlines that are being rejected due
Greetings,
I'm getting some inbound email attempts that I believe are legitimate
from United Airlines that are being rejected due to:
May 9 12:55:38 tamriel postfix/smtpd[1221960]: warning: hostname
o1.email.smallbusiness.mileageplus.com does not resolve to address 50.31.61.242
Tracking this b
Seems like sending as yahoo.com from SES is going to have very poor
deliverability given yahoo.com has a DMARC policy of reject. It'd be
good to nudge Amazon to block certain domains, sure, but even if they
don't, I don't see how somebody's going to have much spam success via
that path. TL;DR who c
Dnia 8.05.2023 o godz. 23:45:54 Dan Mahoney via mailop pisze:
>
> That’s not “leads”, that’s spam, plain and simple. Maybe — maybe when
> your list of leads comes from an entire company you’ve purchased, this
> might make sense, but if it’s a third party purchase, there’s literally no
> business
Ken Peng via mailop writes:
> May 9, 2023 at 4:07 AM, "Gellner, Oliver via mailop"
> wrote:
>
>
>>
>> If a receiver only accepts emails from sender addressed domains for which MX
>> or A records exist (such checks are performed by many receiving servers), it
>> means a sender has to 1. set up
On Mon 08/May/2023 00:51:47 +0200 Slavko via mailop wrote:
The PSL is something strange, introduced by DMARC which
defines "organizational domain", which seems to be not as
clear as DMARC's authors think.
This PSL is not standardized and is maintained by Mozilla,
which is only as volunteer to do
On Tue, 2023-05-09 at 10:19 +0200, Stefano Bagnara via mailop wrote:
> ...
>
> #1 host -t soa e.comune.bardolino.vr.it
> e.comune.bardolino.vr.it is an alias for app.mailvox.it.
> ...
>
> I guess it is not the missing SOA at #2 because all of our senders
> share that step and most of them show no
On Tue, 9 May 2023 at 04:10, John Levine wrote:
> It appears that Stefano Bagnara via mailop said:
> >Sounds like our standard senders using @e.example.com domain in their
> >RFC5321 are able to deliver to Yahoo while italian municipalities
> >using, e.g., @e.comune.bardolino.vr.it (so 2 more le
20 matches
Mail list logo
