Re: [mailop] United Airlines / mileageplus DNS/rDNS mismatch issue

[Bill Cole via mailop]

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 other. Maybe I‘m wrong, 
but then I‘d like to hear from them.


I do not penalize such connections, in part because the systems I manage 
are hypersensitive to rejecting MS365 mail.


Also because it isn't useful. It IS useful to reject clients with no PTR 
and to match some name patterns in PTR results that are "generic."



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] AT has eliminated their DNSBL team?

[Bill Cole via mailop]

Just to close this loop:

I resent my report this evening and got an autoreply as normal, so I 
guess AT 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 tossed at me by a customer who 
inexplicably wants to send mail to an @att.net address


Action: failed
Status: 5.3.0
Remote-MTA: dns; al-ip4-mx-vip1.prodigy.net
	Diagnostic-Code: smtp; 553 5.3.0 alph774 DNSBL:RBL 521< 
74.115.114.190
	_is_blocked.For assistance forward this error to 
abuse_...@abuse-att.net


Having seen those a half-dozen times in as many years, I pulled up my 
last removal request, replaced the different bits, and sent it off to 
the address specified by AT in their error message: 
abuse_...@abuse-att.net


A few seconds later, I get this gem:

The original message was received at Sat, 6 May 2023 16:04:31 -0400
from m0288871.ppops.net [127.0.0.1]

   - The following addresses had permanent fatal errors -

	(reason: 550 5.1.1 : Recipient address 
rejected: User unknown in local recipient table)


   - Transcript of session follows -
... while talking to [144.160.237.58]:
>>> DATA
	<<< 550 5.1.1 : Recipient address rejected: 
User unknown in local recipient table

550 5.1.1 ... User unknown
<<< 421 4.7.0 zlp11043.enaf.vci.att.com Error: too many errors

--346K4VsL001258.1683403471/m0288871.ppops.net-00191d01.
Content-Type: message/delivery-status

Reporting-MTA: dns; m0288871.ppops.net-00191d01.
Received-From-MTA: DNS; m0288871.ppops.net
Arrival-Date: Sat, 6 May 2023 16:04:31 -0400

Final-Recipient: RFC822; abuse_...@abuse-att.net
X-Actual-Recipient: rfc822; abuse_...@abuse-att.net
Action: failed
Status: 5.1.1
Remote-MTA: DNS; [144.160.237.58]
	Diagnostic-Code: SMTP; 550 5.1.1 : Recipient 
address rejected: User unknown in local recipient table

Last-Attempt-Date: Sat, 6 May 2023 16:04:31 -0400

That's their Proofpoint inbound filter being told by an actual AT 
machine that the address they tell people to mail does not exist.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: PSL: SOA record per subdomain required?!

[Tobias Fiebig via mailop]

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 two, with both of them being on this mailing list. ;-)

That being said; Of course, just doing things correctly is (obviously)
the right solution; The 'solution' I outlined is for the specific
context of 'legacy system in place that does not do zone-breaks, how do
we get this fixed while we figure out how to properly fix our tree
because whatever set of scripts currently manages our zone(s) grew
sentient roughly two decades before ChatGPT and is really skeptical of
change'. ;-)

With best regards,
Tobias
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: PSL: SOA record per subdomain required?!

[John Levine via mailop]

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/remotebackend/example.rb
>
>You could use that with a script to programatically inject SOA/NS/DS
>for names matching a specific pattern; At the same time, you could also
>use that to roll out DNSSEC. ;-)

That would work, but if you put your domain in the PSL, normally you
put subdmains in separate zones to make it easier to manage them
separately.

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.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Yahoo: SOA record per subdomain required?!

[Ken Peng via mailop]

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 added.

I was speaking staff.sina.com.cn
which is not a zone but has MX records.

Regards 



> 
> What I wrote was that to satisfy reject_unknown_sender_domain (using your 
> example), the sender has to create a) a DNS zone and b) add an A or MX 
> record. On the other hand, when the receiver only checks for SOA records up 
> to the organizational domain, step b) could be skipped and the check would 
> still pass. That’s why I considered the SOA check more relaxed than Postfix’ 
> reject_unknown_sender_domain.
> 
> — 
> 
> BR Oliver
> 
> 
> 
> **dmTECH GmbH**
> Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
> **Telefon **0721 5592-2500 **Telefax **0721 5592-2777
> **dmt...@dm.de* www.dmTECH.de http://www.dmtech.de/ **
> **GmbH: **Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
> **Geschäftsführer: **Christoph Werner, Martin Dallmeier, Roman Melcher
> 
> 
> 
> **Datenschutzrechtliche Informationen**
> Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
> ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
> Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder 
> sich bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen 
> unter anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren 
> Rechten sowie die Kontaktdaten unserer Datenschutzbeauftragten finden Siehier 
> https://www.dm.de/datenschutzerklaerung-kommunikation-mit-externen-493832 .
>

--
  https://kenpeng.pages.dev/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] United Airlines / mileageplus DNS/rDNS mismatch issue

[Atro Tossavainen via mailop]

> 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 nothing wrong with sending an email from a PTR with a name, that
> doens't have the FQDN forward/reverse matched.

RFC 1912 #2.1

It is 27 years old.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [External] Re: United Airlines / mileageplus DNS/rDNS mismatch issue

[Kevin A. McGrail via mailop]

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.


This has not proven to be a useful indicator of spam or ham and has a 
lot of FPs if you try to enforce it.  From anecdotally looking at the 
logs, it might be useful to bump it up a small amount in SA for when it 
does match but hardly anything when it doesn't.


-KAM

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Yahoo: SOA record per subdomain required?!

[Gellner, Oliver via mailop]

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 up a DNS zone and 2. create a MX or A record within it.


No. A DNS zone is not needed at all for sending email.

My ex-employer is a Nasdaq listed company, whose business email is with 
@staff.sina.com.cn. It has MX only, not a zone.

$ dig staff.sina.com.cn soa +short

$ 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 added.
What I wrote was that to satisfy reject_unknown_sender_domain (using your 
example), the sender has to create a) a DNS zone and b) add an A or MX record. 
On the other hand, when the receiver only checks for SOA records up to the 
organizational domain, step b) could be skipped and the check would still pass. 
That’s why I considered the SOA check more relaxed than Postfix’ 
reject_unknown_sender_domain.

—
BR Oliver

dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] United Airlines / mileageplus DNS/rDNS mismatch issue

[Gellner, Oliver via mailop]

> 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 URL)

Without an A record that maps back to the IP address, there is no direct way 
for the receiver to verify whether the PTR entry is legitimate. Everyone can 
create a PTR record for his own IP address that resolves to mileageplus.com or 
google.com.

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.

—
BR Oliver



dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] United Airlines / mileageplus DNS/rDNS mismatch issue

[Michael Peddemors via mailop]

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 stuff.. I have been 
amiss with sending my state of the union reports the last couple of weeks.




On 2023-05-09 12:18, Tobias Fiebig via mailop wrote:

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 that sample is a bit biased, i'd say that fcrDNS is more
'lived practice' than SPF. ;-)

With best regards,
Tobias

On Tue, 2023-05-09 at 11:40 -0700, Michael Peddemors via mailop wrote:

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 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 URL)

Perfect forward/reverse FQDN matching is still a little aggressive
IMHO,
and especially problematic.  Some people think they need 20 PTR
records,
one for each A record.. (No, that is worse)

Postfix does allow forward/reverse checking, I would NOT enable that
for
the IPv4 space (yet)

On 2023-05-09 10:22, Laura Atkins via mailop wrote:

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 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 back, near as I can tell, postfix is correct here
in that
50.31.61.242 / 242.61.31.50.in-addr.arpa resolves to
o1.email.smallbusiness.mileageplus.com but
o1.email.smallbusiness.mileageplus.com doesn't seem to actually
exist:

dig o1.email.smallbusiness.mileageplus.com a

;o1.email.smallbusiness.mileageplus.com.IN A

;; AUTHORITY SECTION:
smallbusiness.mileageplus.com. 600 INSOA
vndcdf-fs-gma3-vip.ual.com. ualipconfig.united.com. 40 10800
3600
2592000 600

Hopefully someone on here is from UA or knows how to get in touch
with
someone there who could like into fixing that.

Thanks,

Stephen
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


--
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com

Email Delivery Blog: http://wordtothewise.com/blog







___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop



--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] United Airlines / mileageplus DNS/rDNS mismatch issue

[Tobias Fiebig via mailop]

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 that sample is a bit biased, i'd say that fcrDNS is more
'lived practice' than SPF. ;-)

With best regards,
Tobias 

On Tue, 2023-05-09 at 11:40 -0700, Michael Peddemors via mailop wrote:
> 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 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 URL)
> 
> Perfect forward/reverse FQDN matching is still a little aggressive
> IMHO, 
> and especially problematic.  Some people think they need 20 PTR
> records, 
> one for each A record.. (No, that is worse)
> 
> Postfix does allow forward/reverse checking, I would NOT enable that
> for 
> the IPv4 space (yet)
> 
> On 2023-05-09 10:22, Laura Atkins via mailop wrote:
> > 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 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 back, near as I can tell, postfix is correct here
> > > in that
> > > 50.31.61.242 / 242.61.31.50.in-addr.arpa resolves to
> > > o1.email.smallbusiness.mileageplus.com but
> > > o1.email.smallbusiness.mileageplus.com doesn't seem to actually
> > > exist:
> > > 
> > > dig o1.email.smallbusiness.mileageplus.com a
> > > 
> > > ;o1.email.smallbusiness.mileageplus.com.IN A
> > > 
> > > ;; AUTHORITY SECTION:
> > > smallbusiness.mileageplus.com. 600 INSOA 
> > > vndcdf-fs-gma3-vip.ual.com. ualipconfig.united.com. 40 10800
> > > 3600 
> > > 2592000 600
> > > 
> > > Hopefully someone on here is from UA or knows how to get in touch
> > > with
> > > someone there who could like into fixing that.
> > > 
> > > Thanks,
> > > 
> > > Stephen
> > > ___
> > > mailop mailing list
> > > mailop@mailop.org
> > > https://list.mailop.org/listinfo/mailop
> > 
> > -- 
> > The Delivery Experts
> > 
> > Laura Atkins
> > Word to the Wise
> > la...@wordtothewise.com
> > 
> > Email Delivery Blog: http://wordtothewise.com/blog
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://list.mailop.org/listinfo/mailop
> 
> 

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] United Airlines / mileageplus DNS/rDNS mismatch issue

[Michael Peddemors via mailop]

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 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 URL)

Perfect forward/reverse FQDN matching is still a little aggressive IMHO, 
and especially problematic.  Some people think they need 20 PTR records, 
one for each A record.. (No, that is worse)


Postfix does allow forward/reverse checking, I would NOT enable that for 
the IPv4 space (yet)


On 2023-05-09 10:22, Laura Atkins via mailop wrote:
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 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 back, near as I can tell, postfix is correct here in that
50.31.61.242 / 242.61.31.50.in-addr.arpa resolves to
o1.email.smallbusiness.mileageplus.com but
o1.email.smallbusiness.mileageplus.com doesn't seem to actually exist:

dig o1.email.smallbusiness.mileageplus.com a

;o1.email.smallbusiness.mileageplus.com.IN A

;; AUTHORITY SECTION:
smallbusiness.mileageplus.com. 600 INSOA 
vndcdf-fs-gma3-vip.ual.com. ualipconfig.united.com. 40 10800 3600 
2592000 600


Hopefully someone on here is from UA or knows how to get in touch with
someone there who could like into fixing that.

Thanks,

Stephen
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


--
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com

Email Delivery Blog: http://wordtothewise.com/blog







___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop



--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] United Airlines / mileageplus DNS/rDNS mismatch issue

[Laura Atkins via mailop]

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 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 back, near as I can tell, postfix is correct here in that
> 50.31.61.242 / 242.61.31.50.in-addr.arpa resolves to
> o1.email.smallbusiness.mileageplus.com but
> o1.email.smallbusiness.mileageplus.com doesn't seem to actually exist:
> 
> dig o1.email.smallbusiness.mileageplus.com a
> 
> ;o1.email.smallbusiness.mileageplus.com.  IN A
> 
> ;; AUTHORITY SECTION:
> smallbusiness.mileageplus.com. 600 IN SOA vndcdf-fs-gma3-vip.ual.com. 
> ualipconfig.united.com. 40 10800 3600 2592000 600
> 
> Hopefully someone on here is from UA or knows how to get in touch with
> someone there who could like into fixing that.
> 
> Thanks,
> 
> Stephen
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] United Airlines / mileageplus DNS/rDNS mismatch issue

[Stephen Frost via mailop]

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 back, near as I can tell, postfix is correct here in that
50.31.61.242 / 242.61.31.50.in-addr.arpa resolves to
o1.email.smallbusiness.mileageplus.com but
o1.email.smallbusiness.mileageplus.com doesn't seem to actually exist:

dig o1.email.smallbusiness.mileageplus.com a

;o1.email.smallbusiness.mileageplus.com.IN A

;; AUTHORITY SECTION:
smallbusiness.mileageplus.com. 600 IN   SOA vndcdf-fs-gma3-vip.ual.com. 
ualipconfig.united.com. 40 10800 3600 2592000 600

Hopefully someone on here is from UA or knows how to get in touch with
someone there who could like into fixing that.

Thanks,

Stephen


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Any Postmasters or abuse team from Amazon AWS on here?

[Al Iverson via mailop]

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 cares, honestly.

On Mon, May 8, 2023 at 8:11 PM L. Mark Stone via mailop
 wrote:
>
> I also have an issue with an AWS sender using AWS IPs to send email From 
> @yahoo.com.
>
> AWS Support (I’m an AWS customer) says this is OK.
>
> ___
> L. Mark Stone
>
>
> > On May 8, 2023, at 8:24 PM, Michael Peddemors via mailop 
> >  wrote:
> >
> > Wouldn't mind a quick off list dialogue about a prolific spammer team
> > abusing AmazonSES, will share the fingerprints on this actor..
> >
> > Amazon SES is always tougher to filter the good and the bad, but this
> > guy is well known affiliate marketer to suspect sites, and occasionally
> > the odd bit of malware advertisements as well.
> >
> > While we manage to filter this guy to some extent, the footprint is
> > smaller via SES, so be nice to work together on this one.
> >
> > Subject: Adult Film Star Gives New Meaning to Crotch Shot During Video
> >
> >
> > --
> > "Catch the Magic of Linux..."
> > 
> > Michael Peddemors, President/CEO LinuxMagic Inc.
> > Visit us at http://www.linuxmagic.com @linuxmagic
> > A Wizard IT Company - For More Info http://www.wizard.ca
> > "MagicSpam" is a Registered TradeMark of Wizard Tower TechnoServices Ltd.
> > 
> > 604-682-0300 Beautiful British Columbia, Canada
> >
> > This email and any electronic data contained are confidential and intended
> > solely for the use of the individual or entity to which they are addressed.
> > Please note that any views or opinions presented in this email are solely
> > those of the author and are not intended to represent those of the company.
> >
> >
> > --
> > "Catch the Magic of Linux..."
> > 
> > Michael Peddemors, President/CEO LinuxMagic Inc.
> > Visit us at http://www.linuxmagic.com @linuxmagic
> > A Wizard IT Company - For More Info http://www.wizard.ca
> > "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
> > 
> > 604-682-0300 Beautiful British Columbia, Canada
> >
> > This email and any electronic data contained are confidential and intended
> > solely for the use of the individual or entity to which they are addressed.
> > Please note that any views or opinions presented in this email are solely
> > those of the author and are not intended to represent those of the company.
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://list.mailop.org/listinfo/mailop
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop



-- 

Al Iverson / Deliverability blogging at www.spamresource.com
Subscribe to the weekly newsletter at wombatmail.com/sr.cgi
DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New to mass mailings

[Jaroslaw Rafa via mailop]

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 relationship where a party can claim to have opted in.

Formally, not quite right. There are plenty of services, for which when you
sign up, you have the option to agree to give your data to third parties for
marketing purposes. Quite often the service offers even eg. some discount on
subscription fee when you agree to all marketing options, including the
third party one (think mobile phone operators or ISPs - at least here they
often do this). And it is usually not exactly defined what does "third
parties" mean, so basically if you agree to this, they are allowed to give
(think sell) your email address to anyone.

While I still consider this way of doing business as unethical, formally,
you have opted in to this. Even GDPR recognizes it.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Yahoo: SOA record per subdomain required?!

[Byung-Hee HWANG via mailop]

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 a DNS zone and 2. create a MX or A record
>> within it.
>
>
> No. A DNS zone is not needed at all for sending email.
>
> My ex-employer is a Nasdaq listed company, whose business email is with 
> @staff.sina.com.cn. It has MX only, not a zone.
>
> $ dig staff.sina.com.cn soa +short
>
> $ dig staff.sina.com.cn mx +short
> 10 staffmx.sina.com.cn.
> 10 staffmx1.sina.com.cn.

I agree with these pattern, because nowdays people like easy setup via
Cloudflare, with no serious.

> Also, my policy in Postfix has setted up to reject messages from 
> unknow_sender_domain, which means if a domain has neither MX nor A, it would 
> be rejected by me. 
>
> smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, 
> reject_unknown_client_hostname, reject_unknown_sender_domain
>
>
> As you see, Postfix's reject_unknown_sender_domain validates only MX and A, 
> not SOA.
>
> regards.

Good comments, thanks!


Sincerely, Byung-Hee

-- 
^고맙습니다 _布德天下_ 감사합니다_^))//
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Yahoo: SOA record per subdomain required?!

[Alessandro Vesely via mailop]

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 that. Hopefuly they do it in
public way, but one have to consider that list as suggestion
only, it is not used by all and AFAIK some orgs maintain
own lists.



It looks like the PSL won't be used in the "standard" version of DMARC. 
Verifiers would just lookup DMARC records at the From: domain or parents 
thereof.  (There's a new tag to flag the rare exceptions.)  DMARC record 
existence, that way, could the role of SOA+PSL as far as belonging to the same 
organization is the meaning that Y! look for.



Best
Ale
--



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: PSL: SOA record per subdomain required?!

[Tobias Fiebig via mailop]

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 issues.
> So maybe the issue are the missing SOA at #4/#5, but this would be
> out of control by me or my customer (che municipality of Bardolino).
It is actually the one at #1; or rather, at bardolino.vr.it, even
though adding it at e.comune.bardolino.vr.it or comune.bardolino.vr.it
should also help.

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/remotebackend/example.rb

You could use that with a script to programatically inject SOA/NS/DS
for names matching a specific pattern; At the same time, you could also
use that to roll out DNSSEC. ;-)

With best regards,
Tobias

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: PSL: SOA record per subdomain required?!

[Stefano Bagnara via mailop]

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 levels) don't work.
>
> Well, yeah, because vr.it is in the PSL.  Same exact problem.

What would be the fix for this case? Where should we try to add the
missing SOA record? (I'm not sure we can do that, but at this time I
don't even get which SOA record should be added to which host in order
to fix the issue).

#1 host -t soa e.comune.bardolino.vr.it
e.comune.bardolino.vr.it is an alias for app.mailvox.it.
#2 host -t soa app.mailvox.it
app.mailvox.it has no SOA record
#3 host -t soa comune.bardolino.vr.it
comune.bardolino.vr.it has SOA record dns.technorail.com.
hostmaster.comune.bardolino.vr.it. 1 86400 7200 2592000 3600
#4 host -t soa bardolino.vr.it
bardolino.vr.it has no SOA record
#5 host -t soa vr.it
vr.it has no SOA record
#6 host -t soa it
it has SOA record dns.nic.it. hostmaster.nic.it. 2023050909 10800 900
604800 3600

I guess it is not the missing SOA at #2 because all of our senders
share that step and most of them show no issues.
So maybe the issue are the missing SOA at #4/#5, but this would be out
of control by me or my customer (che municipality of Bardolino).

Maybe Yahoo has to whitelist us somehow? I wrote them.

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop