Re: [mailop] Docomo.ne.jp Contact/Assistance?

2023-06-16 Thread dikshie via mailop
On Sat, Jun 17, 2023 at 5:53 AM Scot Berggren via mailop
 wrote:
>
> We have a sender that's shown good results delivering to docomo.ne.jp until 
> the end of May, but messages are timing out since.

from docomo.ne.jp SOA:

postmaster at spmode.ne.jp



Best Regards.
Dikshie
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] [EXT] - Re: Dkim fails, success on same email?

2023-06-16 Thread Salvatore Jr Walter P via mailop
Thanks, I assumed this was an issue, but our vendor who controls our DKIM 
(Sophos) addded the record and we have no control over it. I am going to have 
our network team contact them and get this fixed.

From: mailop  On Behalf Of Alan Hodgson via mailop
Sent: Friday, June 16, 2023 4:57 PM
To: mailop@mailop.org
Subject: [EXT] - Re: [mailop] Dkim fails, success on same email?


On Fri, 2023-06-16 at 18:05 +, Salvatore Jr Walter P via mailop wrote:
Getting reports back from several ISPs like the one below.
It shows dkim failing for the IP, but successful for the domain?
The domain “mail-dkim-us-west-2.prod.hydra.sophos.com” uses multiple IPs,
One of which is “198.154.181.72”. We do receive failures on all other IPs as 
well.
Is this an actual issue or something we can ignore?



198.154.181.72
1

none
fail
pass



warwickri.gov



mail-dkim-us-west-2.prod.hydra.sophos.com
v1
pass


warwickri.gov
pass





It appears you're DKIM-signing it, but not with an identifier aligned with your 
From: domain. So DKIM passes but not in a way that satisfies DMARC.

It passed DMARC only because it passes SPF.

You should add a DKIM signature from a domain aligned with your From: domain.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Dkim fails, success on same email?

2023-06-16 Thread Alan Hodgson via mailop
On Fri, 2023-06-16 at 18:05 +, Salvatore Jr Walter P via mailop
wrote:
> 
> 
> Getting reports back from several ISPs like the one below.
> It shows dkim failing for the IP, but successful for the domain?
> The domain “mail-dkim-us-west-2.prod.hydra.sophos.com” uses
> multiple IPs,
> One of which is “198.154.181.72”. We do receive failures on all
> other IPs as well.
> Is this an actual issue or something we can ignore?
>  
> 
> 
> 198.154.181.72
> 1
> 
> none
> fail
> pass
> 
> 
> 
> warwickri.gov
> 
> 
> 
> mail-dkim-us-west-2.prod.hydra.sophos.com
> v1
> pass
> 
> 
> warwickri.gov
> pass
> 
> 
> 


It appears you're DKIM-signing it, but not with an identifier aligned
with your From: domain. So DKIM passes but not in a way that
satisfies DMARC.

It passed DMARC only because it passes SPF.

You should add a DKIM signature from a domain aligned with your From:
domain.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


[mailop] Docomo.ne.jp Contact/Assistance?

2023-06-16 Thread Scot Berggren via mailop
We have a sender that's shown good results delivering to docomo.ne.jp until the
end of May, but messages are timing out since.

Checking to see if anyone has a contact there.

Thanks,
--
Scot Berggren
Sr. Deliverability Strategist
720-320-5365
scot.bergg...@messagebird.com 
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] DMARC and subdomains

2023-06-16 Thread Gellner, Oliver via mailop

> On 16.06.2023 at 16:13 Jaroslaw Rafa via mailop wrote:
>
> At some time I noticed that Gmail started to indicate DMARC failure. I
> checked and found out that the admins of parent eu.org domain put a DMARC
> record on it, which caused emails from my domain rafa.eu.org (not from the
> parent eu.org) to fail DMARC check.
>
> But... eu.org is on the PSL! So, if DMARC check did actually use the PSL to
> determine the organizational domain, it would have determined that
> rafa.eu.org *is* the organizational domain itself and it shouldn't check
> anything above it. It wasn't the case, however.
>
> So at least one (and important one, given the size of this mail service)
> implementation of DMARC does not use the PSL.

eu.org is located in the private domain section of Mozillas public suffix list. 
Apparently Google does not treat those private domains as public suffixes (at 
least not all of them) or uses a different public suffix list. The DMARC 
specification does not mandate that you have to use Mozillas PSL and pick up 
every self-appointed entry from there.
Andy Smith is likely using a domain below an ICANN registered TLD and is 
therefore unaffected by this issue anyway.

—
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


[mailop] Dkim fails, success on same email?

2023-06-16 Thread Salvatore Jr Walter P via mailop
Getting reports back from several ISPs like the one below.
It shows dkim failing for the IP, but successful for the domain?
The domain "mail-dkim-us-west-2.prod.hydra.sophos.com" uses multiple IPs,
One of which is "198.154.181.72". We do receive failures on all other IPs as 
well.
Is this an actual issue or something we can ignore?



198.154.181.72
1

none
fail
pass



warwickri.gov



mail-dkim-us-west-2.prod.hydra.sophos.com
v1
pass


warwickri.gov
pass




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


Re: [mailop] Port 25 Pingback?

2023-06-16 Thread Bill Cole via mailop
On 2023-06-16 at 13:37:19 UTC-0400 (Fri, 16 Jun 2023 13:37:19 -0400)
John Possidente via mailop 
is rumored to have said:

> A sender of legally mandated bulk mail who are very conscious of making
> sure they're dotting every i and crossing every t (because they're required
> to) asked me today whether port 25 pingback is still necessary. I
> immediately thought, "Of course not," but on second thought (before
> speaking, yay) realized that maybe I'm wrong.
>
> Does anyplace still reject mail from sources that don't answer on port 25?

Do you mean this literally in a technical sense, i.e. that the SMTP client IP 
must accept a port 25 connection back to it? I'm not aware of that EVER being a 
usable tactic that would be worth adapting to. Those people do not want their 
mail.

In the logical sense of "does the domain part of the SMTP sender address have 
appropriate A//MX records in DNS that could make a bounce feasible?" there 
are very many places enforcing that, as they should. If the envelope sender 
address is not even theoretically mailable (i.e. hard app-layerfailure from 
DNS) one can expect the mail to be rejected or in some cases intentionally 
blackholed after acceptance.

In between would be full SMTP callback verification, testing whether the sender 
will accept mail from '<>' in real time, synchronously with the original offer 
of mail. This has been MOSTLY abandoned because it predictably results in false 
positives and has become increasingly risky to the checker's reputation and 
error-prone over the years. A "legally mandated" sender should probably expect 
some of that to still be in use, because the long tail of mail admin 
incompetence is a thing...

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


[mailop] Dkim fails, success on same email?

2023-06-16 Thread Salvatore Jr Walter P via mailop

Getting reports back from several ISPs like the one below.
It shows dkim failing for the IP, but successful for the domain?
The domain "mail-dkim-us-west-2.prod.hydra.sophos.com" uses multiple IPs,
One of which is "198.154.181.72". We do receive failures on all other IPs as 
well.
Is this an actual issue or something we can ignore?



198.154.181.72
1

none
fail
pass



warwickri.gov



mail-dkim-us-west-2.prod.hydra.sophos.com
v1
pass


warwickri.gov
pass




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


Re: [mailop] [EXTERNAL] v4 vs v6 MXs

2023-06-16 Thread Brotman, Alex via mailop
We deliver over v4/v6.   It generally works rather well for us.  We do 
occasionally see someone who publishes a v6 MX and doesn't seem to properly 
test (there was a .gov a few weeks ago for example, since resolved in some 
way). 

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

> -Original Message-
> From: mailop  On Behalf Of James Cloos via
> mailop
> Sent: Thursday, June 15, 2023 7:25 PM
> To: mailop@mailop.org
> Subject: [EXTERNAL] [mailop] v4 vs v6 MXs
> 
> Would any common MTAs in use have any problems with delivery to a destination
> where a subset of its MXs are v4-only and another (non-
> intersecting) subset are v6-only?
> 
> I presume that any rfc-compliant MTA would do the right thing.
> At least in theory.
> 
> But would such an arrangement work in practice?
> 
> -JimC
> --
> James Cloos  OpenPGP: 0x997A9F17ED7DAEA6
> ___
> mailop mailing list
> mailop@mailop.org
> https://urldefense.com/v3/__https://list.mailop.org/listinfo/mailop__;!!CQl3mcH
> X2A!FGn2QQSejR3Zx3fWAr4mzEI2iknjNxA31IoyXLe2YeA5X0OVO4ZGvoTtMf7Kns
> hmVvD-mv-l8AYU0521apI$
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Port 25 Pingback?

2023-06-16 Thread Hans-Martin Mosner via mailop

Am 16.06.23 um 20:02 schrieb Benny Pedersen via mailop:

Mike Hillyer via mailop skrev den 2023-06-16 19:48:

Sources or hosts?

I don’t expect a given host to answer on port 25 just because it
sends, but the domain in the return path should be accepting mail
properly. If they can’t be bothered to receive their DSNs then they
are not likely a good-faith sender.


DSN is not sent, its generated by there own closed port 25 still, so DSN works 
without port 25 listners

maybe accept and bounce should really be stopped ? 


Huh? Whether some address will generate a DSN is not really under their control. What's necessary is that their envelope 
sender address is prepared to receive bounces as it isn't always possible to decide final delivery at the SMTP 
transaction stage.


Of course it would be nice to eliminate accept-and-bounce, but that's not going to happen with SMTP which is after all a 
store-and-forward protocol.


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Port 25 Pingback?

2023-06-16 Thread Benny Pedersen via mailop

Mike Hillyer via mailop skrev den 2023-06-16 19:48:

Sources or hosts?

I don’t expect a given host to answer on port 25 just because it
sends, but the domain in the return path should be accepting mail
properly. If they can’t be bothered to receive their DSNs then they
are not likely a good-faith sender.


DSN is not sent, its generated by there own closed port 25 still, so DSN 
works without port 25 listners


maybe accept and bounce should really be stopped ?

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


Re: [mailop] Port 25 Pingback?

2023-06-16 Thread Hans-Martin Mosner via mailop

Am 16.06.23 um 19:37 schrieb John Possidente via mailop:
A sender of legally mandated bulk mail who are very conscious of making sure they're dotting every i and crossing 
every t (because they're required to) asked me today whether port 25 pingback is still necessary. I immediately 
thought, "Of course not," but on second thought (before speaking, yay) realized that maybe I'm wrong.


Does anyplace still reject mail from sources that don't answer on port 25?

Thanks.


Since mail operators do all kinds of reasonable and unreasonable things to limit the amount of undesired mail, it's 
entirely possible.


I would not care about the domain of the sending SMTP client, but the RFC2821.mailfrom (envelope sender) and the 
RFC2822.from (header From: address) tend to be used as recipients of automatic respectively manual responses, and in my 
opinion the willingness to receive and handle both kinds of responses is part of good e-mail hygiene.


Cheers,
Hans-Martin

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


Re: [mailop] Port 25 Pingback?

2023-06-16 Thread Al Iverson via mailop
On Fri, Jun 16, 2023 at 12:41 PM John Possidente via mailop
 wrote:
>
> A sender of legally mandated bulk mail who are very conscious of making sure 
> they're dotting every i and crossing every t (because they're required to) 
> asked me today whether port 25 pingback is still necessary. I immediately 
> thought, "Of course not," but on second thought (before speaking, yay) 
> realized that maybe I'm wrong.
>
> Does anyplace still reject mail from sources that don't answer on port 25?

No place that matters. Most ESPs have separate infra for outbound SMTP
and inbound reply handling, and it's not the same servers, not the
same IPs. Thus, the servers connecting outbound to deliver mail do not
answer on port 25. This is how it was where I used to work and it was
no impediment to billions of messages delivered monthly. And I never
saw an instance where delivery was held up by waiting to see if the
inbound infra could be reached on port 25 separately.

Cheers,
Al Iverson

-- 

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


[mailop] Docomo Contact/Assistance?

2023-06-16 Thread Scot Berggren via mailop
We have a sender that's shown good results delivering to docomo.ne.jp
until the end of May, but messages are timing out since.

Thanks,
-- 
Scot Berggren
Sr. Deliverability Strategist
720-320-5365
scot.bergg...@messagebird.com 
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Port 25 Pingback?

2023-06-16 Thread Mike Hillyer via mailop
Sources or hosts?

I don’t expect a given host to answer on port 25 just because it sends, but the 
domain in the return path should be accepting mail properly. If they can’t be 
bothered to receive their DSNs then they are not likely a good-faith sender.

Mike

From: mailop  On Behalf Of John Possidente via mailop
Sent: Friday, June 16, 2023 1:37 PM
To: mailop 
Subject: [mailop] Port 25 Pingback?

A sender of legally mandated bulk mail who are very conscious of making sure 
they're dotting every i and crossing every t (because they're required to) 
asked me today whether port 25 pingback is still necessary. I immediately 
thought, "Of course not," but on second thought (before speaking, yay) realized 
that maybe I'm wrong.

Does anyplace still reject mail from sources that don't answer on port 25?

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


[mailop] Port 25 Pingback?

2023-06-16 Thread John Possidente via mailop
A sender of legally mandated bulk mail who are very conscious of making
sure they're dotting every i and crossing every t (because they're required
to) asked me today whether port 25 pingback is still necessary. I
immediately thought, "Of course not," but on second thought (before
speaking, yay) realized that maybe I'm wrong.

Does anyplace still reject mail from sources that don't answer on port 25?

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


Re: [mailop] DMARC and subdomains

2023-06-16 Thread Andy Smith via mailop
Hi Todd,

On Fri, Jun 16, 2023 at 09:31:58AM -0400, Todd Herr via mailop wrote:
> Yes, the DMARC protocol does describe the search for the organizational
> domain for the RFC5322.From domain in an email message.

Yep, got itnow; I want the subdomain policy ("sp"). Not sure how I
missed that, or the other silly errors in my email.

My brain is baking in a non-air-conditioned London!

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] DMARC and subdomains

2023-06-16 Thread Todd Herr via mailop
On Fri, Jun 16, 2023 at 10:11 AM Jaroslaw Rafa via mailop 
wrote:

> Dnia 16.06.2023 o godz. 09:31:58 Todd Herr via mailop pisze:
> > Yes, the DMARC protocol does describe the search for the organizational
> > domain for the RFC5322.From domain in an email message.
> >
> > It doesn't rely on the "_domainkey" hostnames (that's DKIM), but it does
> > currently rely on the Public Suffix List to determine the organizational
> > domain in cases where there is no DMARC policy record published for the
> > RFC5322.From domain.
>
> Well, in reality it doesn't use PSL.
>
> [snip]
>
> So at least one (and important one, given the size of this mail service)
> implementation of DMARC does not use the PSL.
>

Those are two different statements, though.

The current DMARC protocol (
https://datatracker.ietf.org/doc/html/rfc7489#section-3.2) specifies
acquiring a public suffix list as the first step in determining an
organizational domain.

Your example demonstrates an implementation of DMARC that may not be
following the published protocol, but that's different from saying DMARC
doesn't use the PSL.

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] DMARC and subdomains

2023-06-16 Thread Jaroslaw Rafa via mailop
Dnia 16.06.2023 o godz. 09:31:58 Todd Herr via mailop pisze:
> Yes, the DMARC protocol does describe the search for the organizational
> domain for the RFC5322.From domain in an email message.
> 
> It doesn't rely on the "_domainkey" hostnames (that's DKIM), but it does
> currently rely on the Public Suffix List to determine the organizational
> domain in cases where there is no DMARC policy record published for the
> RFC5322.From domain.

Well, in reality it doesn't use PSL.

When my issues with deliverability to Google began a few years ago, I had no
DMARC record on my domain rafa.eu.org. It has been so since the beginning of
the domain and Gmail only used its "best guess" rule to indicate SPF pass
(as SPF record was not present as well).

At some time I noticed that Gmail started to indicate DMARC failure. I
checked and found out that the admins of parent eu.org domain put a DMARC
record on it, which caused emails from my domain rafa.eu.org (not from the
parent eu.org) to fail DMARC check.

But... eu.org is on the PSL! So, if DMARC check did actually use the PSL to
determine the organizational domain, it would have determined that
rafa.eu.org *is* the organizational domain itself and it shouldn't check
anything above it. It wasn't the case, however.

So at least one (and important one, given the size of this mail service)
implementation of DMARC does not use the PSL.
-- 
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] DMARC and subdomains

2023-06-16 Thread Todd Herr via mailop
On Fri, Jun 16, 2023 at 9:21 AM Andy Smith via mailop 
wrote:

> Hi,
>
> Let's say I have domain example.com with SPF, DKIM and DMARC
> records. I've put an A record in there to point foo.bar.example.com
> at someone else's IP address.
>
> Probably some cron job or other automated task on that host has sent
> an email from usern...@foo.bar.example.com that has ended up at
> gmail. gmail have sent me an aggregated DMARC report that includes
> SPF and DMARC failures for that mail.
>
> I did not expect that such email from foo.bar.example.com would
> consult the DMARC record for the parent example.com. Is this
> expected?
>
> Does DMARC use the Public Prefix List or something to determine that
> foo.bar.example.com is under the same administrative control as
> example.com, and in the absence of _domainkey.foo.bar.example.com
> will look for _domainkey.example.com? Amnd perhaps even
> _domainkey.bar.example.com?
>
>
Yes, the DMARC protocol does describe the search for the organizational
domain for the RFC5322.From domain in an email message.

It doesn't rely on the "_domainkey" hostnames (that's DKIM), but it does
currently rely on the Public Suffix List to determine the organizational
domain in cases where there is no DMARC policy record published for the
RFC5322.From domain.

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


[mailop] DMARC and subdomains

2023-06-16 Thread Andy Smith via mailop
Hi,

Let's say I have domain example.com with SPF, DKIM and DMARC
records. I've put an A record in there to point foo.bar.example.com
at someone else's IP address.

Probably some cron job or other automated task on that host has sent
an email from usern...@foo.bar.example.com that has ended up at
gmail. gmail have sent me an aggregated DMARC report that includes
SPF and DMARC failures for that mail.

I did not expect that such email from foo.bar.example.com would
consult the DMARC record for the parent example.com. Is this
expected?

Does DMARC use the Public Prefix List or something to determine that
foo.bar.example.com is under the same administrative control as
example.com, and in the absence of _domainkey.foo.bar.example.com
will look for _domainkey.example.com? Amnd perhaps even
_domainkey.bar.example.com?

Thanks,
Andy

PS I don't care about making it work, and the host name is just a
   convenience for someone else. I'd rather not set or be
   responsible for DMARC policy for it at all. The desired SPF, DKIM
   and DMARC records for the example.com here were intended to be
   for a domain that doesn't send any email at all.

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] v4 vs v6 MXs

2023-06-16 Thread Bjørn Bürger via mailop
Am 16. Juni 2023 01:24:41 MESZ schrieb James Cloos via mailop 
:
>Would any common MTAs in use have any problems with delivery to a
>destination where a subset of its MXs are v4-only and another (non-
>intersecting) subset are v6-only?


I tried it for a while and it's somewhat broken...

In theory, it should just work.

In practice, some people do misconfigure their spamfilters (b)

a) If you just have a set of receiving MXes for each protocol, it doesn't 
matter at all, as long as the sender is able to reach at least one MX for the 
chosen protocol.

b) *some* braindamaged dualstack MX setups reject a connection on v6, if the 
sending MX is v6-only, but the (dualstack) receiving side tries to find an A 
record to check against rbls. I have seen some variations of this kind of setup 
and you can usually work around this, by failover to another sending mx 
(dualstack or v4 only). 

Bjørn

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