Re: [mailop] Proofpoint breaking delivery for Google Workspace

[Mark Alley via mailop]

On 8/2/2024 10:10 AM, Tobias Fiebig via mailop wrote:


Moin,
I just got poked by a user that mail delivery for a review system fails
to some users;

Specifically, organizations using cloud-hosted Proofpoint setups
forwarding to google workspace.
Specifically:
- A DKIM signed SPF valid mail is delivered to the MX of example.com;
   These are pp-hosted's servers.
- Proofpoint does as proofpoint does, breaking DKIM
Many of their customers use External Warning Tags, which inserts 
external warning text into the message body, obviously breaking the 
original DKIM body hash. (i.e. DKIM breaking is entirely dependent on 
the customer configuration)

- Proofpoint then relays the message to the final destination: Google
- Google then rejects the message, as it fails DKIM and SPF;


Is the mail following this flow?

Original Sender server - > MX (PP Hosted cluster) - > Inbound mail route 
to the PP customer's mail store (Google Workspace)


If so, the Proofpoint-protected Google Workspace tenant owner needs to 
configure it (workspace) to not enforce email authentication policy, as 
SPF/DKIM auth will almost certainly be broken by the filter, and DMARC 
(where applicable) will fail for nearly all mail.


Odds are they're probably not receiving a *lot *of mail if this is the 
case. Another prime example of not following configuration requirements.



Does somebody have input on which of the following options is the most
sensible one (i kind of dislike most of them):

- Set p=none and ~all; Hope that this is enough for google (doubt; But
   would appreciate experience reports on this)


SPF ~all would be the best case for maximum delivery with a strict DMARC 
policy. DMARC p=none would technically fix the problem, but obviously 
introduces more security concerns.



- Include the barrage of SPF includes from all major relayers, i.e.,
   pp, gmail/gworkspaces, ms/o365


I'm sure you know this - but... pls no.


- Complain on mailop@, hoping to get proofpoint and gmail to agree on
   trusting each other's ARC signatures if proofpoint breaks DKIM and
   SPF


Proofpoint doesn't seal ARC yet, unfortunately. Believe me, I've 
/vehemently /begged for it from their Product teams, as have many others.


- Mark Alley
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Echospoofing

[Mark Alley via mailop]

On 8/1/2024 4:18 PM, Scott Q. via mailop wrote:

CloudFilter is Proofpoint, right ?

We still gets tons of Spam from them. Not sure if this is related to 
this echospoofing but we just got a pretty big wave


Received: from omta040.useast.a.cloudfilter.net 
(omta040.useast.a.cloudfilter.net [44.202.169.39])
by mx.emailarray.com (Haraka/2.8.21) with ESMTPS id 
6075B447-619F-4FE2-94FB-B6B586F92374.3
envelope-from
(version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 verify=FAIL);
Thu, 01 Aug 2024 16:19:30 -0400
Received: from eig-obgw-6009a.ext.cloudfilter.net ([10.0.30.184])
by cmsmtp with ESMTPS
id ZYIHspqDRnNFGZcGnsTR6p; Thu, 01 Aug 2024 20:19:29 +
Received: from cp-in-14.webhostbox.net ([103.50.162.147])
by cmsmtp with ESMTPS
id ZcGksNXf0oaMiZcGlsDN9r; Thu, 01 Aug 2024 20:19:28 +
X-Authority-Analysis: v=2.4 cv=deKG32Xe c=1 sm=1 tr=0 ts=66abedd0
  a=+OZ35jC+7F35rNibgVyYDA==:117 a=jZ5zol7y3lBdV6rxEGevAg==:17
  a=MKtGQD3n3ToA:10 a=yoJbH4e0A30A:10 a=5KLPUuaC_9wA:10 a=M51BFTxLslgA:10
  a=A4EqBspgoKYA:10 a=n9Fe_nV6:8 a=x8JhEuIrCajjPMggPtkA:9
  a=PEF53iIozS7NwpkX:21 a=_W_S_7VecoQA:10 a=lqcHg5cX4UMA:10
  a=xOl7BDxbbtdmDN2MprIA:9 a=HXjIzolwW10A:10 a=T6a71-JsGAwA:10
  a=wlHTxKAh8-WCeF7hZiUK:22 a=WVAGjVSKdBBTa5aWMILr:22 a=WIq2oDtJ_6PiUi2x2ys3:22
Received: from [45.137.126.85] (port=62285 helo=[185.198.243.176])
by cp-in-14.webhostbox.net with esmtpsa  (TLS1.2) tls 
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
(Exim 4.96.2)
(envelope-from)
id 1sZcGi-002goN-2w



Technically yes, that's Cloudmark (owned by Proofpoint) - but no, 
"Echospoofing" has nothing to do with Cloudmark at all.


To my knowledge, .pphosted.com (hosted Proofpoint enterprise mail 
clusters) were the primary affected targets.


- Mark Alley
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Echospoofing

[Mark Alley via mailop]

On 7/30/2024 5:11 PM, Gellner, Oliver via mailop wrote:

Might be interesting for some: The article describes an attack that 
abuses weaknesses in Microsofts and Proofpoints email services to send 
spoofed emails that pass both SPF and DKIM checks for various domains 
like ibm.com or disney.com and others that use both services:


https://labs.guard.io/echospoofing-a-massive-phishing-campaign-exploiting-proofpoints-email-protection-to-dispatch-3dd6b5417db6

Sending spoofed emails that pass SPF alone for domains that use hosted 
email services like Office365 is not new and has already been 
documented in the past (eg in https://arxiv.org/pdf/2302.07287.pdf). 
That’s why some providers like Gmail started to consider only DKIM for 
the BIMI verdict / authentication checkmarks and do not rely on SPF 
any longer 
(https://www.theregister.com/2023/06/09/google_bimi_email_authentication/). 
However in this case the attackers managed to take it one step further 
and combine two hosted email services to get valid DKIM signatures for 
their messages too.
Beside fixing the configuration within the Proofpoint tenant for the 
affected domains, I advise to also prefix 
„include:spf.protection.outlook.com“ in the SPF record with a question 
mark and rely only on DKIM for authentication, as in the end you 
cannot control what is being allowed by this broad SPF include.


Unsolicited opinion from $dayjob that is a PP customer; I commented 
about this on LinkedIn already, but just sharing it here in more 
detailed reply (not limited to 1250 characters) to this since it's 
directly relevant.


Disclaimer: I don't work for Proofpoint. These views below are my own, 
and they have not been reviewed or approved by my employer.



The part that makes this issue complicated is that every Proofpoint 
enterprise customer's mail clusters are separate and distinct, whether 
they're on-prem (PPS) or using Proofpoint Hosted on-demand (POD).


For the context of this topic and the exploited configuration in 
question, there is no shared environment (outside of VM hosts) or shared 
allow relay configuration between customer mail clusters in this aspect 
- any configuration done by one mail cluster administrator, has nothing 
to do with any other customer's. (i.e. Local policy, rules, and 
filtering specific to that cluster and customer)


Generally (and as Oliver noted), this isn't a "new" attack vector; it's 
been a known common misconfiguration and heavily suggested step in 
Proofpoint's M365 integration guide best practices to mitigate for a 
very long time.


As it turns out, potentially a *lot* of Proofpoint's hosted enterprise 
customers (.pphosted.com) weren't following these best practices. So, 
(from my PoV as a customer cluster mail admin which did mitigate for 
this many years ago) I'm not really sure where the blame lies.


Is it the customer mail administrator's fault for not restricting the 
MTA's relay configuration correctly? (from either ignorance of the 
configuration vulnerability, failure to remediate in a timely fashion, 
incompetence, red tape, etc.)


Or is Proofpoint at fault because they hosted the MTAs, but didn't 
mitigate this for their hosted customers with this vulnerable 
configuration for as many years (which is almost double digits) as it's 
been a known configuration issue with M365 integration for allowed relay 
IPs?


Arguably, I think there could have been a lot more done in hindsight by 
Proofpoint to address this more actively - but this has largely been the 
mail cluster administrator's responsibility to mitigate in the past, 
which apparently led to and heavily contributed to this incident. 
Hopefully that will change soon with improvements to the relay 
restriction feature.


Okay, I'll get off my soapbox now.


- Mark Alley

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

Re: [mailop] Outlook forwarding meeting invite breaks DMARC

[Mark Alley via mailop]

Outlook has had this problem IIRC since I first started working with 
DMARC back in ~2017. It's "expected behavior" apparently, since it uses 
the "Sender" header to notate the forwarder is sending "on behalf of" 
the Meeting organizer (which obviously doesn't fix the RFC5322.FROM)


I've usually advised users to send the invite as an attachment with the 
"Forward as iCalendar" option on Desktop outlook in their calendar, 
which avoids the problem.


- Mark Alley

On 7/29/2024 9:55 AM, Scott Q. via mailop wrote:
Anyone else dealing with Outlook not rewriting the header From upon 
forwarding a meeting invite ?


This is obviously wrong and breaks on domains with strict DMARC policy.

I only found this thread that's 3 years old talking about it: 
https://learn.microsoft.com/en-us/answers/questions/335985/issues-forwarding-meetings 



What would the recommended behavior be ? Not forward invites ? Switch 
MUA ?


Scott


___
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] Crowdstrike Phishing domains

[Mark Alley via mailop]

Adding a few more:-

crowdstrike.phpartners[.]org
crowdstrikeodayl[.]com
crowdstrikedown[.]com
crowdstrikeblueteam[.]com
crowdstrikefix[.]zip
crowdstrikereport[.]com


- Mark Alley

On 7/19/2024 12:54 PM, Mark Alley wrote:


Hey Mailop friends, sharing info here from the email security community.

I'm sure many of you are already /very/ acutely aware of the 
Crowdstrike outage going on globally right now. Threat actors have 
started to register and operationalize domains capitalizing on this 
outage, noted TA domains are below for blocking:


crowdstrike-helpdesk[.]com
crowdstrikebluescreen[.]com
crowdstrike-bsod[.]com
crowdstrikedown[.]site
crowdstrike0day[.]com
crowdstrikedoomsday[.]com
crowdstrikefix[.]com
crashstrike[.]com
crowdstriketoken[.]com
fix-crowdstrike-bsod[.]com
bsodsm8r[.]xamzgjedu[.]com
crowdstrikebsodfix[.]blob[.]core[.]windows[.]net
crowdstrikecommuication[.]app
fix-crowdstrike-apocalypse[.]com
supportportal-crowdstrike-com[.]translate[.]goog
crowdstrike-cloudtrail-storage-bb-126d5e[.]s3[.]us-west-1[.]amazonaws[.]com
crowdstrikeoutage[.]info
clownstrike[.]co[.]uk
crowdstrikebsod[.]com
whatiscrowdstrike[.]com
clownstrike[.]co
microsoftcrowdstrike[.]com
crowdfalcon-immed-update[.]com
crowdstuck[.]org
failstrike[.]com
winsstrike[.]com
crowdpass[.]live
crowdstrokeme[.]me
crowdstrikerecovery1.blob.core[.]windows[.]net
crowdstrikeupdate[.]com


- Mark Alley
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Crowdstrike Phishing domains

[Mark Alley via mailop]

Hey Mailop friends, sharing info here from the email security community.

I'm sure many of you are already /very/ acutely aware of the Crowdstrike 
outage going on globally right now. Threat actors have started to 
register and operationalize domains capitalizing on this outage, noted 
TA domains are below for blocking:


crowdstrike-helpdesk[.]com
crowdstrikebluescreen[.]com
crowdstrike-bsod[.]com
crowdstrikedown[.]site
crowdstrike0day[.]com
crowdstrikedoomsday[.]com
crowdstrikefix[.]com
crashstrike[.]com
crowdstriketoken[.]com
fix-crowdstrike-bsod[.]com
bsodsm8r[.]xamzgjedu[.]com
crowdstrikebsodfix[.]blob[.]core[.]windows[.]net
crowdstrikecommuication[.]app
fix-crowdstrike-apocalypse[.]com
supportportal-crowdstrike-com[.]translate[.]goog
crowdstrike-cloudtrail-storage-bb-126d5e[.]s3[.]us-west-1[.]amazonaws[.]com
crowdstrikeoutage[.]info
clownstrike[.]co[.]uk
crowdstrikebsod[.]com
whatiscrowdstrike[.]com
clownstrike[.]co
microsoftcrowdstrike[.]com
crowdfalcon-immed-update[.]com
crowdstuck[.]org
failstrike[.]com
winsstrike[.]com
crowdpass[.]live
crowdstrokeme[.]me
crowdstrikerecovery1.blob.core[.]windows[.]net
crowdstrikeupdate[.]com


- Mark Alley
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mailserver software

[Mark Alley via mailop]

Just sharing since it's relevant - report direct from CISA 
 
I believe he's referencing.


- Mark Alley


On 7/16/2024 3:31 PM, Graeme Fowler via mailop wrote:

On 16 July 2024 16:29:39 "Scott Q. via mailop"  wrote:
You are a few years too late. China already completely hacked MS and 
had access to ALL accounts for up to 2 years.


Joking aside: [citation needed]

If you're going to make massive claims of that nature, please provide 
links to factual articles about it.


Not hearsay, not rumours, but substantiated evidence.

And remember that Microsoft, for their many faults, do not simply run 
one infrastructure. The consumer and business environments are largely 
separated, for one.


I'm no apologist for them but one thing I can't take, as a list member 
or admin, is unsubstantiated posts.


Ta

Graeme


___
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] Help with handling backscatter

[Mark Alley via mailop]

On 7/11/2024 3:01 PM, Jesse Hathaway via mailop wrote:

We received a thousand or so of the attached backscatter emails this
morning, each one to a different recipient, but with the same
return-path,. I don't have much experience dealing
with backscatter, so I was hoping for some guidance from this list.

Questions:

1.  Why are the non-delivery notifications sent to
   rather than to?
2.  Does the backscatter email show evidence of miss configuration on my
 side? I don't believe so, but we did recently stand up some new
 postfix servers, whereas our existing servers run exim.
3.  What mitigations do folks recommend to drop these types of messages?

Thanks, Jesse


Is BATV an option for you?

- Mark Alley
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Cloud hosts for responsible mail servers?

[Mark Alley via mailop]

Assuming you're talking about Azure Communications Service; from my
experience/knowledge, it shares the same IP space and outbound pools that's
used by Outlook/Live/Exchange Online, etc.

So, yes.

-Mark Alley

On Tue, Jul 9, 2024, 5:36 PM Jeff Pang via mailop  wrote:

> On 2024-07-10 05:43, Ken Johnson via mailop wrote:
> > Opinion based on personal experience follows:
> >
> > I would not choose Amazon SES because of the poor content quality
> > (spam, phishing, etc.) of many messages received here where the header
> > contains the string "amazonses.com".
>
> does azure messages service have that issue?
>
> --
> Jeff Pang
> jeffp...@aol.com
> ___
> 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] proofpoint - possible missmatch with ipcheck

[Mark Alley via mailop]

Sorry - to clarify - Each customer configuration (and dispositions/spam
thresholds/policies/DNSBLs used, etc) for POD customers are entirely
separate from one another, but PDR info is shared across customers to my
knowledge (specific to blocks). I'm not 1000% sure if it applies entirely
the same across the board to the deferrals for both PPE and POD customers.

PDR is also configurable per-customer (.pphosted.com), so your experience
with one customer may not be identical to another depending on their
configuration. That's what I meant by per-customer.

It's black-box machine learning, so nobody but Proofpoint knows the exact
signals designed for it.

>From a customer perspective, all we know is it's largely IP based when it
comes to blocking/deferral disposition and looks at
volume/spammy-ness/threats, etc from the IPs.

I know a rep from PPE is on-list, and can elaborate on the PPE side if they
want to.

- Mark Alley





On Thu, Jul 4, 2024, 11:08 AM Patrick Landolt 
wrote:

> Hi Mark
>
> Thanks for the insight.
>
> Most deferred mails go to remote mx that do use PP internally and have an
> mx that is branded with their domain.
> But there are also a good bunch of recievers that have a *.pphosted.com
> mx. Thos mails to *pphosted.com are now delivered.
> There were less mails to *.ppe-hosted.com mx but there were no deferred
> mails there.
>
> What do you mean that PDR kicks in deferrals per-customer? Would that
> affect specific Mail.FROM that would be deferred?
> Would love to talk to a PP representative to better understand those
> deferrals.
>
> Best regards,
> Patrick
>
>
> > On 4 Jul 2024, at 17:46, Mark Alley  wrote:
> >
> > PP customer here - Do you know what the receiver hostnames are that are
> deferring you? And is it all mail to any Proofpoint customer, or to just a
> few hosts?
> >
> > If the MX hostnames end in .ppe-hosted.com, that's Proofpoint
> essentials, if it's .pphosted.com, that's an enterprise POD customer.
> >
> > PDR usually kicks in deferrals per-customer if you're sending large
> unexpected volume from an IP address. You'll only show up on the PDR IP
> tool if you're actually added to the list for blocking.
> >
> > - Mark Alley
> >
> > On Thu, Jul 4, 2024, 9:29 AM Patrick Landolt via mailop <
> mailop@mailop.org> wrote:
> > Hi
> >
> > We see a surge of deferred mails because of a proofpoint check resulting
> in mta responses like:
> > Deferred - see https://ipcheck.proofpoint.com/?ip=[…]
> >
> > The actual ipcheck on the mentioned domain does - on multiple tested ips
> - return that nothing is blocked.
> >
> > Is there a proofpoint representative here that can contact me off list
> to help solve the issue?
> >
> > Best regards,
> > Patrick
> >
> > --
> > Patrick Landolt
> > Leiter Softwareentwicklung
> > Mitglied der Geschäftsleitung
> >
> > mailXpert GmbH
> > Schulstrasse 37
> > 8050 Zürich
> >
> > Tel: +41 44 222 22 14
> > Web: https://www.mailXpert.ch
> > --
> >
> > www.mailXpert.ch
> > Professionelles E-Mail Marketing von ARTACK WebLab GmbH
> >
> > ___
> > 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] proofpoint - possible missmatch with ipcheck

[Mark Alley via mailop]

PP customer here - Do you know what the receiver hostnames are that are
deferring you? And is it all mail to any Proofpoint customer, or to just a
few hosts?

If the MX hostnames end in .ppe-hosted.com, that's Proofpoint essentials,
if it's .pphosted.com, that's an enterprise POD customer.

PDR usually kicks in deferrals per-customer if you're sending large
unexpected volume from an IP address. You'll only show up on the PDR IP
tool if you're actually added to the list for blocking.

- Mark Alley

On Thu, Jul 4, 2024, 9:29 AM Patrick Landolt via mailop 
wrote:

> Hi
>
> We see a surge of deferred mails because of a proofpoint check resulting
> in mta responses like:
> Deferred - see https://ipcheck.proofpoint.com/?ip=[…]
>
> The actual ipcheck on the mentioned domain does - on multiple tested ips -
> return that nothing is blocked.
>
> Is there a proofpoint representative here that can contact me off list to
> help solve the issue?
>
> Best regards,
> Patrick
>
> --
> Patrick Landolt
> Leiter Softwareentwicklung
> Mitglied der Geschäftsleitung
>
> mailXpert GmbH
> Schulstrasse 37
> 8050 Zürich
>
> Tel: +41 44 222 22 14
> Web: https://www.mailXpert.ch
> --
>
> www.mailXpert.ch
> Professionelles E-Mail Marketing von ARTACK WebLab GmbH
>
> ___
> 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] How to respond to a subscription attack

[Mark Alley via mailop]

Adding to Taavi's List-Unsub condition - I've had similar success with 
List-unsubscribe identification for transactional-volume attacks, and 
also with a few additional indicators for transactional mail that are 
below. These are Proofpoint-specific conditions, but can be (mostly) 
translated to other filters.


As Taavi noted, this is scorched-earth on most external mail, but it 
curbs the volume the attack recipient actually receives down to almost 
negligible levels, while still allowing somewhat normal day-to-day 
correspondence. You'd definitely want to make sure these messages are 
quarantined, rather than rejected/dropped so your SOC/IR team can review.


 * Message Header "x-mailer" contains "php"
 o OR
 * Detected Language is not "en" (english) - (Or whatever your org's
   expected communication language(s) are)
 o OR
 * Message Header "x-antiabuse" does not equal ""
 o OR
 * Envelope Sender Email Address contains "bounce"
 o OR
 * Dictionary Unsubscribe score greater than 0 in subject, body fields
   - (dictionary below)

Unsubscribe dictionary:

Teken uit إلغاء الاشتراك Odhlásit se Afmeld abonnement opzeggen 
unsubscribe tellimuse tühistamine boko ni volayaca Maghinto ng 
suskrisyon Peruuta tilaus se désabonner abbestellen আন-সাবস্ক্রাইব 
διαγραφείτε από τη συνδρομή dezabòne לבטל את המנוי सदस्यता समाप्त 
Leiratkozás berhenti berlangganan disiscrizione 購読解除します。 batili 
ungisho 구독 취소 otkazati pretplatu atcelt abonēšanu atsisakyti 
prenumeratos berhenti melanggan twaqqaf l-abbonament anular le 
suscripción avslutte abonnementet anular ar suscripción لغو عضویت 
Anulowanie subskrypcji dezabonare отписване отписаться toe lesitala 
Отказивање претплате Otkazivanje pretplate odhlásiť odjavo anular la 
suscripción avsluta prenumerationen சந்தாநீக்கு స్వీకరణ donar de baixa 
ยกเลิก to'o e ngaahi totongi Aboneliği Kaldır відмовитися від підписки 
رکنیت ختم hủy đăng ký Dileu tanysgrifiad leiratkozni darse de baja 
wypisać z donar-se de baixa 取消 订阅 取消 訂閱 取消訂閱 subscribe verify 
subscription registration account has been created welcome to newsletter 
confirmation activation


- Mark Alley


On 6/28/2024 3:42 AM, Taavi Eomäe via mailop wrote:
The best method we've found was to reject all letters with 
List-Unsubscribe header (or similar) sent to that victim.


This obviously has side-effects, but they're tolerable compared to the 
flood of letters.


I should note that these letters are usually sent in order to cover up 
something like a credit card statement, password reset or something 
other malicious. So be perceptive.



___
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] Scanner frequency ?

[Mark Alley via mailop]

The website is here below; I get this in my web logs occasionally.

https://about.censys[.]io/

User Agent: Mozilla/5.0 (compatible; CensysInspect/1.1; 
+https://about.censys[.]io/)


- Mark Alley


On 5/29/2024 3:29 PM, J Doe via mailop wrote:

Hi list,

Has anyone noticed a recent increase in the frequency of scans of their
mail servers by Censys ?

I am seeing the following in my logs more often:

    May 29 01:49:13 server smtpd[50661]: 78d6ab67951b801a smtp
    connected address=199.45.154.4
    host=scanner-401.hk2.censys-scanner.com

Thanks,

- J
___
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] Does Google not accept bounce emails anymore?

[Mark Alley via mailop]

Do you not have SPF records for your HELO/EHLO FQDNs?

It appears the A record the PTR of that IP address resolved to "
mail-108-mta34.mxroute.com" and it does not have an SPF record.

You should have a SPF record for each of your MTA hostnames that authorizes
the IP and/or A record of said hostnames. That may fix the problem.

- Mark Alley

On Mon, May 27, 2024, 6:15 PM Jarland Donnell via mailop 
wrote:

> 421-4.7.26 Your email has been rate limited because it is
> unauthenticated. Gmail requires all senders to authenticate with either
> SPF or DKIM. Authentication results: DKIM = did not pass SPF [] with ip:
> [136.175.108.34] = did not pass For instructions on setting up
> authentication, go to
> https://support.google.com/mail/answer/81126#authentication
> 5614622812f47-3d1b370fc69si2809030b6e.141 - gsmtp
>
> Bounces coming from blank envelope senders are being held to SPF/DKIM
> authentication, which of course fails. Been seeing this a lot lately.
> Should we just not send bounce emails to Google anymore?
> ___
> 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] v=spf1 -all SPF treewalk?

[Mark Alley via mailop]

On 5/16/2024 6:09 PM, John Levine wrote:


It appears that Mark Alley via mailop  said:

This claim stated that (and I'm quoting verbatim here), "/I forced many
ESPs to start failing SPF for any subdomain of a domain that has no
explicit SPF, and fails SPF at the *primary domain level* /(Context
note: when/v=spf1 -all /exists at the primary domain)".

Has anyone observed or heard of this SPF treewalk-esque evaluation logic
being used by Receivers when an empty SPF fail policy is used at the
organizational domain, but the subdomain used for SPF evaluation doesn't
exist?

I think he's confusing SPF and DMARC, or he's just confused.

If a domain has no SPF record, the SPF result is None, which is not
Pass, so in some contexts (DMARC checks) it acts like fail. This
should not surprise anyone.

R's,
John


I'm of the same opinion, and this context is specifically excluding 
DMARC. Which itself is even yet more confusing as to the purpose of this 
proposed "problem" email scenario that an authentication test was 
actually designed for. I don't see what it's supposed to prove.


- Mark Alley
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL] v=spf1 -all SPF treewalk?

[Mark Alley via mailop]

In this case, assume no wildcard exists intentionally.


- Mark Alley

On 5/16/2024 5:18 PM, Michael Wise wrote:


… seems legit? Although perhaps a bit too restrictive if the 
subdomains have valid SPF records that allow.


DEFAULT DENY ALL … except …

But this seems to imply problems with a sender’s wildcard dns?

Aloha,

Michael.

--

*Michael J Wise*
MicrosoftCorporation| Spam Analysis

"Your Spam Specimen Has Been Processed."

Open a ticket for Hotmail 
<http://go.microsoft.com/fwlink/?LinkID=614866> ?


*From:*mailop  *On Behalf Of *Mark Alley 
via mailop

*Sent:* Thursday, May 16, 2024 3:11 PM
*To:* mailop@mailop.org
*Subject:* [EXTERNAL] [mailop] v=spf1 -all SPF treewalk?

Hey all, got a dubious claim I read today that's somewhat of a 
head-scratcher.


Let's lay out the scenario.

  * The following DNS answers are returned when queried (pseudocode):
  o domain.com IN TXT "v=spf1 -all"
  o test.domain.com IN TXT  - NXDOMAIN
  o _dmarc.test.domain.com IN TXT - NXDOMAIN
  o _dmarc.domain.com IN TXT - NXDOMAIN

  * An email is sent with the RFC5321.mailfrom and RFC5322.from
"t...@test.domain.com" <mailto:t...@test.domain.com>.
  * The email is not signed with DKIM.
  * The HELO FQDN has an SPF record with the corresponding MTA's IP in it.

This claim stated that (and I'm quoting verbatim here), "/I forced 
many ESPs to start failing SPF for any subdomain of a domain that has 
no explicit SPF, and fails SPF at the *primary domain level* /(Context 
note: when/v=spf1 -all /exists at the primary domain)".


Has anyone observed or heard of this SPF treewalk-esque evaluation 
logic being used by Receivers when an empty SPF fail policy is used at 
the organizational domain, but the subdomain used for SPF evaluation 
doesn't exist?


- Mark Alley
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] v=spf1 -all SPF treewalk?

[Mark Alley via mailop]

Hey all, got a dubious claim I read today that's somewhat of a 
head-scratcher.


Let's lay out the scenario.

 * The following DNS answers are returned when queried (pseudocode):
 o domain.com IN TXT "v=spf1 -all"
 o test.domain.com IN TXT  - NXDOMAIN
 o _dmarc.test.domain.com IN TXT - NXDOMAIN
 o _dmarc.domain.com IN TXT - NXDOMAIN

 * An email is sent with the RFC5321.mailfrom and RFC5322.from
   "t...@test.domain.com".
 * The email is not signed with DKIM.
 * The HELO FQDN has an SPF record with the corresponding MTA's IP in it.

This claim stated that (and I'm quoting verbatim here), "/I forced many 
ESPs to start failing SPF for any subdomain of a domain that has no 
explicit SPF, and fails SPF at the *primary domain level* /(Context 
note: when/v=spf1 -all /exists at the primary domain)".


Has anyone observed or heard of this SPF treewalk-esque evaluation logic 
being used by Receivers when an empty SPF fail policy is used at the 
organizational domain, but the subdomain used for SPF evaluation doesn't 
exist?



- Mark Alley

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

Re: [mailop] "The email didn't arrive" to Office 365

[Mark Alley via mailop]

On 5/9/2024 3:51 PM, Gellner, Oliver via mailop wrote:

On 09.05.2024 at 20:21 Jarland Donnell via mailop wrote:

Quick question for you experts. What do you find to be the most common root 
cause for reports of emails not being received by Office 365 domains, when you 
can confirm conclusively that Microsoft accepted the email? Obviously spam 
folder delivery should rank high, but what else? Are there admin settings for 
Office 365 organizations that result in emails being accepted by their servers 
but not delivered to the recipients? Maybe quarantined somewhere?

To add more details to the already given answers based on my limited 
experience. It’s a little bit more complicated:

- There is a spam folder in the mailbox of the recipient, called „Junk“. This 
folder is accessible by the recipient, but many people do not actively monitor 
it. The recipient does not get notified about new emails in the Junk folder.
- There are quarantines which are accessible by the recipient via a separate 
website.
- There are quarantines which are not accessible by the recipient. Which 
quarantines are accessible and which are not depends on the settings configured 
by the tenant administrator and cannot be determined from outside.
- The difference between the Junk folder and the different quarantines is that 
dangerous messages which contain malware or phishing links are supposed to end 
up in one of the quarantines, whereas plain spam messages should go to the Junk 
folder. Of course all of them can and do contain false positives.
- There are spam filters which move messages into hidden folders. While those 
messages theoretically end up in the recipients mailbox, they cannot see or 
access them, as long as they don’t mess around with the API.
- In the end, messages can also be dropped. Those are not accessible anymore by 
anyone.

Trying to offer support for employees of another company, where you have no 
insight into their IT landscape, is always difficult. I‘d give them the 
timestamp and ID under which their MX accepted and acknowledged the message. 
From there on their IT support should take over.

—
BR Oliver



Let's also not forget the helpful Inbox views, "Focused Inbox", "Other", 
and the 
junk-folder-that's-really-not-a-junk-folder-but-is-considered-one-anyway, 
"Clutter".


- Mark Alley
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Cannot send messages to Google Mail users

[Mark Alley via mailop]

On 4/24/2024 10:04 AM, Al Iverson via mailop wrote:

Is disabling IPv6 an option here? A prior poster suggested as such,
but I don't know if that was just a general suggestion or if that's
actually possible in O365 settings.

But if you can  yes, try sending outbound mail only via IPv4. A
"well known secret" is that Gmail filters mail from IPv6 connections
more harshly than IPv4. Maybe less than they once did, and certainly
you could question if it's fair or not, but I saw clear evidence of it
in the past. I personally have IPv6 disabled on my MTA because of it.

Also make sure your DKIM is set up as YOU and not just as the default
*.onmicrosoft.com that Microsoft sticks on there for those who aren't
fully configured.

If you want folks to look at headers and offer up additional
suggestions, run a test usinghttps://aboutmy.email  and share the
results link here. I'll take a look and advise, and I imagine others
will, too.

Cheers,
Al Iverson


They'd have to request it be disabled from Microsoft support. In the 
past, someone would have had to request it be enabled explicitly for it 
to be on in their Exchange Online tenant, because IPv6 is not enabled by 
default to my knowledge.


- Mark Alley
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Cannot send messages to Google Mail users

[Mark Alley via mailop]

I've also seen Google provide this error when a domain had a
spammer/phisher attempt to spoof said domain several hundred thousand
times. Since Google saw their domain in the RFC5321.Mailfrom, even though
the messages weren't authenticated and were rejected as per their DMARC
policy, the domain's mere existence in the RFC5321.Mailfrom for SPF was
enough to tank their reputation with Google to abysmal levels.

I'd suggest checking their DMARC reporting historical data (if available)
to see if this potentially occurred recently.

- Mark Alley


Sent from mobile, please excuse any typos.

On Wed, Apr 24, 2024, 5:09 AM Matus UHLAR - fantomas via mailop <
mailop@mailop.org> wrote:

> On 24.04.24 07:28, Simon Branch via mailop wrote:
> > For the past 2 weeks, we have been unable to send mails to any gmail
> users,
> > nor any email domains hosted on Google's mail servers.  We are using
> > Microsoft 365.
>
> So I assume you send your mail through microsoft/outlook servers, you
> can't
> your outgoing IP, and don't need to change it.
>
> > Every time we attempt to send a message, we get the following
> bounce-back:
> >
> > 550 5.7.350 Remote server returned message detected as spam -> 550 5.7.1
> [2a01:111:f403:261b::700 19] Gmail has detected that this message;is likely
> suspicious due to the very low reputation of the sending;domain.
> > To best protect our users from spam, the message has been;blocked. For
> more information, go to; https://support.google.com/mail/answer/188131
> im8-20020a056214246800b00696b2e6b32asi14453219qvb.337 - gsmtp
> >
> > I have been in touch with Microsoft 365 support and they have double
> > checked our SPF / DMARC / DKIM records and all are correct.
> >
> > The only advice Microsoft will give is to speak to Google.
> >
> > I have filled out one of Googles email cases, explaining that our DNS
> > records are set up correctly and we are not spamming.
> >
> > Unfortunately, we have had no reply after a week.
> >
> > Is there anything we can do to help resolve the issue?
>
> I had similar problem with out customers' domain a few months ago.
> The problem happened because of spamming from that domain (hijacked
> account), while SPF and DKIM were correct.
>
> It took about month until mail started working.
>
> Make sure nobody did spam/mailbomb from your domain while having matching
> SPF/DKIM.  I guess that could include forwarding of spam messages or
> creating mail loop etc.  I also guess you signed into google postmaster
> tools and configured your domain.
>
> https://postmaster.google.com/
>
> check SPF/DKIM records if they don't allow sending authenticated mail from
> other places.
>
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> Fighting for peace is like fucking for virginity...
> ___
> 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] freenet.de routing issues anyone? (Cloudflare-OVH issue?)

[Mark Alley via mailop]

+1

- Mark Alley

On 3/8/2024 10:01 AM, Bill Cole via mailop wrote:

On 2024-03-08 at 09:13:32 UTC-0500 (Fri, 8 Mar 2024 15:13:32 +0100)
Stefano Bagnara via mailop 
is rumored to have said:


Well,

I undestand you all hate OVH, but this really doesn't look like an
intended block.


Sure it does.


I tested that when I log to my @freenet.de email I am not able to
write emails to any domain whose DNS are hosted by OVH.


That really looks like an intended block...


I know plenty
of italian companies whose domain zone is at OVH: even if their email
is at Google Workspace or somewhere else they currently cannot receive
emails from @freenet.de and you are telling me this is something
freenet.de done by purpose beucase they didn't want OVH spam? I'll
believe that once a freenet.de people will confirm it.

Considering OVH is the biggest registar in europe they are not
delivering email to most european domains.


Registrars, DNS providers, and hosters are very different things, even 
if they happen to sometimes be the same entity. For example, half of 
the domains I own don't even use DNS from their registrar, who doesn't 
even sell hosting.


OVH being a major registrar doesn't mean much. OVH providing a lot of 
DNS for their registration customers means a bit more, but one can 
resolve DNS indirectly so it's not huge. Being a massive hoster makes 
the cost of blocking them significant, but not necessarily excessive 
for some providers. Freenet.de knows their users better than you do. 
They may have a thousand pinhole exemptions from that blocking making 
the effective price for their customers near zero.



So, if they blocked the whole OVH ASN at their SMTP server I could
even get that (even if I'm not aware of anyone else doing that),


I block OVH ranges by announced route when I see anything in the range 
sending me spam, unless there's a concrete reason not to. It's not 
worthwhile to block by ASN, especially as I am not doing the blocking 
in BGP.



but I
really don't believe they blocked bidirectional routing between 2 ASN
just because freenet thinks OVH is spammy. We hardly see a similar
block when there is a war between 2 countries.


All of your argumentation against this being an intentional block is 
based on the fact that it isn't something YOU would do, because YOU 
would find the cost unacceptable.


That's not a very useful class of reasoning, especially when it is 
inconsistent with evidence. The evidence suggests a broad block of OVH 
by Freenet. That should not happen easily by accident, although it 
certainly could. It is far more likely that it was entirely 
intentional, but lacked careful analysis of the negative effects. It 
is possible that it was entirely intentional and the risks 
pre-mitigated in ways that you cannot see.






Stefano

On Fri, 8 Mar 2024 at 14:49, Yuval Levy via mailop 
 wrote:


On 2024-03-08 07:48, Stefano Bagnara via mailop wrote:
On Fri, 8 Mar 2024 at 13:04, Mark Alley  
wrote:

Have you considered they may be blocking OVH ASNs on their firewall?


Well, blocking the whole ASNs even to their NS sounds something very
unexpected.


Extreme, yes. Unexpected? I disagree.  It is just another logical
escalation step towards the inevitable, but nothing new. Think of a
collision between the internet's echo chambers and the Great Firewall:
one side wants to control what the other side receives; and the other
side wants to control what it does not receive.

Simple Venn diagram.  When the intersection between the two circles
(agreement on what both sides want to send/receive) has less net value
than one of the two separate half-moons, the concerned side may as well
block the whole ASN: the cost of sacrificing the intersection is lower
than the benefit from allowing the communication less the
filtering/sanitation cost.

Once one side decides that it gets less benefits than cost from the
communication, the other side has three strategic choices: giving more
value; causing less cost; or accepting the disconnect.  They are now at
the accepting the disconnect, waiting to see who blinks first.  If
no-one blinks, the disconnect becomes permanent.

The problem is compounded by aggregation on the two sides: well behaved
senders will put pressure on their side; the rats may abandon ship and
raid the next ISP with weak policies.  Affected recipients will put
pressure on their side to remove the filter.  The question is where
those pressures will burst.  My hope is that someone at OVH will 
wake up

and mop up the neighborhood that they control.

Personally, I am still looking for the ideal firewall: block all ASNs
unless permitted.  And even after that, the next battlefields are
already in sight: wireless network traversal.

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




--
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop 

Re: [mailop] freenet.de routing issues anyone? (Cloudflare-OVH issue?)

[Mark Alley via mailop]

Having seen this behavior before from overzealous network admins,
especially given the fact that freenet owns their netblock and their NS are
self-hosted on said netblock rather than cloud DNS SaaS, it's very likely a
firewall rule.

I wouldn't be surprised if it was the case, OVH isn't exactly known for
reputable traffic.

- Mark Alley


On Fri, Mar 8, 2024, 6:48 AM Stefano Bagnara  wrote:

> On Fri, 8 Mar 2024 at 13:04, Mark Alley  wrote:
> > Have you considered they may be blocking OVH ASNs on their firewall?
>
> Well, blocking the whole ASNs even to their NS sounds something very
> unexpected. This mean any service (not only email) that is hosted in
> OVH (in europe is the biggest provider) thinks their domains don't
> even exists.
> Also, freenet.de users are not able to write emails to anyone having
> the DNS hosted at OVH (millions of domains): sounds like burning your
> house to protect it from thieves :-D
>
> Seems like AS5430 and AS16276 are not talking at all, but I don't know
> how confirm it and how to check where is the issue in more detail.
>
> > Their NS and zone seems resolvable and reachable from pretty much
> everything else on the internet according to DNSchecker.org.
>
> Here you can see their NS IP is not reachable from 7 on 30 location
> being tested from western europe:
> https://www.host-tracker.com/en/ic/3/189c2804-114d-4be7-94e5-716f131bc458
>
> So, I think the issue is more on freenet side than OVH side, but I'd
> need someone who knows or have powers to check.
>
> Now I also wrote an email to the noc/peer emails for both ASN.
> Stefano
>
> > On Fri, Mar 8, 2024, 5:54 AM Stefano Bagnara via mailop <
> mailop@mailop.org> wrote:
> >>
> >> Hi,
> >>
> >> I'm experiencing routing issues to freenet.de MX since almost 3 days.
> >>
> >> 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:
> >>
> >> 194.97.8.138
> >> 195.4.92.217
> >>
> >> From my servers @OVH they are not reachable at all.
> >>
> >> I checked the IPs at https://check-host.net/check-ping and I see both
> >> IP pings from most places but a netherland one, hong kong and 4
> >> russians sources (by comparison my own IPs are reachable from all of
> >> those sources).
> >>
> >> Failing traceroutes from check-host.net and from my IPs stuck at a
> >> Cloudflare IP:
> >>
> >> # traceroute 194.97.8.138
> >> traceroute to 194.97.8.138 (194.97.8.138), 30 hops max, 60 byte packets
> >>  1  MYIP  0.373 ms  0.484 ms  0.590 ms
> >>  2  10.17.50.74 (10.17.50.74)  0.356 ms 10.17.50.72 (10.17.50.72)
> >> 0.396 ms  0.458 ms
> >>  3  10.73.17.68 (10.73.17.68)  0.101 ms 10.73.16.116 (10.73.16.116)
> >> 0.107 ms 10.73.17.70 (10.73.17.70)  0.134 ms
> >>  4  10.95.64.142 (10.95.64.142)  1.027 ms 10.95.64.156 (10.95.64.156)
> >> 0.424 ms 10.95.64.136 (10.95.64.136)  0.421 ms
> >>  5  par-gsw-sbb1-nc5.fr.eu (54.36.50.228)  3.949 ms  3.825 ms  3.821 ms
> >>  6  10.200.2.85 (10.200.2.85)  4.079 ms 10.200.2.77 (10.200.2.77)
> >> 71.136 ms  71.123 ms
> >>  7  * * *
> >>  8  172.71.120.4 (172.71.120.4)  4.689 ms 141.101.67.52
> >> (141.101.67.52)  4.538 ms  4.578 ms
> >>  9  172.71.133.105 (172.71.133.105)  3.842 ms 172.71.129.237
> >> (172.71.129.237)  4.226 ms 172.69.187.98 (172.69.187.98)  4.214 ms
> >> 10  172.71.133.23 (172.71.133.23)  5.352 ms 172.71.117.70
> >> (172.71.117.70)  4.631 ms 172.71.121.67 (172.71.121.67)  4.512 ms
> >> 11  * * *
> >> 12  * * *
> >> 13  * * *
> >>
> >> I thought it was a peering issue, but 3 days should be enough for
> >> someone to detect and fix it.
> >>
> >> It doesn't look like a blacklisting issue as I cannot even query their
> >> authoritative NS and I can't do that even from IPs that never sent
> >> emails.
> >>
> >> I also checked OVH looking glass and they fail routing to freenet from
> >> all of their DCs:
> >>
> https://lg.ovh.net/traceroute/sgp+vin+sbg+bhs+hil+rbx+lim+bom+gra+waw+syd1+eri/ipv4?q=194.97.8.138
> >>
> >> I also tried using OVH hosted email to write an email to a freenet.de
> >> domain and it resulted in a "Domain not found" error, so to confirm
> >> the whole OVH network can't reach the freenet.de NS.
> >>
> >> I opened a ticket to OVH but they closed it telling me the traceroute
> >> show the problem in outside their network (last working hop is a
> >> cloudflare IP).
> >>
> >> Peering/routing is not my field, so I'm looking for other people with
> >> problems sending emails to freenet.de and for suggestions on how/who
> >> to contact to fix the issue (maybe I should look for an NOC-op mailing
> >> list?) .
> >>
> >> Stefano
> >>
> >> --
> >> Stefano Bagnara
> >> Apache James/jDKIM/jSPF
> >> VOXmail/Mosaico.io/VoidLabs
> >> ___
> >> mailop mailing list
> >> mailop@mailop.org
> >> https://list.mailop.org/listinfo/mailop
>
>
>
> --
> Stefano Bagnara
> Apache James/jDKIM/jSPF
> VOXmail/Mosaico.io/VoidLabs
>
___
mailop 

Re: [mailop] freenet.de routing issues anyone? (Cloudflare-OVH issue?)

[Mark Alley via mailop]

Have you considered they may be blocking OVH ASNs on their firewall?

Their NS and zone seems resolvable and reachable from pretty much
everything else on the internet according to DNSchecker.org.

- Mark Alley


On Fri, Mar 8, 2024, 5:54 AM Stefano Bagnara via mailop 
wrote:

> Hi,
>
> I'm experiencing routing issues to freenet.de MX since almost 3 days.
>
> 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:
>
> 194.97.8.138
> 195.4.92.217
>
> From my servers @OVH they are not reachable at all.
>
> I checked the IPs at https://check-host.net/check-ping and I see both
> IP pings from most places but a netherland one, hong kong and 4
> russians sources (by comparison my own IPs are reachable from all of
> those sources).
>
> Failing traceroutes from check-host.net and from my IPs stuck at a
> Cloudflare IP:
>
> # traceroute 194.97.8.138
> traceroute to 194.97.8.138 (194.97.8.138), 30 hops max, 60 byte packets
>  1  MYIP  0.373 ms  0.484 ms  0.590 ms
>  2  10.17.50.74 (10.17.50.74)  0.356 ms 10.17.50.72 (10.17.50.72)
> 0.396 ms  0.458 ms
>  3  10.73.17.68 (10.73.17.68)  0.101 ms 10.73.16.116 (10.73.16.116)
> 0.107 ms 10.73.17.70 (10.73.17.70)  0.134 ms
>  4  10.95.64.142 (10.95.64.142)  1.027 ms 10.95.64.156 (10.95.64.156)
> 0.424 ms 10.95.64.136 (10.95.64.136)  0.421 ms
>  5  par-gsw-sbb1-nc5.fr.eu (54.36.50.228)  3.949 ms  3.825 ms  3.821 ms
>  6  10.200.2.85 (10.200.2.85)  4.079 ms 10.200.2.77 (10.200.2.77)
> 71.136 ms  71.123 ms
>  7  * * *
>  8  172.71.120.4 (172.71.120.4)  4.689 ms 141.101.67.52
> (141.101.67.52)  4.538 ms  4.578 ms
>  9  172.71.133.105 (172.71.133.105)  3.842 ms 172.71.129.237
> (172.71.129.237)  4.226 ms 172.69.187.98 (172.69.187.98)  4.214 ms
> 10  172.71.133.23 (172.71.133.23)  5.352 ms 172.71.117.70
> (172.71.117.70)  4.631 ms 172.71.121.67 (172.71.121.67)  4.512 ms
> 11  * * *
> 12  * * *
> 13  * * *
>
> I thought it was a peering issue, but 3 days should be enough for
> someone to detect and fix it.
>
> It doesn't look like a blacklisting issue as I cannot even query their
> authoritative NS and I can't do that even from IPs that never sent
> emails.
>
> I also checked OVH looking glass and they fail routing to freenet from
> all of their DCs:
>
> https://lg.ovh.net/traceroute/sgp+vin+sbg+bhs+hil+rbx+lim+bom+gra+waw+syd1+eri/ipv4?q=194.97.8.138
>
> I also tried using OVH hosted email to write an email to a freenet.de
> domain and it resulted in a "Domain not found" error, so to confirm
> the whole OVH network can't reach the freenet.de NS.
>
> I opened a ticket to OVH but they closed it telling me the traceroute
> show the problem in outside their network (last working hop is a
> cloudflare IP).
>
> Peering/routing is not my field, so I'm looking for other people with
> problems sending emails to freenet.de and for suggestions on how/who
> to contact to fix the issue (maybe I should look for an NOC-op mailing
> list?) .
>
> Stefano
>
> --
> Stefano Bagnara
> Apache James/jDKIM/jSPF
> VOXmail/Mosaico.io/VoidLabs
> ___
> 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] mimecast "antispoofing"

[Mark Alley via mailop]

On 3/5/2024 3:01 PM, Julian Bradfield via mailop wrote:

What should they be doing according to "best practice"?


Not rejecting mail based solely on SPF results.

- Mark Alley
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Dot as the first character of a line ? (RFC 5321, Section 4.5.2)

[Mark Alley via mailop]

Unless I'm missing something, it's the first bullet in RFC5321 4.5.2.

- Mark Alley


On 3/1/2024 3:49 PM, Cyril - ImprovMX via mailop wrote:

@Julien Bradfield:
I've initially shared the exact line in the code on what Aiosmtpd - 
not my software - is doing, which it is saying is following the RFC by 
removing the first character if it's a dot. I could share emails that 
went through Aiosmtpd and another that didn't, which would only show 
that the one that didn't still has a starting dot whereas the other 
doesn't. I don't see what I can add on top of that. It seems clear, 
precise and detailed as it includes references and links. If anything 
is missing, coud you please ask clearly and precisely what do you 
expect more from it?


@John Levine , I'm not sure which line you are 
mentioning, the one I used from the RFC ("... If the first character 
is a period and there are other characters on the line, the first 
character is deleted.") does mention "deleted", not "inserted".

From where did you get your quote?


Le ven. 1 mars 2024 à 20:04, John Levine  a écrit :

It appears that Cyril - ImprovMX via mailop  said:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>Just to clarify, I'm not trying to pin some issue on a company
(Google) but
>I'm trying to understand why aiosmtpd seems to follow an RFC that
>appears to be clear on the behavior, that GMail doesn't do but
doesn't
>appear to be the only one (as my user is generating a document
that also
>doesn't seems to follow it).
>
>I'm more thinking about a different interpretation on the RFC
that leads to
>various behavior between aiosmtpd and (some) others.

You might want to reread the paragraph before the one you quoted
in your last message:

   o  Before sending a line of mail text, the SMTP client checks the
      first character of the line.  If it is a period, one additional
      period is inserted at the beginning of the line.

It's quite clear, and if your software isn't adding a second dot
in front of the
line that starts with a dot, it's wrong.

R's,
John


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


--
- Mark Alley
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail.com SPF false negatives?

[Mark Alley via mailop]

On 2/28/2024 6:53 AM, Benny Pedersen via mailop wrote:

L. Mark Stone via mailop skrev den 2024-02-27 23:52:

I believe you need a DMARC record...


does this fix spf fails ?


Not directly, but for some evaluator configurations, it may alter their 
disposition handling behavior if a DMARC policy exists (even p=none).


- Mark Alley
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Anyone else noticing an increase in spam from Office365 distribution lists?

[Mark Alley via mailop]

Ah, yep, thanks for catching that typo.

On 1/14/2024 4:56 PM, Andrew C Aitchison wrote:

On Sun, 14 Jan 2024, Mark Alley via mailop wrote:

This is anecdotal, but I think it illustrates even at a smaller scale 
the persistent problem Microsoft currently has with their tenancy.


I did some quick perusal of the last month's data from our email 
logs, and out of a total of 22,473 external emails that contain a 
.onmicrosoft.com subdomain in the RFC5322.FROM field -- 22,086 were 
blocked because of various reasons:


* 21,228 spam
* 1 malware
* 759 phishing
* 5 impostor
* 93 "hard" failed SPF without a DMARC record since onmicrosoft.com
  doesn't have one. (probably forwarded)

387 "clean" emails were delivered successfully initially, and 151 of 
those initial delivers were then later retroactively classified as 
being spam or phishing.


So even at this scale, we're left with a minutia of ~0.01%


  236/22473 ~= 1%

"legitimate" emails, most of which are from misconfigured Exchange 
Online mailboxes or Office365 groups from various businesses.


So, YMMV widely, but for most organizations, as John said, definitely 
not going to be missing /too /much. Most of what I see that's 
legitimate in our traffic would be 3 or 4 specific subdomain 
additions to a safelist from the hypothetical block rule, and that 
would be it.


- Mark Alley
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Anyone else noticing an increase in spam from Office365 distribution lists?

[Mark Alley via mailop]

This is anecdotal, but I think it illustrates even at a smaller scale 
the persistent problem Microsoft currently has with their tenancy.


I did some quick perusal of the last month's data from our email logs, 
and out of a total of 22,473 external emails that contain a 
.onmicrosoft.com subdomain in the RFC5322.FROM field -- 22,086 were 
blocked because of various reasons:


 * 21,228 spam
 * 1 malware
 * 759 phishing
 * 5 impostor
 * 93 "hard" failed SPF without a DMARC record since onmicrosoft.com
   doesn't have one. (probably forwarded)

387 "clean" emails were delivered successfully initially, and 151 of 
those initial delivers were then later retroactively classified as being 
spam or phishing.


So even at this scale, we're left with a minutia of ~0.01% "legitimate" 
emails, most of which are from misconfigured Exchange Online mailboxes 
or Office365 groups from various businesses.


So, YMMV widely, but for most organizations, as John said, definitely 
not going to be missing /too /much. Most of what I see that's legitimate 
in our traffic would be 3 or 4 specific subdomain additions to a 
safelist from the hypothetical block rule, and that would be it.


- Mark Alley

On 1/14/2024 12:17 PM, John Levine via mailop wrote:

It appears that Russell Clemings via mailop  said:

"You can keep using the initial onmicrosoft.com domain even after you add
your domain. It still works for email and other services, so it's your
choice."

... or am I misunderstanding?

I'm tempted to block *. onmicrosoft.com completely but I'm very afraid.

I concur with the advice to block it.  You're not going to miss any mail
you care about.

R's,
John
___
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] Proofpoint mailop contact?

[Mark Alley via mailop]

Check if your IPs are listed on PDR , usually that's why. A manager over 
PPE is on-list too, I believe.


https://ipcheck.proofpoint.com/

- Mark Alley

On 1/5/2024 3:37 PM, Thomas Johnson via mailop wrote:

Hello-

We're seeing some dropped connections from various servers on 
ppe-hosted.com  - the Proofpoint hosted service.


I'd like to discuss with an admin there, but I cannot locate any 
contact information online for them.


Is anyone from Proofpoint on here? Or does anyone have a contact?

Please feel free to conact me offlist, if that's preferred.

Tom


___
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] DMARC processing

[Mark Alley via mailop]

Is that on Github somewhere? I'd be glad to add it to the list.

On 12/19/2023 9:20 AM, Slavko via mailop wrote:

Dňa 19. decembra 2023 15:02:15 UTC používateľ Mark Alley via 
mailop  napísal:

https://dmarcvendors.com/#Self-Hosted_Solutions

I use own python script (piped from exim), which extracts report's
attachment, stores XML in directories (by month) and reports are
shown/parsed by nginx and its autoindex & xslt module.

regards

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

Re: [mailop] DMARC processing

[Mark Alley via mailop]

https://dmarcvendors.com/#Self-Hosted_Solutions

- Mark Alley

On 12/19/2023 2:47 AM, Eduardo Diaz Comellas via mailop wrote:

Hi,

I'm starting to deploy DMARC records in all our managed domains, but 
we don't have any specific tool to parse and extract meaningful 
information from the reports.


Do you have any recomendations?

Best regards

--
Eduardo Díaz Comellas
Ultreia Comunicaciones, S.L.

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

[mailop] SMTP smuggling

[Mark Alley via mailop]

Hey all, recently saw this mail server SMTP vulnerability that popped up on
a blog yesterday. Sharing here for those interested.

https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/

-Mark Alley
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] If one signature is good, 72 signatures must be better

[Mark Alley via mailop]

Your hypothesis is accurate; speaking from professional experience with 
Proofpoint products, there is an option within the Proofpoint PoD DKIM 
signing configuration to set the Domain scope to "Any" which will 
reproduce this behavior if someone just left the defaults when 
generating a key(s).


Apparently this organization generated ALL their domains' keys with the 
default Any scope... oof. I'm honestly not even mad, that's impressive.


- Mark Alley

On 11/16/2023 3:48 AM, Gellner, Oliver via mailop wrote:

On 16.11.2023 at 03:05 John Levine via mailop wrote:


I just got a couple of quite remarkable messages from Sabre's Tripcase service, 
confirming that they'd received some info I mailed thmm.
Below you can see the Authentication Results header my mail server added.
All 72 valid DKIM signatures really are there, and I am trying to imagine what 
kind of screwup at Proofpoint added them. If anyone would like the whole 
message, just ask. There's nothing interesting in it other than the signatures.

Probably they don't know how to apply a specific signature based on the From 
address. So instead they apply all DKIM signatures they have to all emails.
This reminds of the joke how a computer programmer would hunt a lion in Africa:
1. Go to the northernmost place
2. Traverse the continent alternately east and west working southwards
3. Catch every animal you see
4. Compare the animal to a lion
5. Stop if a match is detected

Unfortunately Sabre didn't implement step 5.

--
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 mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Potential MIT email compromise

[Mark Alley via mailop]

Hey all, anyone from MIT on list?

Seeing a significant amount of QR phishing and docusign phishing from 
MIT mail servers.


IP addresses:

18.9.28.11 (outgoing-auth-1.mit.edu)

18.4.43.33 (littlewood.mit.edu)

Header FROM: h...@math.mit.edu

Thanks,

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

Re: [mailop] hotmail.com SPF forgot IPv6

[Mark Alley via mailop]

Granted, my only point was around message rejection itself with no 
consideration for other email authentication context.


For reference, the M3AAWG BCP section 4 
<https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf> 
this is based off of -


On 8/18/2023 10:53 AM, L. Mark Stone via mailop wrote:

Got it, thanks.  We are concerned about DKIM-replay attacks, so while I now 
better understand where you are coming from, we would continue to mark such 
emails as spam and put them in the users' Junk folders.

Our view is that reputable senders should be able to manage their DNS 
accurately, understanding that we are all human and everyone makes mistakes now 
and then (be kind!).  That's why even with a hard SPF fail we mark emails as 
Spam instead of discarding them outright.

Thanks again for helping me better understand your approach here,
Mark
_
L. Mark Stone, Founder
North America's Leading Zimbra VAR/BSP/Training Partner
For Companies With Mission-Critical Email Needs

- Original Message -
From: "Mark Alley via mailop"
To: "mailop"
Sent: Friday, August 18, 2023 11:15:07 AM
Subject: Re: [mailop] hotmail.com SPF forgot IPv6



Well, if you want to accept the overwhelming amount of DMARC passing mail 
signed with DKIM (which these Hotmail messages are, because they are signed 
with valid and aligned DKIM)... then you definitely shouldn't be rejecting it 
based solely on the SPF result.


- Mark Alley
On 8/18/2023 9:54 AM, L. Mark Stone via mailop wrote:



Hi Mark,

Perhaps I'm misunderstanding your inference, but are you saying we shouldn't 
reject based on a hard fail SPF record?

Thanks,
Mark
_
L. Mark Stone, Founder
North America's Leading Zimbra VAR/BSP/Training Partner
For Companies With Mission-Critical Email Needs

- Original Message -----
From: "Mark Alley via mailop" [mailto:mailop@mailop.org  |  ] To: 
"mailop" [mailto:mailop@mailop.org  |  ] Sent: Friday, August 18, 2023 
10:33:50 AM
Subject: Re: [mailop] hotmail.com SPF forgot IPv6



This will definitely showcase how many receivers are still rejecting based on 
SPF failure by itself.


There's already many threads on Reddit about this from regular consumers 
experiencing bounces they don't know what to do with, it's actually quite sad 
reading some of them.

- Mark Alley



On 8/18/2023 9:16 AM, Laurent S. via mailop wrote:



Aloha hotmail,

It seems since you recently changed your SPF and switched from ~all to
-all. It would have been great if you didn't remove at the same time
your IPv6 ranges from it.

It seems the include:spf.protection.outlook.com was removed during the
change. You might want to include it back.

We are starting to receive quite a few tickets that our clients suddenly
don't receive some mails from hotmail.com

Best regards,
Laurent

___
mailop mailing list [ [mailto:mailop@mailop.org  |mailto:mailop@mailop.org  ] | 
[mailto:mailop@mailop.org  |mailop@mailop.org  ] ] [ 
[https://list.mailop.org/listinfo/mailop  
|https://list.mailop.org/listinfo/mailop  ] | 
[https://list.mailop.org/listinfo/mailop  
|https://list.mailop.org/listinfo/mailop  ] ]



___
mailop mailing list [mailto:mailop@mailop.org  |mailop@mailop.org  ] 
[https://list.mailop.org/listinfo/mailop  
|https://list.mailop.org/listinfo/mailop  ] 
___
mailop mailing list [mailto:mailop@mailop.org  |mailop@mailop.org  ] 
[https://list.mailop.org/listinfo/mailop  
|https://list.mailop.org/listinfo/mailop  ]



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


___
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] hotmail.com SPF forgot IPv6

[Mark Alley via mailop]

Well, if you want to accept the overwhelming amount of DMARC passing 
mail signed with DKIM (which these Hotmail messages are, because they 
are signed with valid and aligned DKIM)... then you definitely shouldn't 
be rejecting it based solely on the SPF result.


- Mark Alley

On 8/18/2023 9:54 AM, L. Mark Stone via mailop wrote:

Hi Mark,

Perhaps I'm misunderstanding your inference, but are you saying we shouldn't 
reject based on a hard fail SPF record?

Thanks,
Mark
_
L. Mark Stone, Founder
North America's Leading Zimbra VAR/BSP/Training Partner
For Companies With Mission-Critical Email Needs

- Original Message -
From: "Mark Alley via mailop"
To: "mailop"
Sent: Friday, August 18, 2023 10:33:50 AM
Subject: Re: [mailop] hotmail.com SPF forgot IPv6



This will definitely showcase how many receivers are still rejecting based on 
SPF failure by itself.


There's already many threads on Reddit about this from regular consumers 
experiencing bounces they don't know what to do with, it's actually quite sad 
reading some of them.

- Mark Alley



On 8/18/2023 9:16 AM, Laurent S. via mailop wrote:



Aloha hotmail,

It seems since you recently changed your SPF and switched from ~all to
-all. It would have been great if you didn't remove at the same time
your IPv6 ranges from it.

It seems the include:spf.protection.outlook.com was removed during the
change. You might want to include it back.

We are starting to receive quite a few tickets that our clients suddenly
don't receive some mails from hotmail.com

Best regards,
Laurent

___
mailop mailing list [mailto:mailop@mailop.org  |mailop@mailop.org  ] 
[https://list.mailop.org/listinfo/mailop  
|https://list.mailop.org/listinfo/mailop  ]



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


___
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] hotmail.com SPF forgot IPv6

[Mark Alley via mailop]

This will definitely showcase how many receivers are still rejecting 
based on SPF failure by itself.


There's already many threads on Reddit about this from regular consumers 
experiencing bounces they don't know what to do with, it's actually 
quite sad reading some of them.


- Mark Alley


On 8/18/2023 9:16 AM, Laurent S. via mailop wrote:

Aloha hotmail,

It seems since you recently changed your SPF and switched from ~all to
-all. It would have been great if you didn't remove at the same time
your IPv6 ranges from it.

It seems the include:spf.protection.outlook.com was removed during the
change. You might want to include it back.

We are starting to receive quite a few tickets that our clients suddenly
don't receive some mails from hotmail.com

Best regards,
Laurent

___
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] ANY OVH Contact?

[Mark Alley via mailop]

On 8/9/2023 3:31 AM, Jaroslaw Rafa via mailop wrote:

Dnia  9.08.2023 o godz. 11:00:12 Otto J. Makela via mailop pisze:

Unless the situation has dramatically changed in the last year,
OVH has no functioning abuse team. I block a majority of their nets
from sending email, don't seem to getting any false positives.

Luckily you don't block the net where my server is located, otherwise you
would get a false positive, if I would send mail to you...


Even by merely glancing at one of those subnets 15.204.0.0/17, I see a 
relatively sizable mail filter, Vadesecure, hosting their MTAs there.


- Mark Alley
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Puma email admins

[Mark Alley via mailop]

Anyone on list happen to have contacts with Puma.com email admins?

Emails from their invoice billing vendor Billtrust are failing SPF, and 
subsequently DMARC.


- Mark Alley
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Mark Alley via mailop]

On 6/20/2023 12:20 PM, Benny Pedersen via mailop wrote:

Mark Alley via mailop skrev den 2023-06-20 19:05:

You'll need to add the DKIM selector (and key) Sophos generated for
you to your external DNS provider so that other receivers can resolve
the key, which enables them to validate messages signed by your email
filter.


if sophos like to change custommers dns, then sophos is loosing


How does one expect another (external) mail server to resolve your 
public key if by not adding it to external DNS? Key-telepathy?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Mark Alley via mailop]

You'll need to add the DKIM selector (and key) Sophos generated for you 
to your external DNS provider so that other receivers can resolve the 
key, which enables them to validate messages signed by your email filter.


- Mark Alley

On 6/20/2023 11:53 AM, Salvatore Jr Walter P via mailop wrote:


OK, we are still having issues with this.

We are using Sophos as an email gateway.

They generated a DKIM record and are telling us we need to send that 
to our domain registrar to add it to our DNS records?


Is this correct? I understood DKIM was server side only?

*From:* mailop  *On Behalf Of *Salvatore Jr 
Walter P via mailop

*Sent:* Friday, June 16, 2023 2:06 PM
*To:* 'mailop@mailop.org' 
*Subject:* [EXT] - [mailop] Dkim fails, success on same email?

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


sophospsmartbannerend

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___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Twitter DKIM/DMARC Fails

[Mark Alley via mailop]

Looks specific to several of their NS' in the "u06" subdomain. 
Everything returned from the "r06" servers resolves correctly.


a.u06.twtrdns.net

b.u06.twtrdns.net

c.u06.twtrdns.net

d.u06.twtrdns.net

On 6/20/2023 11:17 AM, Tom Bartel via mailop wrote:
Twitter seems to have copy/pasted quoted string into "some" of the DNS 
servers such that were logging copious errors. Anyone else seeing this?

Bad record:
dig dkim-201406._domainkey.twitter.com    txt

; <<>> DiG 9.10.6 <<>> dkim-201406._domainkey.twitter.com  
  txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1956
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;dkim-201406._domainkey.twitter.com  . IN   TXT

;; ANSWER SECTION:
dkim-201406._domainkey.twitter.com  . 60 IN TXT "\"v=DKIM1; 
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwe34ubzrMzM9sT0XVkcc3UXd7W+EHCyHoqn70l2AxXox52lAZzH/UnKwAoO+5qsuP7T9QOifIJ9ddNH9lEQ95Y/GdHBsPLGdgSJIs95mXNxscD6MSyejpenMGL9TPQAcxfqY5xPViZ+1wA1qcr\"
 \"yjdZKRqf1f4fpMY+x3b8k7H5Qyf/Smz0sv4xFsx1r+THNIz0rz" 
"k2LO3GvE0f1ybp6P+5eAelYU4mGeZQqsKw/eB20I3jHWEyGrXuvzB67nt6ddI+N2eD5K38wg/aSytOsb5O+bUSEe7P0zx9ebRRVknCD6uuqG3gSmQmttlD5OrMWSXzrPIXe8eTBaaPd+e/jfxwIDAQAB\""

;; Query time: 170 msec
;; SERVER: 10.1.5.4#53(10.1.5.4)
;; WHEN: Tue Jun 20 12:08:03 -03 2023
;; MSG SIZE  rcvd: 485
Bad record:
dig dkim-201406._domainkey.twitter.com    txt 
+short
"\"v=DKIM1; 
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwe34ubzrMzM9sT0XVkcc3UXd7W+EHCyHoqn70l2AxXox52lAZzH/UnKwAoO+5qsuP7T9QOifIJ9ddNH9lEQ95Y/GdHBsPLGdgSJIs95mXNxscD6MSyejpenMGL9TPQAcxfqY5xPViZ+1wA1qcr\"
 \"yjdZKRqf1f4fpMY+x3b8k7H5Qyf/Smz0sv4xFsx1r+THNIz0rz" 
"k2LO3GvE0f1ybp6P+5eAelYU4mGeZQqsKw/eB20I3jHWEyGrXuvzB67nt6ddI+N2eD5K38wg/aSytOsb5O+bUSEe7P0zx9ebRRVknCD6uuqG3gSmQmttlD5OrMWSXzrPIXe8eTBaaPd+e/jfxwIDAQAB\""
Good record:
dig dkim-201406._domainkey.twitter.com    txt

; <<>> DiG 9.10.6 <<>> dkim-201406._domainkey.twitter.com  
  txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25524
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;dkim-201406._domainkey.twitter.com  . IN   TXT

;; ANSWER SECTION:
dkim-201406._domainkey.twitter.com  . 6 IN TXT  "v=DKIM1; 
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwe34ubzrMzM9sT0XVkcc3UXd7W+EHCyHoqn70l2AxXox52lAZzH/UnKwAoO+5qsuP7T9QOifIJ9ddNH9lEQ95Y/GdHBsPLGdgSJIs95mXNxscD6MSyejpenMGL9TPQAcxfqY5xPViZ+1wA1qcr"
 
"yjdZKRqf1f4fpMY+x3b8k7H5Qyf/Smz0sv4xFsx1r+THNIz0rzk2LO3GvE0f1ybp6P+5eAelYU4mGeZQqsKw/eB20I3jHWEyGrXuvzB67nt6ddI+N2eD5K38wg/aSytOsb5O+bUSEe7P0zx9ebRRVknCD6uuqG3gSmQmttlD5OrMWSXzrPIXe8eTBaaPd+e/jfxwIDAQAB"

;; Query time: 191 msec
;; SERVER: 10.1.5.4#53(10.1.5.4)
;; WHEN: Tue Jun 20 12:03:30 -03 2023
;; MSG SIZE  rcvd: 480
Good record:
dig scph0618._domainkey.i.drop.com    txt +short
"v=DKIM1; k=rsa; h=sha256; 
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsj4i57bbiuDFupkAlTYX3E/DD6eq+kcr3KQ5MnbdIXIUYTC1cJ0AhMCv2HHJxztIsFt6HlQUF2GOVrxKX3UUibf9Gmum7GHVqms5/Ok+2m1/sRqOcqYwR4Xt67N5cyiTViURMuWcUOK5bTp3+WQR8/FjlUXPvTdhma7Rvs4qznwIDAQAB"

--
Phone: 303.517.9655
Instagram: https://instagram.com/bartel_photo

"Life's most persistent and urgent question is, 'What are you doing 
for others?'" - Martin Luther King Jr.


___
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] SPF: Does include: a host without TXT entry invalidate the whole SPF entry?

[Mark Alley via mailop]

https://datatracker.ietf.org/doc/html/rfc7208#section-5.2

See the table at the bottom of the section regarding recursive check_host()
evaluation.

In this case, the recursive check_host() function returned "none" as a
result from the include mechanism, and therefore according to the table,
the parent check_host() function returns permerror as a result.

So your customer is correct.

-Mark Alley

On Tue, Jun 6, 2023, 2:42 AM Benoit Panizzon via mailop 
wrote:

> Hi List
>
> One more technical question after some discussion with one of our
> customers.
>
> Sender has SPF entry:
>
> "v=spf1 ip4:10.1.2.0/25 include:_spf.example.com -all"
>
> _spf.example.com either has no txt entry or just does not exist.
>
> So from my point of view, the SPF entry is still valid as it has at
> least one valid element which designates an ip range which wending is
> permitted.
>
> My customer claims an invalid include: renders the whole entry invalid
> causing some service provider to classify such emails as spam.
>
> Mit freundlichen Grüssen
>
> -Benoît Panizzon-
> --
> I m p r o W a r e   A G-Leiter Commerce Kunden
> __
>
> Zurlindenstrasse 29 Tel  +41 61 826 93 00
> CH-4133 PrattelnFax  +41 61 826 93 01
> Schweiz Web  http://www.imp.ch
> __
> ___
> 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] When Will Outlook Rollout SRS for All of Their Email Servers? (For the sake of bimi)

[Mark Alley via mailop]

Update on this - it appears that Google will now be restricting BIMI
display to specifically DKIM authenticated mail.

Link below, see the update on the article.

https://www.scmagazine.com/news/email-security/gmail-spoofing-google-priority-1-probe

"This issue stems from a third-party security vulnerability allowing bad
actors to appear more trustworthy than they are. To keep users safe, we are
requiring senders to use the more robust DomainKeys Identified Mail (DKIM)
authentication standard to qualify for Brand Indicators for Message
Identification (blue checkmark) status.”


On Mon, Jun 5, 2023, 7:17 PM Mark Alley  wrote:

> Last time it was reported to Microsoft, IIRC the individual got the
> response, "it's working as expected" as to the vulnerability that allows
> aligned SPF mail to be forwarded without SRS from any tenant.
>
> Realistically, DMARC and BIMI are working as expected in this scenario.
> Email was (re)sent from an (at the time) authorized IP address and an
> aligned RFC5321.mailfrom header for ups.com. The fault lies partly with
> UPS for keeping the include for Exchange Online in their Hosted SPF macro
> (unnecessary because they don't send directly from O365), and partly with
> Microsoft for allowing and enabling this forwarding vulnerability to exist.
>
> O365 customers can mitigate this by ensuring they sign DKIM and remove the
> O365 include where feasible (only possible if O365 is not a domain's last
> hop), or by signing DKIM and making the O365 include a SPF neutral
> disposition.
>
> The former is the easiest and least impactful, assuming one meets that
> criteria; The latter - it's a dirty fix - but current reality is anyone
> that uses O365 relying on their SPF include will be vulnerable to this
> until Microsoft fixes the root cause.
> - Mark Alley
>
>
>
> On 6/5/2023 6:06 PM, Al Iverson via mailop wrote:
>
> How long until Google, Yahoo, others stop accepting that forwarded
> mail from Microsoft, is another way to frame that.
>
> Good to see it getting some attention. I'll be curious to see who
> addresses it and how.
>
> Cheers,
> Al Iverson
>
> On Mon, Jun 5, 2023 at 3:01 PM Alex Liu via mailop  
>  wrote:
>
>
> Looks like the bad guys are exploiting Outlook's forwarding feature to bypass 
> BIMI.
> https://twitter.com/chrisplummer/status/1664075886545575941
>
> We reported this issue in 
> April:https://www.sysnet.ucsd.edu/~voelker/pubs/forwarding-eurosp23.pdf
>
> --
> Regards,
> Enze "Alex" Liu
> PhD Student
> Department of Computer Science and engineeringe7...@eng.ucsd.edu
> University of California, San Diego
> ___
> mailop mailing listmailop@mailop.orghttps://list.mailop.org/listinfo/mailop
>
>
>
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] When Will Outlook Rollout SRS for All of Their Email Servers? (For the sake of bimi)

[Mark Alley via mailop]

On 6/5/2023 7:41 PM, Benny Pedersen via mailop wrote:

Mark Alley via mailop skrev den 2023-06-06 02:17:

O365 customers can mitigate this by ensuring they sign DKIM and remove
the O365 include where feasible (only possible if O365 is not a
domain's last hop), or by signing DKIM and making the O365 include a
SPF neutral disposition.


this is more or less not needed if dmarc is strict, or if sender wants 
aligned emails, and reject the rest, also adsp is usefull


UPS is at a DMARC reject policy, and look what good it did them - it didn't.

This issue revolves around a "feature" that exists in Office 365; if one 
doesn't mitigate for it and a threat actor knows the method, anyone can 
spoof an SPF aligned message, forward/relay via another O365 tenant and 
produce DMARC passing mail. Hence, the recommendation.


The point is to ensure that, specifically, no other O365 tenant can send 
mail as your domain that isn't authenticated by aligned/valid DKIM 
(which you achieve by doing the aforementioned, and removing the O365 
SPF record or making the include neutral).


ADSP theoretically might also be useful for this, assuming the domain 
had no mail flow that wasn't capable of being DKIM signed, which I'm 
quite positive UPS has. I definitely wouldn't want to be their 
postmaster going to 'discard' on a whim.



- Mark Alley
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] When Will Outlook Rollout SRS for All of Their Email Servers? (For the sake of bimi)

[Mark Alley via mailop]

Last time it was reported to Microsoft, IIRC the individual got the 
response, "it's working as expected" as to the vulnerability that allows 
aligned SPF mail to be forwarded without SRS from any tenant.


Realistically, DMARC and BIMI are working as expected in this scenario. 
Email was (re)sent from an (at the time) authorized IP address and an 
aligned RFC5321.mailfrom header for ups.com. The fault lies partly with 
UPS for keeping the include for Exchange Online in their Hosted SPF 
macro (unnecessary because they don't send directly from O365), and 
partly with Microsoft for allowing and enabling this forwarding 
vulnerability to exist.


O365 customers can mitigate this by ensuring they sign DKIM and remove 
the O365 include where feasible (only possible if O365 is not a domain's 
last hop), or by signing DKIM and making the O365 include a SPF neutral 
disposition.


The former is the easiest and least impactful, assuming one meets that 
criteria; The latter - it's a dirty fix - but current reality is anyone 
that uses O365 relying on their SPF include will be vulnerable to this 
until Microsoft fixes the root cause.


- Mark Alley



On 6/5/2023 6:06 PM, Al Iverson via mailop wrote:

How long until Google, Yahoo, others stop accepting that forwarded
mail from Microsoft, is another way to frame that.

Good to see it getting some attention. I'll be curious to see who
addresses it and how.

Cheers,
Al Iverson

On Mon, Jun 5, 2023 at 3:01 PM Alex Liu via mailop  wrote:

Looks like the bad guys are exploiting Outlook's forwarding feature to bypass 
BIMI.

https://twitter.com/chrisplummer/status/1664075886545575941

We reported this issue in April:
https://www.sysnet.ucsd.edu/~voelker/pubs/forwarding-eurosp23.pdf

--
Regards,
Enze "Alex" Liu
PhD Student
Department of Computer Science and Engineering
e7...@eng.ucsd.edu
University of California, San Diego
___
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] Google Toolbox broken?

[Mark Alley via mailop]

Apologies, typo correction - *"/MX address record limitation as *10 *A 
lookups/ /instead of 1/"


On 6/2/2023 5:45 PM, Mark Alley wrote:


You'll find that several validators are somewhat liberal with 
interpretation of RFC logic and the ABNFs. So, it's not really too 
surprising.


For example, MXToolbox's SPF validator (until very recently, it seems 
they have since fixed it) used to count the number of IP addresses 
resolved from the A records returned from an MX query against the 
number of allowed A record queries in an MX RR (10), which obviously 
doesn't make sense if you read the second paragraph in RFC7208 4.6.4 
.


Prior to their update, if an A RR in an MX record had 10 IPs returned, 
it was counted against the MX address record limitation as 15 A 
lookups instead of 1, and immediately said your SPF record had errors. 
There's plenty other examples like this with other validators.


Personally, I've liked URIports  
MTA-STS/SPF/DKIM/DMARC validator, as theirs is one of several that are 
strict and accurate to RFC logic.


- Mark Alley


On 6/2/2023 3:17 PM, Gellner, Oliver via mailop wrote:

On 02.06.2023 at 10:22 Johan Lavsund via mailop wrote:
Hi Oliver,

Can you try adding a ; to the end of the dns record?
On 02.06.2023 at 10:23 Taavi Eomäe via mailop wrote:

Your DKIM TXT record seems valid, but does not specify the key type, looking at the 
length it should probably contain "k=rsa". Or they might not like you 
specifying acceptable hash algorithms.

Your mta-sts.txt does not have a trailing newline, I'm not sure if the standard 
mandates it, but that seems to be at least one of the differences.

Thank you all for the recommendations. I‘m going to add a semicolon to the 
_mta-sts entry, just to see if this alone makes a difference to that validator, 
although RFC8461 describes a trailing semicolon as optional.

I could do the same with k=rsa in the DKIM record, but as mentioned by Benny 
Pedersen this tag is optional as well and rsa is the default value anyway.
While I agree that you should be strict in what you send and liberal in what 
you receive, I‘d say that adding superfluous tags makes a policy less robust 
and not more, as it introduces additional fields which the other party might 
trip over.

The DKIM record of John Levines domain is reported as invalid too, while you 
should think that he knows his way around DKIM. So in the end this Google tool 
might in fact be buggy.

—
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 mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google Toolbox broken?

[Mark Alley via mailop]

You'll find that several validators are somewhat liberal with 
interpretation of RFC logic and the ABNFs. So, it's not really too 
surprising.


For example, MXToolbox's SPF validator (until very recently, it seems 
they have since fixed it) used to count the number of IP addresses 
resolved from the A records returned from an MX query against the number 
of allowed A record queries in an MX RR (10), which obviously doesn't 
make sense if you read the second paragraph in RFC7208 4.6.4 
.


Prior to their update, if an A RR in an MX record had 10 IPs returned, 
it was counted against the MX address record limitation as 15 A lookups 
instead of 1, and immediately said your SPF record had errors. There's 
plenty other examples like this with other validators.


Personally, I've liked URIports  
MTA-STS/SPF/DKIM/DMARC validator, as theirs is one of several that are 
strict and accurate to RFC logic.


- Mark Alley


On 6/2/2023 3:17 PM, Gellner, Oliver via mailop wrote:

On 02.06.2023 at 10:22 Johan Lavsund via mailop wrote:
Hi Oliver,

Can you try adding a ; to the end of the dns record?



On 02.06.2023 at 10:23 Taavi Eomäe via mailop wrote:

Your DKIM TXT record seems valid, but does not specify the key type, looking at the 
length it should probably contain "k=rsa". Or they might not like you 
specifying acceptable hash algorithms.

Your mta-sts.txt does not have a trailing newline, I'm not sure if the standard 
mandates it, but that seems to be at least one of the differences.

Thank you all for the recommendations. I‘m going to add a semicolon to the 
_mta-sts entry, just to see if this alone makes a difference to that validator, 
although RFC8461 describes a trailing semicolon as optional.

I could do the same with k=rsa in the DKIM record, but as mentioned by Benny 
Pedersen this tag is optional as well and rsa is the default value anyway.
While I agree that you should be strict in what you send and liberal in what 
you receive, I‘d say that adding superfluous tags makes a policy less robust 
and not more, as it introduces additional fields which the other party might 
trip over.

The DKIM record of John Levines domain is reported as invalid too, while you 
should think that he knows his way around DKIM. So in the end this Google tool 
might in fact be buggy.

—
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 mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] verifier.port25.com

[Mark Alley via mailop]

For email authentication, dmarctester.com (AKA LearnDMARC) is a good 
tool. mail-tester.com is another, and it also performs checks with 
SpamAssassin, RBLs, etc.


- Mark Alley

On 5/23/2023 1:31 PM, Blake Hudson via mailop wrote:
Looks like the email verification application at verifier.port25.com 
described in this 
(https://postmarkapp.com/blog/port25s-authentication-and-spam-assassin-tool) 
article may have been shut down.


Anyone have any insight into this or alternative tools for testing 
DKIM, SPF, and similar in one go?


--Blake
___
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] Microsoft Office365 not rejecting emails when instructed so by SPF recored?

[Mark Alley via mailop]

Assuming you're emailing someone that's an Office 365 customer, it's 
largely dependent on the receiving tenant's spam filtering configuration 
within O365 spam settings and Defender. Exchange Online itself does not 
outright reject SPF failure unless a customer has configured it to do so.


- Mark Alley


On 5/23/2023 8:35 AM, Benoit Panizzon via mailop wrote:

Hi List

I'm surprised...

six-group.com is the biggest payment platform in Switzerland. Of course
they use SPF to protect their domain from being abused by phishers.

It looks like GV0CHE01FT013.mail.protection.outlook.com is happily
accepting phishing emails which, according to SPF should get rejected.

six-group.com descriptive text "v=spf1 mx include:285283.spf01.hubspotemail.net 
include:spf.protection.outlook.com a:prodmail33a.sapsf.eu a:prodmail33b.sapsf.eu 
a:prodmail33c.sapsf.eu a:prodmail33d.sapsf.eu ip4:130.214.193.81 a:smtp.cetrel.lu 
-all"

https://www.spf-record.de/spf-lookup/six-group.com?ip=157.161.4.123

Connected to *.mail.protection.outlook.com.
Escape character is '^]'.
220 GV0CHE01FT013.mail.protection.outlook.com Microsoft ESMTP MAIL Service 
ready at Tue, 23 May 2023 13:30:12 +
ehlo example.com
250-GV0CHE01FT013.mail.protection.outlook.com Hello [157.161.4.123]
   # (yes, my actual IP)
250-SIZE 157286400
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250 SMTPUTF8
mail from:
250 2.1.0 Sender OK
rcpt to:
250 2.1.5 Recipient OK
data
354 Start mail input; end with .
PhsihPhishPhish
.
250 
2.6.0<1596b267-85c2-4695-80cb-4c354a335...@gv0che01ft013.eop-che01.prod.protection.outlook.com>
  [InternalId=139006616572402, Hostname=ZRAP278MB0141.CHEP278.PROD.OUTLOOK.COM] 7400 
bytes in 0.087, 82.746 KB/sec Queued mail for delivery

WTF!

Mit freundlichen Grüssen

-Benoît Panizzon-___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Amazon please stop your outgoing spam

[Mark Alley via mailop]

Here's a few prominent services I know of sending from this 
54.224.0.0/11 subnet. (Whether or not these are spam in your eyes is up 
to you, I'm just noting actual legitimate senders.)


 * Amazon Business (no-re...@amazon.com)
 * Amazon DE (donotre...@amazon.de)
 * Adobe (account-nore...@adobe.com)
 * Adobe Workfront (notificati...@my.workfront.com)
 * Audible (newslett...@audible.com)
 * Cisco Meraki (ship-notificat...@meraki.com)
 * SAP Concur (Concur.com/concur.de etc...)
 * Oakley.com
 * Snowflake (snowflake.net)
 * Sterling HR (verify.backgro...@sterlingcheck.com)

And that's just traffic from the last 24 hours.

- Mark Alley


On 5/12/2023 1:53 PM, Mary via mailop wrote:

not yet :D



On Fri, 12 May 2023 19:11:53 +0100 John Devine via mailop  
wrote:


Indeed so I think……….

I would so like to block as you have, any legit mail lost yet?

JD

___
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] SPF behavior on email forwarding

[Mark Alley via mailop]

My understanding is that ARC validators have a list of trusted ADMDs 
 
(domains) that they trust the ARC results of to be "accurate and true". 
If the chain is valid at receipt, all of the sealed ADMD ARC sets are 
trusted, and the authentication results were originally a DMARC pass 
result at i=1 (the first instance), it's possible to use these results 
to inform other decision making processes, such as DMARC, to override an 
otherwise failing authentication scenario.


Of course, anyone can seal ARC, but whether or not their ADMD is trusted 
by receivers is another matter. It depends on who the validator is, and 
who they trust.


- Mark Alley

On 4/14/2023 8:10 AM, Jarland Donnell via mailop wrote:

On 2023-04-14 07:45, Taavi Eomäe via mailop wrote:

On 14/04/2023 15:22, Laura Atkins via mailop wrote:
Unless they’re rewriting the envelope, yes. This is part and parcel 
of how SPF works. I’m somewhat surprised that those services are not 
rewriting the envelope, though. Unfortunately, I don’t have the 
Google access / infrastructure to test this and see what they’re doing.


Google supports ARC, SRS is a hack of the past compared to it.


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


Correct me if I'm wrong but isn't the trust level of ARC basically 
"trust me bro?" At least SRS and SPF require ownership of the domain.

___
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] agilitylive.com publishing empty SPF record

[Mark Alley via mailop]

We do try to follow general receiver best practices 
<https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf>; 
in this case, where there is no valid DMARC record/policy to follow, we 
fall back to SPF - where especially if the domain has "-all" or 
publishes "v=spf1 -all" which is intended to state the domain does not 
send mail, it will get rejected as the domain owner has specified.


This domain *does* send mail, and is actually used by Kofax for their 
CMMS system. It appears Kofax, perhaps mistakenly, thought it did not 
send mail, and published this policy as part of a DMARC project. I've 
been trying to reach out to various channels (DNS SOA admin email, 
helpdesk, LinkedIn, etc) to get them to fix this, but to no avail yet.


We could make an exception for emails from these IPs and their domain 
respectively, as they are legitimate emails and duly expected, but I'd 
rather the root problem be fixed so we as receivers do not have to 
resort to manual safelisting.


- Mark Alley


On 4/14/2023 7:15 AM, Gellner, Oliver via mailop wrote:


On 13.04.2023 at 19:37 Mark Alley via mailop wrote:

> To clarify - legitimate mail getting rejected. I have not seen any 
malicious messages from these IP's, this seems to be a recent change 
in their DNS according to securitytrails.


> On 4/13/2023 12:22 PM, Mark Alley wrote:

>> Any Kofax reps or someone who knows the owners of agilitylive.com on 
list?


>> It appears they've recently published an empty SPF record with a 
hardfail policy and an (incorrectly) placed DMARC policy of reject. 
Lots of mail getting rejected from them because of their SPF record.


The SPF record clearly states that this domain is not expected to send 
emails. I’d be interested if you make an exception for emails from 
domains with such a deny-all SPF record and reject those messages 
based solely on the SPF result. As the domain does not have a valid 
DMARC record I would otherwise expect that the emails still get accepted.


--

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 <mailto: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 Sie hier 
<https://www.dm.de/datenschutzerklaerung-kommunikation-mit-externen-493832>.


___
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] agilitylive.com publishing empty SPF record

[Mark Alley via mailop]

To clarify - /legitimate /mail getting rejected. I have not seen any 
malicious messages from these IP's, this seems to be a recent change in 
their DNS according to securitytrails.


On 4/13/2023 12:22 PM, Mark Alley wrote:


Any Kofax reps or someone who knows the owners of agilitylive.com on list?

It appears they've recently published an empty SPF record with a 
hardfail policy and an (incorrectly) placed DMARC policy of reject. 
Lots of mail getting rejected from them because of their SPF record.


IP Addresses they're sending from currently are 83.138.154.43 and 
134.213.118.100.


Thanks,

Mark Alley

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

[mailop] agilitylive.com publishing empty SPF record

[Mark Alley via mailop]

Any Kofax reps or someone who knows the owners of agilitylive.com on list?

It appears they've recently published an empty SPF record with a 
hardfail policy and an (incorrectly) placed DMARC policy of reject. Lots 
of mail getting rejected from them because of their SPF record.


IP Addresses they're sending from currently are 83.138.154.43 and 
134.213.118.100.


Thanks,

Mark Alley

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

Re: [mailop] software for a DMARC report db

[Mark Alley via mailop]

https://dmarcvendors.com/#Self-Hosted_Solutions has a list of all 
(known) self-hosted DMARC solutions, as well as the hosted SaaS ones.


If anyone on list knows of any that aren't listed, let me know and I'll 
update the site.


-Mark Alley

On 4/7/2023 12:37 PM, Michael W. Lucas via mailop wrote:

Hi,

I'm looking at setting up my own dmarc parser/aggregator db.

Searches keep leading to dmarcts-report-parser and
dmarcts-report-viewer. Is there a better option out there for
self-hosting dmarc reports, or should I go ahead?

(The projects don't look terribly active, so they're either complete
or abandoned, and searches for competitors keep leading to commercial
hosting.)

Thanks for any hints,
==ml

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

Re: [mailop] Salesforce abuse bounces

[Mark Alley via mailop]

Looks like a typoed domain.


On 4/3/2023 1:38 PM, Jay Hennigan via mailop wrote:

Trying to report spam from their network, got this:

Reporting-MTA: dns; speedy.sb.west.net
X-Postfix-Queue-ID: 4PqzpV4cYJz6N6gs
X-Postfix-Sender: rfc822; [me]
Arrival-Date: Mon,  3 Apr 2023 11:25:22 -0700 (PDT)

Final-Recipient: rfc822; ab...@asalesforce.com
Original-Recipient: rfc822;ab...@asalesforce.com
Action: failed
Status: 5.1.1
Remote-MTA: dns; smtp.secureserver.net
Diagnostic-Code: smtp; 550 5.1.1  Recipient not 
found.




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

Re: [mailop] If possible can I get a email back from someone either at Google Workspaces or Google Domains

[Mark Alley via mailop]

I replied off list.

On Tue, Mar 21, 2023, 9:54 AM Eric Tykwinski via mailop 
wrote:

>
>
>
>
> Sincerely,
>
>
>
> Eric Tykwinski
>
> TrueNet, Inc.
>
> P: 610-429-8300
>
>
> ___
> 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] [EXT] - Re: [EXT] - Re: [EXT] - Re: New member, trying to bring our mail server inline.

[Mark Alley via mailop]

That would definitely do it - does it have the ability to sign DKIM? 
Maybe you should do it there, instead of on exchange. Typically you want 
to sign DKIM at the edge.


On 3/4/2023 5:48 PM, Salvatore Jr Walter P via mailop wrote:


Something just accored to me, we have a sophos email appliance. All 
incoming and outgoing email go through that box and it scans 
everything. Do you think that may be modifying the headers before it 
leaves our network?


*From:* Josh Daynard 
*Sent:* Saturday, March 4, 2023 6:37 PM
*To:* Salvatore Jr Walter P 
*Cc:* Alessandro Vesely ; mailop@mailop.org
*Subject:* [EXT] - Re: [mailop] [EXT] - Re: [EXT] - Re: New member, 
trying to bring our mail server inline.


On Mar 4, 2023, at 3:11 PM, Salvatore Jr Walter P via mailop
 wrote:

Sorry, but I have no idea what any of that means?

what is a z tag?

I was curious as well and managed to find a decent resource here:

What-are-DKIM-Tags_.jpg

What are DKIM Tags? 

easydmarc.com 

Bottom line is that the verification error you’re seeing (“signature 
verification failed”) is an indication that one of the header fields 
being used to generate the DKIM signature (listed in the h= tag potion 
of the signature) is being altered *after* the signature has been 
generated but before the message is relayed to the destination domain.


Looks like z tags can be used in the DKIM signature for debugging 
purposes … you can copy the original header values that were present 
during signing into this tag and then when signature verification 
fails, you can compare those values to what was actually received to 
see what was altered (assuming whatever altered the header(s) won’t 
touch the z= tag in your DKIM sig!).


We had this problem early on due to some header fix-ups happening by 
the MTA post DKIM signing.  You need to be sure that DKIM Signing is 
basically the last thing that happens before a message is relayed or 
at least that none of the header fields used to generate the sig are 
altered!


You would get a different error if the public key couldn’t be 
retrieved or if the body of the message was altered (body hash mismatch).


- Josh


___
Walter P Salvatore Jr
Systems Administrator
Information Technology
City of Warwick
(401) 921-9663
https://www.warwickri.gov
walter.p.salvat...@warwickri.gov




From: Alessandro Vesely 
Sent: Saturday, March 4, 2023 7:12 AM
To: Salvatore Jr Walter P; 'mailop@mailop.org'
Subject: [EXT] - Re: [mailop] [EXT] - Re: New member, trying to
bring our mail server inline.

On Fri 03/Mar/2023 21:39:46 +0100 Salvatore Jr Walter P via mailop
wrote:

Thanks Mark. I sent an email as suggested and it came back as
a fail for DKIM.

“I see you've included a DKIM signature. I've retrieved the
public key from

1._domainkey.warwickri.gov

The signature failed validation. The Auth Result is fail.”



A failing signature should mean a header change.  That's also what
I get from
your posts on mailop, signature verification failed (otherwise
would 've been
body hash mismatch).  Can you turn on z= tags?  Otherwise try
carefully
comparing the signed fields, from: subject: to: date:, message-id:
and the
signature itself.

Check that no other filters alter those fields after signing.  Can
you sign
messages off-line?  Do Bcc: copies verify? (Use any off-line dkim
verifier.)


Good luck
Ale
--






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


___
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] Intuit directly spaming

[Mark Alley via mailop]

I'm not sure if they have an API, but I've used Hurricane Electric's BGP 
toolkit   to look up AS' frequently.


If you want API integration, BGPview 
 is 
quite useful.


On 3/4/2023 4:58 PM, MRob via mailop wrote:

On 2023-02-27 23:53, Atro Tossavainen via mailop wrote:

> harder to give due suspision on sendgrid because they give full


It's actually kind of easy.

Is the IP announced by AS11377?

Yes? -> SendGrid.


Thanks you Atro, is there popular tool for to do that in real time?
___
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] Google Postmaster Crash

[Mark Alley via mailop]

I've seen the same with my domains. Just spins on load.

On Sat, Mar 4, 2023, 3:35 PM Emre Üst via mailop  wrote:

> Hello ,
>
> Google Postmaster not working since Friday. After log in, it should list
> the domain list, but the loading screen returns and does not appear.
>
> Are you like that too? Or are we just experiencing this situation?
>
> Thank you
>
> --
> *Emre ÜST*
> Deliverability Team Leader
>
> *t.*   +90 212 343 07 39
> *f.*   +90 212 343 07 42
> *m.* +90 533 157 73 10
>
> *email: *emre@relateddigital.com <%23>
> *web:* relateddigital.com 
> Maslak Mah. Büyükdere Cd. No:249 Sarıyer - İstanbul
>
> 
> 
>  
>
> 
>
> Bu e-posta içeriği, mesajın alıcı kısmında belirtilmiş olan kişi/kurum
> içindir ve sadece gönderilen kişiye/kuruma yöneliktir. Mesajın gönderilmek
> istendiği kişi/kurum değilseniz, lütfen doğrudan veya dolaylı olarak mesajı
> kullanmayınız ve mesajın tüm kopyalarını sisteminizden derhal siliniz. Bu
> mesaj kişisel veri içerebilir, böyle bir durumda mesajın muhatabı
> değilseniz, ilgili mevzuat kapsamında kişisel veri içeren mesajı tüm
> sistemlerinizden derhal kaldırın. Related Digital, bu e-postada yer alan
> hatalardan veya eksikliklerden sorumlu değildir ve e-posta kullanımından
> kaynaklanan zararlardan sorumlu tutulamaz. Bu mesajda yer alan herhangi bir
> görüş ve beyan ya da herhangi bir ek yalnızca yazarına aittir ve Related
> Digital’i mutlak anlamda temsil etmemektedir.
>
>
> This e-mail content is solely for the individual/entity who has been
> mentioned specifically in the recipient section of the e- mail and intended
> solely for the addressee. If you are not the intended addressee, please do
> not use the message directly or indirectly and delete the message and all
> its copies immediately. This message may contain personal data, if you are
> not the recipient of the message remove the message immediately from all
> your systems under the relevant legislation within the scope of personal
> data. Related Digital is not responsible for errors or omissions in this
> message and cannot be held responsible for any damage arising from the use
> of e-mail. Any opinion and other statement contained in this message and
> any attachment are solely those of the author and do not necessarily
> represent Related Digital.
> ___
> 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] New member, trying to bring our mail server inline.

[Mark Alley via mailop]

The selector seems to just be "1", of which the published record appears 
to be valid in DNS.


https://tools.wordtothewise.com/dkim/check/warwickri.gov/1

DNS propagation  
shows the DKIM record is resolvable across the internet, so resolution 
isn't the problem, and it appears to be syntactically valid.


@Salvatore - if you send a test message to the address provided to you 
on https://learndmarc.com, it will show you authentication results of 
direct messages from your mail server which you can use to troubleshoot 
authentication further.


- Mark Alley


On 3/3/2023 10:27 AM, Laura Atkins via mailop wrote:
Based on the headers of the message you sent here (to mailop), you 
have yet to actually publish a public key in DNS.


https://tools.wordtothewise.com/dkim/check/warwickri/1677852725

laura

On 3 Mar 2023, at 14:12, Salvatore Jr Walter P via mailop 
 wrote:


We are in the final stages of migrating our exchange server from 2013 
to 2019.

I found out we had no SPF, DMARC, DKIM etc setup on our domains.
Trying to get us setup properly and have SPF and DMARC working, DKIM 
is another story.

Setup on the server, sent the key to our ISP for the DNS to be added.
Headers show the signature is being included.
DKIM-Signature: v=1; a=rsa-sha256; d=redacted.gov 
; s=1; c=relaxed/relaxed;

    t=1677851456; h=from:subject:to:date:message-id;(rest of key)
Also from the headers:
Authentication-Results:inbound.redacted.net  ;
  spf=pass smtp.mailfrom=redac...@redacted.gov  ;
  dkim=fail header.d=redacted.gov  ;
  dmarc=pass (policy=none; pct=100; status=pass);
  arc=none
Any suggestion where to go from here? We are having all emails 
blocked by AT, no idea why so trying to get all our ducks in a row 
and make sure we are doing everything the “right” way.

___
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] DKIM record IONOS

[Mark Alley via mailop]

On 2/17/2023 9:27 PM, H wrote:
> On February 16, 2023 8:57:49 PM EST, Mark Alley via mailop 
>  wrote:
>> As long as the organizational domain you want reports for is the same
>> as
>> you have published in the DMARC RUA/RUF "mailto" tags, then no, you do
>> not
>> need it to be able to receive said reports.
>> 
>> - Mark Alley
>> 
>> On Thu, Feb 16, 2023, 7:47 PM H  wrote:
>> 
>>> On February 16, 2023 6:37:42 PM EST, Mark Alley via mailop <
>>> mailop@mailop.org> wrote:
>>>> You only need to create that record if you are sending the
>>>> aggregate/failure reports for a particular domain that is different
>>>> from
>>>> the one the reports are actually on behalf of.
>>>> 
>>>> So for example, if you owned domain1.com and wanted to send RUA/RUF
>>>> reports
>>>> for domain1.com to a mailbox at domain2.com (assuming you own
>> domain2),
>>>> you
>>>> would need to create the TXT record in domain2 -
>>>> "domain1.com._report._
>>>> dmarc.domain2.com" IN TXT "v=DMARC1;"
>>>> 
>>>> If you're using an external third party for report analysis, usually
>>>> they
>>>> have a wildcard published in their DNS for this "_report._dmarc"
>>>> subdomain,
>>>> so you don't have to worry about it in that case.
>>>> 
>>>> 
>>>> - Mark Alley
>>>> 
>>>> 
>>>> On Thu, Feb 16, 2023, 4:14 PM H via mailop
>> wrote:
>>>>> On 02/11/2023 07:42 PM, H wrote:
>>>>> 
>>>>> On 02/11/2023 01:55 AM, Gellner, Oliver via mailop wrote:
>>>>> 
>>>>> 
>>>>> On 2023-02-11 02:51 H via mailop wrote:
>>>>> 
>>>>> 
>>>>> On 02/10/2023 10:13 AM, Gellner, Oliver via mailop wrote:
>>>>> 
>>>>> On 2023-02-10 04:08, H via mailop wrote:
>>>>> 
>>>>> I now did find that resource but it is written as general
>> information
>>>> and does not really tell how to get it going with IONOS if they run
>> the
>>>> email server...
>>>>> As far as I understood you not only use Ionos as your registrar,
>> but
>>>> also use their email server to send your email through. Ionos does
>> not
>>>> DKIM sign emails on behalf of its customers, at least they didn't do
>> so
>>>> in the past. So the answer is simple: You do not set up DKIM or
>> DMARC
>>>> at all, because you can't.
>>>>> The instructions given by Ionos are only valid if your email is
>> sent
>>>> and signed by some other server and you want to add the DKIM public
>> key
>>>> to your domain hosted at Ionos.
>>>>> --
>>>>> BR Oliver
>>>>> 
>>>>> Thank you, you are starting with the first issue, ie whether I can
>>>> even
>>>>> have a DKIM record given that the domain is hosted by Ionos as is
>> the
>>>> mail
>>>>> server. Upon my additional research I have come to the same
>>>> conclusion as
>>>>> you, ie not possible.
>>>>> 
>>>>> By the way, I stumbled across this posting on the net -
>>>>> 
>> https://serverfault.com/questions/1030262/record-dkim-on-ionos-makes-sense
>>>>> - that as far as I can tell is still true.
>>>>> 
>>>>> So, I will now look at creating a DMARC record given that I have
>>>>> previously created a SPF record and will not be able to have a
>> DKIM
>>>> record.
>>>>> I recommend against setting up a DMARC record with a policy of
>>>> quarantine
>>>>> or reject as long as DKIM signing isn‘t in place. The SPF
>>>> authentication
>>>>> will break for all forwarded messages as well as for all automatic
>>>> replies
>>>>> or non-delivery reports. It will do mire harm than good.
>>>>> Of course if you‘re interested in the reporting you can create a
>>>> DNARC
>>>>> record with a none policy and only change that after you have
>> moved
>>>> to a
>>>>> different email provider who supports DKIM.
>>>>> 
>>>>> —
>>>>> BR Oliver
>>>>> 
>>>>> --
>>>>> dmTECH G

Re: [mailop] DKIM record IONOS

[Mark Alley via mailop]

As long as the organizational domain you want reports for is the same as
you have published in the DMARC RUA/RUF "mailto" tags, then no, you do not
need it to be able to receive said reports.

- Mark Alley

On Thu, Feb 16, 2023, 7:47 PM H  wrote:

> On February 16, 2023 6:37:42 PM EST, Mark Alley via mailop <
> mailop@mailop.org> wrote:
> >You only need to create that record if you are sending the
> >aggregate/failure reports for a particular domain that is different
> >from
> >the one the reports are actually on behalf of.
> >
> >So for example, if you owned domain1.com and wanted to send RUA/RUF
> >reports
> >for domain1.com to a mailbox at domain2.com (assuming you own domain2),
> >you
> >would need to create the TXT record in domain2 -
> >"domain1.com._report._
> >dmarc.domain2.com" IN TXT "v=DMARC1;"
> >
> >If you're using an external third party for report analysis, usually
> >they
> >have a wildcard published in their DNS for this "_report._dmarc"
> >subdomain,
> >so you don't have to worry about it in that case.
> >
> >
> >- Mark Alley
> >
> >
> >On Thu, Feb 16, 2023, 4:14 PM H via mailop  wrote:
> >
> >> On 02/11/2023 07:42 PM, H wrote:
> >>
> >> On 02/11/2023 01:55 AM, Gellner, Oliver via mailop wrote:
> >>
> >>
> >> On 2023-02-11 02:51 H via mailop wrote:
> >>
> >> 
> >> On 02/10/2023 10:13 AM, Gellner, Oliver via mailop wrote:
> >>
> >> On 2023-02-10 04:08, H via mailop wrote:
> >>
> >> I now did find that resource but it is written as general information
> >and does not really tell how to get it going with IONOS if they run the
> >email server...
> >>
> >> As far as I understood you not only use Ionos as your registrar, but
> >also use their email server to send your email through. Ionos does not
> >DKIM sign emails on behalf of its customers, at least they didn't do so
> >in the past. So the answer is simple: You do not set up DKIM or DMARC
> >at all, because you can't.
> >> The instructions given by Ionos are only valid if your email is sent
> >and signed by some other server and you want to add the DKIM public key
> >to your domain hosted at Ionos.
> >>
> >> --
> >> BR Oliver
> >>
> >> Thank you, you are starting with the first issue, ie whether I can
> >even
> >> have a DKIM record given that the domain is hosted by Ionos as is the
> >mail
> >> server. Upon my additional research I have come to the same
> >conclusion as
> >> you, ie not possible.
> >>
> >> By the way, I stumbled across this posting on the net -
> >>
> >
> https://serverfault.com/questions/1030262/record-dkim-on-ionos-makes-sense
> >> - that as far as I can tell is still true.
> >>
> >> So, I will now look at creating a DMARC record given that I have
> >> previously created a SPF record and will not be able to have a DKIM
> >record.
> >>
> >> I recommend against setting up a DMARC record with a policy of
> >quarantine
> >> or reject as long as DKIM signing isn‘t in place. The SPF
> >authentication
> >> will break for all forwarded messages as well as for all automatic
> >replies
> >> or non-delivery reports. It will do mire harm than good.
> >> Of course if you‘re interested in the reporting you can create a
> >DNARC
> >> record with a none policy and only change that after you have moved
> >to a
> >> different email provider who supports DKIM.
> >>
> >> —
> >> 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,
> >

Re: [mailop] DKIM record IONOS

[Mark Alley via mailop]

You only need to create that record if you are sending the
aggregate/failure reports for a particular domain that is different from
the one the reports are actually on behalf of.

So for example, if you owned domain1.com and wanted to send RUA/RUF reports
for domain1.com to a mailbox at domain2.com (assuming you own domain2), you
would need to create the TXT record in domain2 -  "domain1.com._report._
dmarc.domain2.com" IN TXT "v=DMARC1;"

If you're using an external third party for report analysis, usually they
have a wildcard published in their DNS for this "_report._dmarc" subdomain,
so you don't have to worry about it in that case.


- Mark Alley


On Thu, Feb 16, 2023, 4:14 PM H via mailop  wrote:

> On 02/11/2023 07:42 PM, H wrote:
>
> On 02/11/2023 01:55 AM, Gellner, Oliver via mailop wrote:
>
>
> On 2023-02-11 02:51 H via mailop wrote:
>
> 
> On 02/10/2023 10:13 AM, Gellner, Oliver via mailop wrote:
>
> On 2023-02-10 04:08, H via mailop wrote:
>
> I now did find that resource but it is written as general information and 
> does not really tell how to get it going with IONOS if they run the email 
> server...
>
> As far as I understood you not only use Ionos as your registrar, but also use 
> their email server to send your email through. Ionos does not DKIM sign 
> emails on behalf of its customers, at least they didn't do so in the past. So 
> the answer is simple: You do not set up DKIM or DMARC at all, because you 
> can't.
> The instructions given by Ionos are only valid if your email is sent and 
> signed by some other server and you want to add the DKIM public key to your 
> domain hosted at Ionos.
>
> --
> BR Oliver
>
> Thank you, you are starting with the first issue, ie whether I can even
> have a DKIM record given that the domain is hosted by Ionos as is the mail
> server. Upon my additional research I have come to the same conclusion as
> you, ie not possible.
>
> By the way, I stumbled across this posting on the net -
> https://serverfault.com/questions/1030262/record-dkim-on-ionos-makes-sense
> - that as far as I can tell is still true.
>
> So, I will now look at creating a DMARC record given that I have
> previously created a SPF record and will not be able to have a DKIM record.
>
> I recommend against setting up a DMARC record with a policy of quarantine
> or reject as long as DKIM signing isn‘t in place. The SPF authentication
> will break for all forwarded messages as well as for all automatic replies
> or non-delivery reports. It will do mire harm than good.
> Of course if you‘re interested in the reporting you can create a DNARC
> record with a none policy and only change that after you have moved to a
> different email provider who supports DKIM.
>
> —
> 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 listmailop@mailop.orghttps://list.mailop.org/listinfo/mailop
>
> I see. As I am sure everyone has noticed, I am a complete newbie to
> SPF/DKIM/DMARC (and a lot of other things.)
>
> Understanding your message, creating a DMARC with "none" policy would not
> have any downside? When you say "reporting", what type of reporting would
> that be and how could I benefit from such reporting?
>
> I have created a DMARC record and checked that it is correctly set up on a
> DMARC check site. I understand that in order to receive these reports I
> also need to create a EDV record among my domain DNS settings?
>
> Googling around I have not found any clear instructions on how to do so?
>
> At this time my understanding is that I need to create another TXT record
> where the host field would contain "mydomain.com._report._
> dmarc.mydomain.com" and the value field would contain "v=DMARC1".
> Mydomain above would of course be replaced with the actual domain name.
>
> Thanks.
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org

Re: [mailop] DKIM record IONOS

[Mark Alley via mailop]

In consumer applications, DKIM is usually signed on behalf of the 
sending domain it has been configured for (if at all).


If you own domain1.com on IONOS and set up DKIM signing for it, 
domain1.com email from that mail system will be signed. If you own 
domain2.com on IONOS and have not set up signing up for it, it will not 
be signed for domain2.com unless you explicitly set it up the same way 
you have for domain1.com.



On 2/9/2023 9:03 PM, H via mailop wrote:

On February 9, 2023 9:03:26 PM EST, Eric Tykwinski  
wrote:

I think you are confused about the key signing, the mail server sending
the email is generating the keys.  They are the ones signing the
emails.  So if you send emails through Ionos -> receiving MTA, they
should be the one signing the emails.  This allows them to create the
keys.  If you are smarthosting emails, ie Ionos -> your MTA ->
receiving MTA then you would sign the emails.

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300


On Feb 9, 2023, at 8:53 PM, H via mailop  wrote:

On 02/09/2023 07:51 PM, Al Iverson wrote:

The DKIM public key is technically a TXT record.
Some people do use a CNAME version, but then yeah, you put in the

hostname of the real server (real DNS entry) that has the TXT entry.

So in your case, you’re probably looking to paste that key value

into the TXT record.

Your selector is “k1” in this example. That sounds right based on

Googling the iONOS instructions, I think.

Cheers,
Al Iverson



On Feb 9, 2023, at 6:41 PM, H via mailop  wrote:

Having successfully created a SPF record for my domain hosted by

Ionos, I now wanted to create a DKIM record but have received two
completely different answers from Ionos.

The first instruction I received was to create a CNAME record,

enter k1._domainkey in the Host field, and then a key the Value field.
Well, there is no Value field, only a Points To field and that seems to
accept another domain name, not a key.

I then called the helpline and was told to create a TXT record,

keep the Host Name field unchanged from the default suggested by Ionos
and then enter the public DKIM key in the Value field. IOW, no
particular selector to be entered. Upon inquiring how to use the
private DKIM key they told me I do not need it for anything...

By the way, I used easyDmarc.com to create the public/private key

pair.

Clearly at most one of the above can be correct - or possibly none

of the two...

If anyone could set me straight, it would be greatly appreciated.

Thanks.

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

I think the selector, if I understood this correctly, is actually

_domainkey.

Where did you find the Ionos instructions? I have only found

third-party instructions which I do not consider to be authoritative.
As I wrote, the instructions I received from them were also different
suggesting confusion (beyond my own).

And when/how do I use the private key?


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



Bringing this back to the list again instead of private email. I sent an email 
from another domain they host for me and checked that particular email upon 
arrival to another of email address I have. No DKIM signature so they do not 
default to DKIM signing. One wonders why not?
___
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] Question of SPF record

[Mark Alley via mailop]

Per their instructions here:
https://www.ionos.com/help/domains/configuring-mail-servers-and-other-related-records/using-an-spf-record-to-prevent-spam/

Just add these to your SPF record like so.

v=spf1 a mx include:_spf.perfora.net include:_spf.kundenserver.de ~all

You probably don't need the MX mechanism given they publish a different
subnet in SPF for their sending MTAs, but feel free to verify by testing if
you remove it.

To your original question about IP addresses, the ip4 mechanism allows for
singular IP addresses as well as CIDR format to add subnets. (i.e. ip4:
74.208.4.192/26) But you don't need to do this, as this subnet is covered
by the SPF record includes above provided by IONOS.

Thanks,

Mark Alley

On Sun, Feb 5, 2023, 6:44 PM H via mailop  wrote:

> I have a domain with multiple email addresses hosted by Ionos. I have
> found that outgoing emails can come from a range of Ionos email IPs.
>
> I have created a TXT record for my domain containing one IP4 address but
> outgoing emails seem to be sent from different IP4 addresses. As an example
> I now have:
>
> v=spf1 a mx ip4:74.208.4.194 ~all
>
> I know I can add at least one more ip4 address using the same format but I
> am not sure exactly what the Ionos email ip range might be so:
>
> - Is there a way of saying eg. ip4:72.20.8.*
>
> - Or should I delete the ip4 component and instead add:
>
> include:mydomain.tld (corrected of course)
>
> Suggestions appreciated!
>
> Thanks.
>
> ___
> 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] gmail putting most messages into Spam

[Mark Alley via mailop]

Fair point. I've seen that with the .tk free TLD as well, same boat. 
Generally, nobody I've seen using that TLD has a good time related to email.


On 1/18/2023 4:00 PM, John Levine via mailop wrote:

It appears that Jaroslaw Rafa via mailop  said:

Dnia 18.01.2023 o godz. 07:39:48 Mark Alley via mailop pisze:

Woops, sorry, wrong link pasted. That's the sender guidelines -
while still helpful, was not what I was trying to send.

The eu.org domain gives out free subdomains to anyone, including a lot
of spammers. As we've repeatedly pointed out, sometimes free services
are only worth what you pay for them.

R's,
John
___
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] gmail putting most messages into Spam

[Mark Alley via mailop]

We're glad to help, and that you got it working!

If it's the warning I am recalling, I believe the validators are just 
complaining about the void lookup in one of the nested "a" mechanisms, 
that won't cause an issue unless there are more than 2 total. You can 
probably fix that issue yourself if you control the DNS for that record.


- Mark Alley

On 1/18/2023 3:25 PM, John Covici wrote:

I just wanted to thank the folks on here -- although the syntax
checkers say there is an error in my spf record(s) I was able to send
a message to a gmail address and that has solved my problem.

Thanks again.


Thanks again.

On Wed, 18 Jan 2023 05:50:51 -0500,
Mark Alley via mailop wrote:

[1  ]
[1.1  ]
One other thing - it also appears the SPF syntax for
"ccs.covici.com" is currently an issue. You'll want to address
this so it can be parsed by mail servers correctly.

Here's what I'm assuming it was intended to look like -

/v=spf1 a include:covici-com.spf-a.smtp25.com
include:covici-com.spf-b.smtp25.com
include:covici-com.spf-c.smtp25.com a:ccs.covici.com
a:debian-2.covici.com -all/

Based on the A records used previously in the email thread, I'm
presuming it was meant to reference "ccs.covici.com" and
"debian-2.covici.com" as /"a" /mechanisms rather than
"include". You may also want to address/remove the null "/a/"
mechanism reference to "a:zixworks.com" in this RR
"covici-com.spf-c.smtp25.com".



On 1/18/2023 4:33 AM, Mark Alley wrote:

//X-Spam-Last-External-HELO: covici.com/ * 0.3 KHOP_HELO_FCRDNS
Relay HELO differs from its IP's reverse DNS * I don't
understand this one, I have rdns pointers on ccs.covici.com and
debian-2.covici.com .///

   * "debian-2.covici.com" and "ccs.covici.com" may be the FQDN of the
 mail server(s), but the HELO presented (covici.com) does not match
 the server IP rDNS as reflected above. The HELO of each server
 would need to be match its IP's rDNS FQDN (i.e.
 "debian-2.covici.com" and "ccs.covici.com" respectively) to pass
 this check.
   * You will also want to publish an SPF record for these HELO
 identities once it matches, probably something like -/v=spf1 a ~all
 /I see you already have one for ccs.covici.com, but there is not
 one currently for "debian-2.covici.com".


- Mark Alley


On 1/18/2023 4:08 AM, John Covici via mailop wrote:

Thanks, it was my bad.  I did put an spf record, a couple of hours
ago, but mail-tester said it had not propagated.

I am going to paste my test results, because I have still some
questions.

Comments in line


Good stuff. Your email is almost perfect
Score :
7.7/10
   Subject : test #4Received 0 minutes ago
Click here to view your message
  From : John Covici
Bounce address :cov...@ccs.covici.com
Reply-To :cov...@ccs.covici.com
   Text version
hello.


[1.2  ]
[1.2.1  ]
[1.2.2 DL4BwTVAgVz9PGM0.png ]
[1.2.3 bAUUQBf9Ix4iOBZ2.png ]
[2  ]
___
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] gmail putting most messages into Spam

[Mark Alley via mailop]

That might be your email client rendering my original message 
differently - there shouldn't be any delimiter necessary in your SPF 
record at the beginning/end, you can remove them.


On 1/18/2023 10:44 AM, John Covici via mailop wrote:

So, what can I use to begin and end the record?  Do I need any
delimiter character like Mark gave me?

Thanks.

On Wed, 18 Jan 2023 10:59:21 -0500,
Giovanni Bechis via mailop wrote:

[1  ]
[1.1  ]
[1.1.1  ]
On 1/18/23 16:34, John Covici via mailop wrote:

Thanks for that -- for some reason, an spf lookup site which I have
used says no spf record, are you seeing for covici.com or
ccs.covici.com ?


covici.com and ccs.covici.com spf record are still invalid:

covici.com descriptive text "/v=spf1 a include:covici-com.spf-a.smtp25.com 
include:covici-com.spf-b.smtp25.com include:covici-com.spf-c.smtp25.com a:ccs.covici.com 
a:debian-2.covici.com -all/"

ccs.covici.com descriptive text "/v=spf1 a include:covici-com.spf-a.smtp25.com 
include:covici-com.spf-b.smtp25.com include:covici-com.spf-c.smtp25.com a:ccs.covici.com 
a:debian-2.covici.com -all/"

spf records should not start nor end with "/".

  Giovanni





On Wed, 18 Jan 2023 09:55:05 -0500,
Bill Cole via mailop wrote:

On 2023-01-18 at 05:08:00 UTC-0500 (Wed, 18 Jan 2023 05:08:00 -0500)
John Covici via mailop 
is rumored to have said:

[...]

   Source
Received: by mail-tester.com (Postfix, from userid 500)
id 567CCA0BC0; Wed, 18 Jan 2023 09:59:14 +0100 (CET)
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
mail-tester.com
X-Spam-Level:
X-Spam-Status: No/0.3/5.0
X-Spam-Test-Scores:
KHOP_HELO_FCRDNS=0.32,SPF_HELO_NONE=0.001,SPF_NONE=0.001,
URIBL_BLOCKED=0.001
X-Spam-Last-External-IP: 166.84.7.93
X-Spam-Last-External-HELO: covici.com
X-Spam-Last-External-rDNS: debian-2.covici.com
X-Spam-Date-of-Scan: Wed, 18 Jan 2023 09:59:14 +0100
X-Spam-Report:
*  0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was
*  blocked.  See
*  http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
*  for more information.
*  [URIs: covici.com]
*  0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
*  0.0 SPF_NONE SPF: sender does not publish an SPF Record
*  0.3 KHOP_HELO_FCRDNS Relay HELO differs from its IP's reverse DNS
* I don't understand this one, I have rdns pointers on
   ccs.covici.com and debian-2.covici.com .

Those are the names of rules in the SpamAssassin filter that
mail-tester.com unfortunately purports to demonstrate. They are
using an obsolete version of SA with (apparently) local rule
adjustments and they have chronically m isreported the sign of SA
scores, confusing users. As someone who fields SpamAssassin bug
reports, I despise them.

KHOP_HELO_FCRDNS means that one of the trustworthy set of
Received headers shows a handoff from a machine that identified
itself (in the EHLO or HELO step of the transaction) with a name
that did not match the name that the connecting IP's PTR record
points to, which does resolve back to the connecting IP. This is
a minor issue, and while it is more common in spam, the
correlation is weak enough  to earn a fairly low score for that
rule. In the current full SA ruleset it is scored at 0.001:
basically meaningless.

[...]

OK, even without dkim and marc, why is gmail rejecting?

Only GMail can tell you for sure, if even they can.

Give it some time with your fixed SPF. That *may* be adequate,
but Google changes can take time.


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


[1.2 OpenPGP digital signature ]
No public key for FABEEA09897258E5 created at 2023-01-18T10:59:21-0500 using RSA
[2  ]
___
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] gmail putting most messages into Spam

[Mark Alley via mailop]

Ah ok, apologies, I missed that in the chain. I knew someone had 
mentioned it before in this or another thread, but couldn't find it.


On 1/18/2023 7:43 AM, Jaroslaw Rafa via mailop wrote:

Dnia 18.01.2023 o godz. 07:38:32 Mark Alley via mailop pisze:

Have you tried submitting via the Google Sender Contact Form
<https://support.google.com/mail/answer/81126> to get this resolved?

Countless number of times, as I already wrote in my previous email.

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

Re: [mailop] gmail putting most messages into Spam

[Mark Alley via mailop]

Woops, sorry, wrong link pasted. That's the sender guidelines - while 
still helpful, was not what I was trying to send.


https://support.google.com/mail/contact/gmail_bulk_sender_escalation

On 1/18/2023 7:38 AM, Mark Alley wrote:


Have you tried submitting via the Google Sender Contact Form 
 to get this resolved?


On 1/18/2023 5:02 AM, Jaroslaw Rafa via mailop wrote:

Dnia 17.01.2023 o godz. 20:05:45 Jarland Donnell via mailop pisze:

You visit mail-tester.com, copy the email address, send an email to
it, and then wait about 15-30 seconds and click the button. It'll
give you an overview. It's not perfect, but if your email has some
very significant, avoidable problems it's an easy way to identify a
few common ones.

It's a very interesting service, thank you for the info. However, I must say
that even having 10/10 and all green on this service (as I have) means
nothing with regard to deliverability to Google - my messages are still put
to Spam folder as they have been. Even after manually marking the message as
non-spam by recipient, the next message goes to spam again.

Seems like the only way to have my messages delivered normally to Inbox is
to tell the Gmail recipient to create a filter on my sender address with the
action "never send to spam". Which is pretty idiotic, because a) an average
Gmail user is a person who can't do this (if he/she could, he/she would
probably choose a better mail service than Gmail); b) even if the recipient
can do this, how am I supposed to tell this to a person for whom I have
only email contact?___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] gmail putting most messages into Spam

[Mark Alley via mailop]

Have you tried submitting via the Google Sender Contact Form 
 to get this resolved?


On 1/18/2023 5:02 AM, Jaroslaw Rafa via mailop wrote:

Dnia 17.01.2023 o godz. 20:05:45 Jarland Donnell via mailop pisze:

You visit mail-tester.com, copy the email address, send an email to
it, and then wait about 15-30 seconds and click the button. It'll
give you an overview. It's not perfect, but if your email has some
very significant, avoidable problems it's an easy way to identify a
few common ones.

It's a very interesting service, thank you for the info. However, I must say
that even having 10/10 and all green on this service (as I have) means
nothing with regard to deliverability to Google - my messages are still put
to Spam folder as they have been. Even after manually marking the message as
non-spam by recipient, the next message goes to spam again.

Seems like the only way to have my messages delivered normally to Inbox is
to tell the Gmail recipient to create a filter on my sender address with the
action "never send to spam". Which is pretty idiotic, because a) an average
Gmail user is a person who can't do this (if he/she could, he/she would
probably choose a better mail service than Gmail); b) even if the recipient
can do this, how am I supposed to tell this to a person for whom I have
only email contact?___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] gmail putting most messages into Spam

[Mark Alley via mailop]

The HELO identity is set by the submitting mail server during the SMTP 
session, you'll need to update that accordingly in each respective mail 
server's configuration (or whichever software is being used).


On 1/18/2023 4:48 AM, John Covici wrote:

Thanks, that was useful.

I wonder why it was hello covici.com since I am not sending from that
address?

On Wed, 18 Jan 2023 05:33:32 -0500,
Mark Alley via mailop wrote:

[1  ]
[1.1  ]
//X-Spam-Last-External-HELO: covici.com/ * 0.3 KHOP_HELO_FCRDNS
Relay HELO differs from its IP's reverse DNS * I don't
understand this one, I have rdns pointers on ccs.covici.com and
debian-2.covici.com ./

  * "debian-2.covici.com" and "ccs.covici.com" may be the FQDN of the
mail server(s), but the HELO presented (covici.com) does not match
the server IP rDNS as reflected above. The HELO of each server would
need to be match its IP's rDNS FQDN (i.e. "debian-2.covici.com" and
"ccs.covici.com" respectively) to pass this check.
  * You will also want to publish an SPF record for these HELO
identities once it matches, probably something like -/v=spf1 a ~all
/I see you already have one for ccs.covici.com, but there is not one
currently for "debian-2.covici.com".


- Mark Alley


On 1/18/2023 4:08 AM, John Covici via mailop wrote:

Thanks, it was my bad.  I did put an spf record, a couple of hours
ago, but mail-tester said it had not propagated.

I am going to paste my test results, because I have still some
questions.

Comments in line


Good stuff. Your email is almost perfect
Score :
7.7/10
   Subject : test #4Received 0 minutes ago
Click here to view your message
  From : John Covici
Bounce address :cov...@ccs.covici.com
Reply-To :cov...@ccs.covici.com
   Text version
hello.


[1.2  ]
[2  ]
___
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] gmail putting most messages into Spam

[Mark Alley via mailop]

Sorry - categories*, not labels.

On 1/17/2023 9:43 AM, Mark Alley wrote:


The labels in Gmail/workspace aren't the same as spam, they are part 
of the Inbox. If you have the user turn off labels, you will see them 
still in the inbox as expected.


On 1/17/2023 9:32 AM, Robert Schoneman via mailop wrote:


Our outbound email from O365 through PPE to Gmail and Google 
Workspace is going to Spam. “Show Original” indicates pass on all of 
SPF, DKIM, DMARC. Emails that are nothing but text are going to Spam 
along with emails containing links and/or attachments. We got the 
first user ticket about this issue on Sunday evening when trying to 
communicate with a partner who uses Google Workspace.


We’ve also seen emails from our contact center system and ticketing 
system which previously went to user’s Gmail Inboxes now going to 
“Updates”. Contact center and ticketing system do not go through PPE 
or O365.


Something has definitely changed on Google’s side.

*From:* mailop  *On Behalf Of *Gellner, 
Oliver via mailop

*Sent:* Tuesday, January 17, 2023 10:15 AM
*To:* mailop@mailop.org
*Subject:* Re: [mailop] gmail putting most messages into Spam

On 2023-01-17 14:41, Paul Gregg via mailop wrote:

> We are aware of a recent change in behaviour of gmail.com where 
most email is placed directly into Spam folder.


> So far we have dozens of customers reporting this.

> Tested myself with full SPF, DKIM and DMARC with p=reject - which 
gmail itself marks as passing all tests. The mail was also delivered 
over TLS.


> Mails go to Spam.

I cannot confirm this issue, so it may be specific to certain IP 
addresses or domains, as in Jaroslaw Rafas case, where it's likely 
connected to the reputation of the used domain.


Either way, SPF, DKIM and DMARC authenticate a message, they do not 
say whether it's spam or not.


--

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 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] gmail putting most messages into Spam

[Mark Alley via mailop]

The labels in Gmail/workspace aren't the same as spam, they are part of 
the Inbox. If you have the user turn off labels, you will see them still 
in the inbox as expected.


On 1/17/2023 9:32 AM, Robert Schoneman via mailop wrote:


Our outbound email from O365 through PPE to Gmail and Google Workspace 
is going to Spam. “Show Original” indicates pass on all of SPF, DKIM, 
DMARC. Emails that are nothing but text are going to Spam along with 
emails containing links and/or attachments. We got the first user 
ticket about this issue on Sunday evening when trying to communicate 
with a partner who uses Google Workspace.


We’ve also seen emails from our contact center system and ticketing 
system which previously went to user’s Gmail Inboxes now going to 
“Updates”. Contact center and ticketing system do not go through PPE 
or O365.


Something has definitely changed on Google’s side.

*From:* mailop  *On Behalf Of *Gellner, 
Oliver via mailop

*Sent:* Tuesday, January 17, 2023 10:15 AM
*To:* mailop@mailop.org
*Subject:* Re: [mailop] gmail putting most messages into Spam

On 2023-01-17 14:41, Paul Gregg via mailop wrote:

> We are aware of a recent change in behaviour of gmail.com where most 
email is placed directly into Spam folder.


> So far we have dozens of customers reporting this.

> Tested myself with full SPF, DKIM and DMARC with p=reject - which 
gmail itself marks as passing all tests. The mail was also delivered 
over TLS.


> Mails go to Spam.

I cannot confirm this issue, so it may be specific to certain IP 
addresses or domains, as in Jaroslaw Rafas case, where it's likely 
connected to the reputation of the used domain.


Either way, SPF, DKIM and DMARC authenticate a message, they do not 
say whether it's spam or not.


--

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 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] gmail putting most messages into Spam

[Mark Alley via mailop]

Ah, that is interesting. I checked with a few client PoD clusters I have 
access to and haven't noticed any spam filtering issues at the moment 
with consumer gmail accounts or workspace tenants.



On 1/17/2023 9:05 AM, Paul Gregg wrote:

On Tue, Jan 17, 2023 at 08:28:54AM -0600, Mark Alley via mailop wrote:

Just to clarify - Do you mean from Proofpoint enterprise (PoD) customers or
Proofpoint essentials? I could definitely see essentials having this problem
as their IP space is shared amongst customers, but PoD clusters each
individually have their own IPs that are separate from any other customer.

On 1/17/2023 8:15 AM, Jeff via mailop wrote:

We too have been seeing this in the last 48 hours

Only from clients sending out from Proofpoint though and Google is
marking them as Spam for the reason "Blatant Spam"... when they are
clearly not

We have tickets open with all relevant providers (Proofpoint and Google)
to see if we can figure this out

In my case, Proofpoint Essentials*. Tho a post in r/msp about this same
issue last night also suggests folks are seeing it from PoD and even
when they removed Proofpoint from the path and sent O365->Gmail
directly.

Disclosure: * I'm the Eng Manager responsible for the Essentials
Platform.


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

Re: [mailop] gmail putting most messages into Spam

[Mark Alley via mailop]

Just to clarify - Do you mean from Proofpoint enterprise (PoD) customers 
or Proofpoint essentials? I could definitely see essentials having this 
problem as their IP space is shared amongst customers, but PoD clusters 
each individually have their own IPs that are separate from any other 
customer.


On 1/17/2023 8:15 AM, Jeff via mailop wrote:

We too have been seeing this in the last 48 hours

Only from clients sending out from Proofpoint though and Google is 
marking them as Spam for the reason "Blatant Spam"... when they are 
clearly not


We have tickets open with all relevant providers (Proofpoint and 
Google) to see if we can figure this out


On Tue, Jan 17, 2023 at 9:10 AM Jaroslaw Rafa via mailop 
 wrote:


Dnia 17.01.2023 o godz. 13:16:03 Paul Gregg via mailop pisze:
> Heads up in case anyone else is experiencing this.
>
> We are aware of a recent change in behaviour of gmail.com
 where
> most email is placed directly into Spam folder.
>
> So far we have dozens of customers reporting this.
> Tested myself with full SPF, DKIM and DMARC with p=reject -
which gmail
> itself marks as passing all tests. The mail was also delivered
over TLS.
> Mails go to Spam.
>
> We're trying to reach out to google, but so far have no response.
>
> We don't think it is just 'us', as reddit r/msp has others reporting
> same from O365 direct to gmail.

Welcome to the club :(

I'm experiencing this for over 2 years. Have written about this on
this very
list a few times. Google just suddenly stopped to "like" my
domain. I had
no SPF, DKIM nor DMARC at that time (despite this I didn't have any
deliverability problem, including Google). After Google changed
something
and started to spam-mark my mail I implemented SPF/DKIM/DMARC
(outgoing
only, I don't want to bother with checking this crap on incoming
mail).
Everything passes at Google, but it doesn't help.

However, when I send from exactly the same server, using exactly
the same
mail client, only with diferent sender domain, the mails go
through. So I
know it's the domain Google doesn't like.

Nothing helps - even when the recipient at Gmail flags my mail as
non-spam,
it can happen that next messages from me still go to spam. Even
when I REPLY
(!) to a mail I got from a Gmail user, my reply goes to spam, which is
completely illogical. It should be obvious for Google to detect
that this is
a reply to a message that was previously sent from Gmail.

I have filled in the "sender troubleshooting form" on Google website
multiple times (you need to provide headers from receiving side of
the mail
that was misclassified as spam, so I made myself a test account at
Gmail
that I am sending messages to) - however they state in advance
that they
won't contact you and inform you whether they did anything or not
to your
complaint. Looks like they didn't do anything. I managed to reach
Brandon
from Google via this very list, but he said that it just works so
and from
their point of view they don't see any reason to change anything.
I just
happen to have a domain whose parent domain has a "poor
reputation" and I
have to accept it.

I even made a blog post about it some time ago, but it's in my
language (ie.
Polish). After that post I was contacted by some other people who are
unlucky to be in the same situation.

Shame on you Google.
-- 
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


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


OpenPGP_0xE37A23C4D04F0409.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Valid SPF/DKIM/DMARC *SPAM* coming from my domain ?!

[Mark Alley via mailop]

Looking at it again, I agree with Todd and Jarland's hypothesis; 
Forwarding sounds more plausible than an API submission via compromised 
credentials in this case. I think that hit the nail on the head. This 
also correlates to one of Mailgun's product offerings 
 
for forwarding which fits the bill.


On 1/11/2023 3:29 PM, Todd Herr via mailop wrote:
This looks like a message that maybe might've been sent to a 
reflectiv.net  address (perhaps the one 
advertised on your website? contact at reflectiv.net 
?) and then automatically forwarded by Mailgun 
(which hosts inbound mail for reflectiv.net ) to 
a Google account (since Mailgun probably doesn't do mailbox hosting).


That's just purely a guess, based on

1.
X-Mailgun-Incoming: Yes

appearing in the headers, and the MX record for reflectiv.net 
, and the message coming to Google with the 
following Return-Path:


1.
Return-Path: 

Does that sound plausible?

On Wed, Jan 11, 2023 at 4:07 PM Cyril - ImprovMX via mailop 
 wrote:


Hi everyone!

Today, I received a spam ("I got full access to your computer and
installed a trojan" kind of email). In general, I completely
ignore these, but today was different:

The sender and recipient were my own email! What's odd is that I
did configure SPF (granted, with a "~") but also a DMARC reject
policy.

Looking at the email headers and also the output from GMail, both
SPF and DKIM were successful ("pass"), which means the sender,
somehow, was able to send an email using my account.

I would love your input on the issue, but here are my thoughts so far:

1. My account was compromised, and the password was leaked,
allowing that user to send an email with my account. This would
make sense, but the sending account was only used to be configured
within GMail. As soon as the password was generated, I pasted it
on GMail and never saved it elsewhere.
2. Theoretically, if I were to create an account on Mailgun, I
would be able to send an email from my account and have a valid
SPF for any other services that use Mailgun too (since their SPF
would include Mailgun's IPs), but it wouldn't explain the valid
DKIM though. For this, Mailgun should only allow my account to be
able to send using my domain.
3. Did Mailgun have any database leak that I wasn't aware of?

Of course, as soon as I saw this email, I generated a new password
for my account, but I still wonder how this could have happened. I
would appreciate if you had any insights I've missed that would
make sense.

Here are the headers from the email with my end email redacted:
https://pastebin.com/knqbTa8K

Thank you!
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop



--
*Todd Herr *| Technical Director, Standards and Ecosystem
*e:*todd.h...@valimail.com
*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


OpenPGP_0xE37A23C4D04F0409.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Valid SPF/DKIM/DMARC *SPAM* coming from my domain ?!

[Mark Alley via mailop]

Do you have an API ID and key/password for Mailgun somewhere that was 
compromised? Was it saved somewhere like a password manager (think 
Lastpass)? This looks as if the host submitted it directly to Mailgun, 
hence it passed all email authentication.


On 1/11/2023 3:00 PM, Cyril - ImprovMX via mailop wrote:

Hi everyone!

Today, I received a spam ("I got full access to your computer and 
installed a trojan" kind of email). In general, I completely ignore 
these, but today was different:


The sender and recipient were my own email! What's odd is that I did 
configure SPF (granted, with a "~") but also a DMARC reject policy.


Looking at the email headers and also the output from GMail, both SPF 
and DKIM were successful ("pass"), which means the sender, somehow, 
was able to send an email using my account.


I would love your input on the issue, but here are my thoughts so far:

1. My account was compromised, and the password was leaked, allowing 
that user to send an email with my account. This would make sense, but 
the sending account was only used to be configured within GMail. As 
soon as the password was generated, I pasted it on GMail and never 
saved it elsewhere.
2. Theoretically, if I were to create an account on Mailgun, I would 
be able to send an email from my account and have a valid SPF for any 
other services that use Mailgun too (since their SPF would include 
Mailgun's IPs), but it wouldn't explain the valid DKIM though. For 
this, Mailgun should only allow my account to be able to send using my 
domain.

3. Did Mailgun have any database leak that I wasn't aware of?

Of course, as soon as I saw this email, I generated a new password for 
my account, but I still wonder how this could have happened. I would 
appreciate if you had any insights I've missed that would make sense.


Here are the headers from the email with my end email redacted:
https://pastebin.com/knqbTa8K

Thank you!

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


OpenPGP_0xE37A23C4D04F0409.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Intentionally vague SPF records.

[Mark Alley via mailop]

+1 to Laura's statement about Macros - and just wanted to add there is 
also an open source solution that allows for self-hosted SPF macros on 
github as well.


https://github.com/smck83/expurgate


On 1/11/2023 9:00 AM, Laura Atkins via mailop wrote:



On 11 Jan 2023, at 13:08, Simon Burke via mailop  
wrote:


All,

This is an odd scenario, but sadly one I find myself in.

Work is a large organisation, and currently does not have an SPF 
record. The reason is that there are a large (and unknown) number of 
internal and external parties that send mail on our domain, as well 
as sub-domains.


Most bulk services use either a custom subdomain in the customer’s 
domain space for the 5321.from or their own string in the 5321.from. 
This is primarily to deal with bounces - as anything that fails to 
deliver should go back to the sending service not to the original 
sender. A lot of places (SES, Mailchimp, Constant Contact) use their 
own 5321.from addresses by default and there’s no need to add the 
include: record at all. If your user base is using custom 5321.from 
you’re going to need to set up DNS records for those (CNAMEs are common).


Do you have a lot of users with 1 to 1 email through external relays?

So, even if we do determine who sends email on the domain, we would 
then have an issue with max lookups and record length.


I find, generally, this happens but in most cases it doesn’t have to. 
Despite what a lot of people think, they don’t need to add an include 
for every service they’re using in the spf record for their 
organizational domain.


I know we can use an SPF flattening service. However that either has 
a cost. Or, although we can develop something in house, there's a 
'bought not built' ethos being pushed by management.


Sparkpost uses macros, would that be possible?

As an out the box idea, what would the potential impact be of having 
an SPF record stating just:


"V=spf1 a mx +all"

How bad of an idea would this be? If we also had a DMARC record set 
to either quarantine or reject.


Anecdotally, that would be a bad idea. What I’ve heard is this is 
actually something done for botnet sending and is treated as a bad 
reputation indicator. I don’t ever recommend this.


laura

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


OpenPGP_0xE37A23C4D04F0409.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Intentionally vague SPF records.

[Mark Alley via mailop]

Of those vendors you listed, Mailchimp doesn't send SPF aligned mail in 
the RFC5321.mailfrom (return-path), and Sendgrid custom domain 
authentication uses subdomain CNAMEs by default for the same, so you can 
count those off your list of ones you need to worry about on your 
organizational domain.


For Azure, I'm assuming this is supposed to be server(s) you have hosted 
in the Azure cloud that sends mail directly out? This could just be an 
ip4 mechanism reference in your SPF record, which avoids a DNS lookup.


Right now, with just this lineup (excluding Verint as I couldn't find 
any documentation on them) we're at 5 lookups with this example SPF 
record below. Depending on which of these services are customer-mailing, 
or if they're only sending to your own users, you can make the decision 
to convert some of them to using a sub-domain to alleviate your root 
record lookups.


v=spf1 ip4: include:spf.protection.outlook.com 
include:amazonses.com include:spf.mailjet.com 
include:eu.rp.oracleemaildelivery.com ?all


All of this being said, keep in mind, it's not necessary to have SPF 
authenticate for everything you send. DMARC will still pass as long as 
the sending infrastructure signs with an aligned and valid DKIM 
signature on the emails. Authenticate what you can with SPF - the 
critical business services, and rely on DKIM alone for the rest if 
necessary. Plenty of big senders today use this philosophy with nary an 
issue, just look at Mailchimp.


This is also partly why it's considered a deliverability best practice 
to use ~all (softfail) on your sending domains (M3AAWG best practices 
<https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf> 
section 4). This practice is widely used for sending domains that have 
an enforced DMARC policy to avoid issues with SPF failure where some 
MTAs are configured to reject -all before processing DMARC policy and 
DKIM. (DMARC RFC7489 10.1 
<https://datatracker.ietf.org/doc/html/rfc7489#section-10.1>)



- Mark Alley

On 1/11/2023 7:52 AM, Simon Burke via mailop wrote:


What makes you think you'd go over the limit if you haven't done
the discovery?

This would be because the ones that we are aware of, are the likes of 
AmazonSES, Sendgrid, Mailchimp, Azure, OracleCloud, Mailjet, 
KANA/Verint, just to name a few on top of our O365 instance and 
locally transported mail.


We know the major ones, but it's all the little ones that one 
department somewhere setup without contacting central IT. This happens 
a lot due to internal politics (it's a UK University, where there's no 
obligation for colleges to use IT services).


Theres a lot of internal politics involved, but the thought popped 
into our heads, to use a intentionally vague record as a fudge until 
we are able to determine what it should look like. Or push external 
things onto sub-domains so we can have a simple SPF for the primary 
domain.


Thanks.


On Wed, 11 Jan 2023 at 13:32, Mark Alley via mailop 
 wrote:


What makes you think you'd go over the limit if you haven't done
the discovery? You might be surprised that you may not exceed the
lookup count, as with optimization/analysis and proper SPF design
(even without flattening), the lookup count can be quite easily
managed. This sounds like a prime candidate for your mail source
discovery with DMARC reporting <https://dmarcvendors.com>.

Using ?all (neutral) might be best for deliverability's sake while
you build out this SPF record during discovery. This would have
the same effect as your current scenario of having no SPF record,
while still allowing for positive matches of your legitimate known
mail-flow until you get to a point you move to ~all.

- Mark Alley

On 1/11/2023 7:08 AM, Simon Burke via mailop wrote:

All,

This is an odd scenario, but sadly one I find myself in.

Work is a large organisation, and currently does not have an SPF
record. The reason is that there are a large (and unknown) number
of internal and external parties that send mail on our domain, as
well as sub-domains.

So, even if we do determine who sends email on the domain, we
would then have an issue with max lookups and record length.

I know we can use an SPF flattening service. However that either
has a cost. Or, although we can develop something in house,
there's a 'bought not built' ethos being pushed by management.

As an out the box idea, what would the potential impact be of
having an SPF record stating just:

"V=spf1 a mx +all"

How bad of an idea would this be? If we also had a DMARC record
set to either quarantine or reject.

Regards,

Simon






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

___

Re: [mailop] Intentionally vague SPF records.

[Mark Alley via mailop]

What makes you think you'd go over the limit if you haven't done the 
discovery? You might be surprised that you may not exceed the lookup 
count, as with optimization/analysis and proper SPF design (even without 
flattening), the lookup count can be quite easily managed. This sounds 
like a prime candidate for your mail source discovery with DMARC 
reporting .


Using ?all (neutral) might be best for deliverability's sake while you 
build out this SPF record during discovery. This would have the same 
effect as your current scenario of having no SPF record, while still 
allowing for positive matches of your legitimate known mail-flow until 
you get to a point you move to ~all.


- Mark Alley

On 1/11/2023 7:08 AM, Simon Burke via mailop wrote:

All,

This is an odd scenario, but sadly one I find myself in.

Work is a large organisation, and currently does not have an SPF 
record. The reason is that there are a large (and unknown) number of 
internal and external parties that send mail on our domain, as well as 
sub-domains.


So, even if we do determine who sends email on the domain, we would 
then have an issue with max lookups and record length.


I know we can use an SPF flattening service. However that either has a 
cost. Or, although we can develop something in house, there's a 
'bought not built' ethos being pushed by management.


As an out the box idea, what would the potential impact be of having 
an SPF record stating just:


"V=spf1 a mx +all"

How bad of an idea would this be? If we also had a DMARC record set to 
either quarantine or reject.


Regards,

Simon






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


OpenPGP_0xE37A23C4D04F0409.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] I received a scam letter from Paypal

[Mark Alley via mailop]

A common scenario for these is that a legitimate PayPal account is 
compromised and then used to send out these invoices requests from the 
account, hence these requests/messages are sent via PayPal's email 
infrastructure to external recipients.


The best course of action for remediation would be to report these to 
PayPal's fraud division via a forward to "phish...@paypal.com"


On 12/28/2022 12:33 PM, John Devine via mailop wrote:
I’m pretty sure I had one of those and it was like you say quite 
‘real’ I had to log in to my PayPal account to check there had been no 
activity, how are they doing this?


On 28 Dec 2022, at 18:14, Cyril - ImprovMX via mailop 
 wrote:


Hi everyone!

If I recall correctly, there was already a discussion here on 
something similar, but I'd like to share my story here.


Yesterday, I received an email from Paypal with the subject "Reminder 
- You have paid an invoice".


The content of the email is the following:



There are a few things to note that are surprising :

  * The email is really coming from Paypal (serv...@paypal.com)
  * The SPF/DKIM AND DMARC are valid
  * All the links inside the email point to Paypal.com
, even though I haven't clicked on the "View
ad Pay Invoice"
  * The sending IP (66.211.170.90) is from Paypal: mx4.phx.paypal.com
 (https://check.mx/ptr/66.211.170.90)


And a few inconsistencies :

  * The subject says, "You have paid an invoice", but the body says,
"Please pay your invoice"
  * The bottom indicates that Paypal "will always contain your full
name", but the top indicates "Hello, PayPal Customer"
  * I haven't tried the phone number but pretty sure that's where the
scammers are sitting.

Here's the validation from GMail:



What I'm saying here, is what the hell? How a scam can come from 
Paypal like this?
This is a serious issue, and they need to fix this because I'm not 
sure my parents would catch the scam here, all seems legit!


Stay safe, and happy holidays!

Best,
Cyril
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop





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


OpenPGP_0xE37A23C4D04F0409.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Contact info for antispamcloud.com ?

[Mark Alley via mailop]

Checking the MX history, it looks like they've had these MX records in 
place for that domain for several years. Or am I missing something? Were 
you getting no resolution results previously?


On 12/26/2022 12:53 PM, Peter N. M. Hansteen via mailop wrote:

On Mon, Dec 26, 2022 at 06:26:26PM +, ml+mailop--- via mailop wrote:

On Sun, Dec 25, 2022, Peter Nicolai Mathias Hansteen via mailop wrote:


but since they have no valid MX record

What's wrong with the MX records?

dig antispamcloud.com. mx
antispamcloud.com.  600 IN  MX  10 filter10.antispamcloud.com.
antispamcloud.com.  600 IN  MX  30 filter30.antispamcloud.com.
antispamcloud.com.  600 IN  MX  20 filter20.antispamcloud.com.
antispamcloud.com.  600 IN  MX  40 filter40.antispamcloud.com.

filter10.antispamcloud.com. 120 IN  A   38.111.198.185
filter20.antispamcloud.com. 300 IN  A   38.89.254.156
filter30.antispamcloud.com. 292 IN  A   38.111.198.185
filter40.antispamcloud.com. 300 IN  A   38.109.53.20

This means they fixed them.

Possibly in response to the message I input in their contact form which is 
likned from their whois info.


Do you mean that the IPs don't map back to the names?
185.198.111.38.in-addr.arpa. 43200 IN   PTR 
fe2-r2-in.la10.l.antispamcloud.com.

No, but that is a separate problem that I suppose somebody might point out to 
them
if one were at all inclined to be friendly towards that outfit.


That's not a problem wrt MX records, right?

Again, the fact that they now *have* MX records is an improvement.

For their sake one could hope that the find somebody to sort out their reverses 
too.

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