Re: [mailop] Outlook JMRP IP Feedback not available

[Simon Arlott via mailop]

On 26/06/2024 19:25, Scott Mutter via mailop wrote:
> What would cause an IP address to not show as being available for Outlook's
> JMRP?

IP addresses can only be a member of one feed. You should be able to see
all JMRP feeds that directly contain an IP address you have access to,
even if you can't manage the feed (which requires access to all IP
addresses on the feed).

It's also possible to include networks in a JMRP feed, which then stops
you from adding it to an individual feed. I don't know if you can see
details of that feed if you only have access to one of the IPs. Do you
have access to the entire network in SNDS?

> When I visit the SNDS page using this, I get:
> 
> Error: no data for the specified IP

This is the SNDS page, not JMRP.

-- 
Simon Arlott

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

Re: [mailop] Increase in outlook.com S3150 rejections

[Simon Arlott via mailop]

On 19/02/2024 14:15, Fernando MM via mailop wrote:
> I was wondering if anyone else is also experiencing this type of issue?

It still happens every 10-12 weeks for me. It's getting increasingly
difficult to get them to implement "mitigation".


For example (these are all responses over 24 hours for one IP):

"Nothing was detected to prevent your mail from reaching
Outlook.com customers. Please follow the instructions below."

"I do not see anything offhand with the IP’s that would be preventing
your mail from reaching our customers."

"As stated previously, I do not see anything offhand that would be
preventing your mail from reaching our customers for the following IP
For more detailed information about best sending practices to
Outlook.com users, please review the following white paper [from 2007
where the links don't work any more]"

"Nothing was detected to prevent your mail from reaching Outlook.com
customers. Please follow the instructions below."

"I do not see anything offhand with the IP’s that would be preventing
your mail from reaching our customers."

"I do not see anything offhand with the IP’s that would be preventing
your mail from reaching our customers."

"We have implemented mitigation for your IP and this process may take
24 - 48 hours to replicate completely throughout our system."

-- 
Simon Arlott

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

[Simon Arlott via mailop]

On 19/01/2024 00:33, Randolf Richardson, Postmaster via mailop wrote:
>   The blacklists seem to be blocking mostly the ones that send 
> directly from @.onmicrosoft.com addresses, which 
> should make filtering easy if we can confirm for certain that no 
> legitimate eMail has these as the sender -- that is, not in the 
> "Return-Path:" header and not in the "From:" header.

I have a legitimate email today from @example.onmicrosoft.com (both
envelope sender and From: header) that is a cross-organisation meeting
invite. Normally all of their email uses their domain but some Microsoft
software is using this internal domain for meeting invites.

Indiscriminate blocking is going to unexpectedly reject real email.

-- 
Simon Arlott

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

Re: [mailop] Single deliveries are good for you was, Gmail now deferring

[Simon Arlott via mailop]

On 31/12/2023 16:02, John Levine via mailop wrote:
> A message with a dozen recipients in the same SMTP session is a very
> strong spam signal. So don't do that, do single deliveries like
> everyone else does.

Except that Google and Microsoft don't do single deliveries. Yahoo does.

"Do as I say, not as I do"?

-- 
Simon Arlott

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

Re: [mailop] Merry Christmas from Google?

[Simon Arlott via mailop]

On 17/12/2023 15:01, Jarland Donnell via mailop wrote:
> I “think” these new messages represent a clarification on the reasons 
> more than a change of the internal reasons. I’ve long suspected their IP 
> rate limit message of only sometimes being an actual IP based rate 
> limit. I just never sat down long enough to prove it.

No, I think this is something new.

Total email to Google this month, by outgoing server (email to multiple
recipients counted multiple times):

G   P   Y
2023-12-01  1   2   8
2023-12-02  1   2   0
2023-12-03  0   0   1
2023-12-04  0   0   2
2023-12-07  1   0   1
2023-12-08  1   0   0
2023-12-09  0   1   2
2023-12-11  1   0   1
2023-12-13  2   0   0
2023-12-14  2   0   3

Today I'm getting "Gmail has detected an unusual rate of unsolicited
mail originating from your IP Netblock [78.47.120.45  15]".


The last time I got an "Our system has detected an unusual rate of
unsolicited mail originating from your IP address" was 2019-07-15 and
it was successfully delivered through one of Google's other incoming
servers before it ran out of MX records to attempt delivery to.

-- 
Simon Arlott

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

[mailop] Microsoft Hotmail: why S1350 blocking every 3 months?

[Simon Arlott via mailop]

This happens every 3 months now:

2023-10-29T19:22:20.569+00:00 1qxBMV-0086ua-AC ** @hotmail.com
P= R=dnslookup_ipv4 T=remote_smtp
H=hotmail-com.olc.protection.outlook.com [104.47.58.161]:25 
I=[209.16.157.42]:40134
X=TLS1.2:ECDHE_SECP384R1__RSA_SHA256__AES_256_GCM:256 CV=yes
DN="C=US,ST=Washington,L=Redmond,O=Microsoft 
Corporation,CN=mail.protection.outlook.com":
SMTP error from remote mail server after MAIL FROM: SIZE=4773:
550 5.7.1 Unfortunately, messages from [209.16.157.42] weren't sent. 
Please contact your Internet service provider since part of their network is on 
our block list (S3150). You can also refer your provider to 
http://mail.live.com/mail/troubleshooting.aspx#errors. 
[BN8NAM11FT042.eop-nam11.prod.protection.outlook.com 2023-10-29T19:22:20.489Z 
08DBD7DEDE23957D]

Every time I go through the mitigation dance and then it just happens
again 3 months later. They've been doing this for over 2 years now.

Between the last mitigation on 2023-08-16 and now there have been a
total of 3 emails delivered to Hotmail.

In the same period two other outgoing IPs have sent 9 and 8 emails to
Hotmail but they have never experienced a single S3150 rejection.

I know from netflow data that there's barely any SMTP traffic to Hotmail
in the entire network (and only certain IPs are authorised to make SMTP
connections) so why does Microsoft keep blocking me repeatedly?

(SNDS: "All of the specified IPs have normal status")

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

Re: [mailop] fastmail and sender score snafu

[Simon Arlott via mailop]

On 09/10/2023 07:44, Kirill Miazine via mailop wrote:
> The reason for a long retry is that I have to manually decrypt mailstore 
> partition in case of server reboot. Exim would accept the message, but 
> defer delivery until the mount appears. I wanted to have some time in 
> case of a reboot and me not being easily available to mount the partition.

You need to configure different retry times for local domains and then
set delay_warning_condition so that it doesn't send warning emails
unless the origin is local.

-- 
Simon Arlott

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

Re: [mailop] Zero-day RCE for exim - whacky stats?

[Simon Arlott via mailop]

On 30/09/2023 09:35, Carsten Schiefner via mailop wrote:
> But would you happen to have any more details wrt. the withholding and 
> the 50%?

https://seclists.org/oss-sec/2023/q3/254


"< jgh> one's in the resolver library.  I find it questionable that it's
being raised against Exim, as if we have to protect ourselves against a
library.  But AFAIK it's still open.

< jgh> whatever the system resolver library accesed via res_search() is"

I assume this is https://www.zerodayinitiative.com/advisories/ZDI-23-1473/


"< jgh> one's in SPA.  Status unknown; I couldn't trace the alleged
notification to us
< jgh> (could be just the library, again)"

I assume this is https://www.zerodayinitiative.com/advisories/ZDI-23-1471/


There are no comments related to this one, but it incorrectly describes
Exim as the vendor for libspf2:

https://www.zerodayinitiative.com/advisories/ZDI-23-1472/

-- 
Simon Arlott

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

Re: [mailop] Zero-day RCE for exim - whacky stats?

[Simon Arlott via mailop]

On 30/09/2023 08:50, Andrew C Aitchison via mailop wrote:
> I see that there is an Exim release candidate out on test at the moment
>https://lists.exim.org/lurker/message/20230926.174111.cb403675.en.html
> but know nothing about whether it fixes any of these vulnerabilities.

It doesn't fix the vulnerabilities. The fixes are being withheld until
the release of 4.97 and only cover the 50% of the reported
vulnerabilities (those that affect the SPA authenticator).

-- 
Simon Arlott

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

Re: [mailop] Google Toolbox broken?

[Simon Arlott via mailop]

On 02/06/2023 08:45, Gellner, Oliver via mailop wrote:
> the Google admin toolbox claims our DKIM keys and MTA-STS entries are 
> invalid. Example: 
> https://toolbox.googleapps.com/apps/checkmx/check?domain=dm.de&dkim_selector=dmglobal4
>  reports "Invalid format of DKIM record" and "MTA STS is malformed". I cannot 
> find out what is invalid about them, can someone shed some light on this? Or 
> is the Google admin toolbox broken, or is it only designed for Gsuite domains 
> and expects some Google specific entries like it does for the SPF check?

It's very broken because it's making Recursion Desired DNS queries to my
Authoritative DNS servers, and I drop those.


Google then fails to implement RFC8461 correctly, despite authoring it:

"The MTA-STS TXT record must comply with RFC8461
Multiple records found."

I have these DNS records, which is valid because only one begins with
"v=STSv1;":
_mta-sts TXT "v=RFC7672; this obsession with PKIX must stop; use DANE"
_mta-sts TXT "v=STSv1; id=0"


It says this at the bottom, so it looks like it accepts my DKIM/DMARC
records:
"DKIM authentication DNS setup."
"Formatting of DMARC policies."

-- 
Simon Arlott

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

Re: [mailop] Mailing lists, Apple and failing DKIM signatures

[Simon Arlott via mailop]

On 22/05/2023 19:49, Jim Popovitch via mailop wrote:
> DO use Mailman's built-in DMARC mitigations for re-writing From for
> DMARC identified domains, including p=none.

For a DMARC (p=reject) domain, if the From: header is rewritten, the
presence of a failing DKIM signature still causes Apple to add 1 to the
spam score:

X-Apple-MoveToFolder: Junk
X-ICL-SCORE: 4.333033240041
x-spam-flag: yes
x-suspected-spam: true
...
Authentication-Results: bimi.icloud.com; bimi=skipped reason="missing evidence"
X-ARC-Info: policy=fail; arc=none
Authentication-Results: arc.icloud.com; arc=none
Authentication-Results: dmarc.icloud.com; dmarc=pass 
header.from=lists.example.com
X-DMARC-Info: pass=pass; dmarc-policy=reject; s=r1; d=r1; 
pdomain=lists.example.com
X-DMARC-Policy: v=DMARC1; p=reject; rua=mailto:dmarc-repo...@example.com; 
ruf=mailto:dmarc-repo...@example.com; fo=1
Authentication-Results: dkim-verifier.icloud.com; dkim=pass (1024-bit key) 
header.d=lists.example.com header.i=@lists.example.com header.b=kZPnt/iY
Authentication-Results: dkim-verifier.icloud.com; dkim=fail reason="signature 
verification failed" (3072-bit key) header.d=example.net header.i=@example.net 
header.b=m+UnOE2q
Authentication-Results: dkim-verifier.icloud.com; dkim=permerror (0-bit key) 
header.d=example.net header.i=@example.net header.b=J0UvU0HU
Authentication-Results: dkim-verifier.icloud.com; dkim=neutral (0-bit key) 
header.d=example.net header.i=@example.net header.b=gfXmzzC8
Authentication-Results: dkim-verifier.icloud.com; dkim=permerror (0-bit key) 
header.d=example.net header.i=@example.net header.b=UZxRPpOF
Authentication-Results: spf.icloud.com; spf=pass ...
...
From: Example via Example 
Cc: Example 

X-Apple-MoveToFolder: INBOX
...
X-ICL-SCORE: 3.333033230041
Authentication-Results: bimi.icloud.com; bimi=skipped reason="missing evidence"
X-ARC-Info: policy=fail; arc=none
Authentication-Results: arc.icloud.com; arc=none
Authentication-Results: dmarc.icloud.com; dmarc=pass 
header.from=lists.example.com
X-DMARC-Info: pass=pass; dmarc-policy=reject; s=r1; d=r1; 
pdomain=lists.example.com
X-DMARC-Policy: v=DMARC1; p=reject; rua=mailto:dmarc-repo...@example.com; 
ruf=mailto:dmarc-repo...@example.com; fo=1
Authentication-Results: dkim-verifier.icloud.com; dkim=pass (1024-bit key) 
header.d=lists.example.com header.i=@lists.example.com header.b=iMjTZqEm
Authentication-Results: spf.icloud.com; spf=pass ...
...
From: Example via Example 
Cc: Example 

-- 
Simon Arlott

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

[mailop] Mailing lists, Apple and failing DKIM signatures

[Simon Arlott via mailop]

If you're running a mailing list that retains the original DKIM
signatures [that will fail because the message subject and body have
been modified] you might want to strip/hide them because it can cause
Apple iCloud Mail to increment the spam score by 1 which can cause it to
be delivered to Junk (despite "I've pretty religiously been marking each
email as not spam but it's not keen at all").

For an email originating from gmail.com retaining the original From:,
it doesn't appear to care about the DMARC failure (p=none) but it
doesn't like the failed DKIM signature.

There was also a signed ARC result (from before the email reaches
Mailman) that would be invalid but hiding that didn't have any visible
effect on the score. There's no forwarding involved, the user is
subscribed directly with an address hosted by iCloud.

X-ICL-SCORE: 4.332033240044
X-Apple-MoveToFolder: Junk
x-spam-flag: yes
x-suspected-spam: true
...
Authentication-Results: bimi.icloud.com; bimi=skipped reason="insufficient 
dmarc"
X-ARC-Info: policy=fail; arc=fail; id=mx5.messagingengine.com
Authentication-Results: arc.icloud.com; arc=fail
Authentication-Results: dmarc.icloud.com; dmarc=fail header.from=gmail.com
X-DMARC-Info: pass=fail; dmarc-policy=none; s=r0; d=r0; pdomain=gmail.com
X-DMARC-Policy: v=DMARC1; p=none; sp=quarantine; 
rua=mailto:mailauth-repo...@google.com
Authentication-Results: dkim-verifier.icloud.com; dkim=pass (1024-bit key) 
header.d=lists.example.com header.i=@lists.example.com header.b=soRHKGr8
Authentication-Results: dkim-verifier.icloud.com; dkim=fail reason="signature 
verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com 
header.b=rcro5QTc
Authentication-Results: spf.icloud.com; spf=pass ...
...
From: Example 

X-ICL-SCORE: 3.333033230041
X-Apple-MoveToFolder: INBOX
...
Authentication-Results: bimi.icloud.com; bimi=skipped reason="insufficient 
dmarc"
X-ARC-Info: policy=fail; arc=none
Authentication-Results: arc.icloud.com; arc=none
Authentication-Results: dmarc.icloud.com; dmarc=fail header.from=gmail.com
X-DMARC-Info: pass=fail; dmarc-policy=none; s=r0; d=r0; pdomain=gmail.com
X-DMARC-Policy: v=DMARC1; p=none; sp=quarantine; 
rua=mailto:mailauth-repo...@google.com
Authentication-Results: dkim-verifier.icloud.com; dkim=pass (1024-bit key) 
header.d=lists.example.com header.i=@lists.example.com header.b=iMjTZqEm
Authentication-Results: spf.icloud.com; spf=pass ...
...
From: Example 

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

Re: [mailop] SPF behavior on email forwarding

[Simon Arlott via mailop]

On 14/04/2023 12:26, Cyril - ImprovMX via mailop wrote:
> What is the best approach here?

Identify the forwarders your customers are using and for those origins
either assume SPF passed or lookup the SPF result in the headers.

-- 
Simon Arlott

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

Re: [mailop] Outlook JMRP unable to add new IP address

[Simon Arlott via mailop]

On 06/04/2023 17:22, Scott Mutter via mailop wrote:
> But when I go to add the IP under the Junk Mail Reporting Program, the IP
> address is not shown.
> 
> "If you want to add any IP addresses not shown below, please request access
> to those IPs"
> 
> There's no IP addresses listed.  And like I've said, I've already done the
> request access part.

If it's already in another JMRP feed you can't add it to a new one. Does
someone else have access to the network that contains the IP? They may
have created a JMRP feed and you're probably not able to see it.

-- 
Simon Arlott

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

Re: [mailop] How to address Microsoft if spaming Office365 customers cause collateral damage for other Office365 customers sharing the same IP?

[Simon Arlott via mailop]

On 30/03/2023 16:48, Michael Peddemors via mailop wrote:
> Now, if you could get EVERYONE to block them for a day, or find some 
> other way to hit their pocket books, maybe we could see some relief. 

Co-ordinate deferring all email from them for a 30 hour period (UTC
00:00 to UTC 32:00, so that it covers a full day in the US) on specific
days of the week?

By not blocking email you avoid causing too much collateral damage,
Microsoft will just appear to be slow at delivery some of the time.

That should have a visible impact on their outgoing mail queue, right?

Too frequent retries might be a bit of a problem, but that'll affect
them too.

-- 
Simon Arlott

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

Re: [mailop] Hetzner

[Simon Arlott via mailop]

On 07/02/2023 16:08, Michael Peddemors via mailop wrote:
> Yes, the spammers are picking up on the Hetzner networks again..
> Maybe a priority abuse line is needed for those in the threat detection 
> industry..

Maybe when people like Return Path stop sending in false abuse reports?

I've had two so far, for emails sent from the IP address over a year
before Hetzner assigned it to me.

This claims a date in 2021 for an email over a year earlier in 2020:

> Source: Telenet
> Abuse-Type: complaint
> Feedback-Type: abuse
> User-Agent: ReturnPathFBL/2.0
> Arrival-Date: Sat, 16 Oct 2021 16:01:25 +
>
> Received: from elasmtp-galgo.atl.sa.earthlink.net ([*.*.*.*])
>   by charles.telenet-ops.be with bizsmtp
>   id *; Wed, 30 Sep 2020 05:53:49 +0200

This claims a date in 2022 for a different email over two years before
in 2020:

> Source: Telenet
> Abuse-Type: complaint
> Feedback-Type: abuse
> User-Agent: ReturnPathFBL/2.0
> Arrival-Date: Fri, 07 Oct 2022 09:08:26 +
> 
> Received: from lucien.telenet-ops.be (LHLO lucien.telenet-ops.be)
>  (2a02:1800:120:4:0:0:f00:16) by zcsnocm106.telenet-ops.be with LMTP; Wed,
>  30 Sep 2020 14:44:41 +0200 (CEST)
> Received: from elasmtp-galgo.atl.sa.earthlink.net ([*.*.*.*])
>   by lucien.telenet-ops.be with bizsmtp
>   id *; Wed, 30 Sep 2020 14:44:41 +0200

RFC 5965:
"Arrival-Date" indicates the date and time at which the original
message was received by the Mail Transfer Agent (MTA) of the
generating ADMD (Administrative Management Domain).

-- 
Simon Arlott

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

Re: [mailop] starttls-virginia.securing-email.com 34.227.19.103

[Simon Arlott via mailop]

On 16/09/2022 04:46, Bill Cole via mailop wrote:
>> Anyone recognize them?
> 
> Looks like the same vt.edu bozos who have at least 2 prior rounds of bad 
> research behavior.

I've blocked them previously:
2020-03-17 3.104.129.119 comment "proxy-research.com"
2020-03-17 15.164.73.143 comment "proxy-research.com"
2020-03-17 15.188.24.147 comment "proxy-research.com"
2020-03-17 34.227.19.103 comment "proxy-research.com"
2020-03-17 54.94.237.221 comment "proxy-research.com"
2020-03-17 54.187.79.149 comment "proxy-research.com"

15.164.73.143 may have been discontinued since then:
143.73.164.15.in-addr.arpa domain name pointer 
ec2-15-164-73-143.ap-northeast-2.compute.amazonaws.com.

34.227.19.103 is the first one to use the new domain:
119.129.104.3.in-addr.arpa domain name pointer 
starttls-sydney.proxy-research.com.
147.24.188.15.in-addr.arpa domain name pointer 
starttls-paris.proxy-research.com.
103.19.227.34.in-addr.arpa domain name pointer 
starttls-virginia.securing-email.com.
221.237.94.54.in-addr.arpa domain name pointer 
starttls-saopaulo.proxy-research.com.
149.79.187.54.in-addr.arpa domain name pointer 
starttls-oregon.proxy-research.com.

I think it's just a coincidence that the one you mention is named
"virginia" because it's hosted at AWS. I don't think this is vt.edu.

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

Re: [mailop] smtp dane/tlsa

[Simon Arlott via mailop]

On 02/09/2022 16:16, Carl Byington via mailop wrote:
> Years ago I setup automation for tlsa records to support smtp dane here.
> However, something is now broken, and I am not sure what is wrong.
> 
> _25._tcp.mail3.five-ten-sg.com. IN TLSA 3 0 1 (
>   834d710b2feb790cc9b2c6d251c65b1fedc24c51a4149bdfeae4d40e0be11892
> )
> 
> https://www.huque.com/bin/danecheck-smtp shows DANE TLSA 3 0 1
> [834d710b..]: not checked and a failed result.

Looks like the latest version of this (https://github.com/shuque/gotls)
returns the reason why it fails, which appears to be a bug in the tool
caused by the expired DST X3 CA:

Result: FAILED: DANE TLS error: cert chain: x509: certificate has expired or is 
not yet valid: current time 2022-09-03T09:10:15Z is after 2021-09-30T14:01:15Z

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

Re: [mailop] Research project on SPF validation: Is your server violating RFC standards for SPF resolution?

[Simon Arlott via mailop]

On 25/08/2022 11:39, Tobias Fiebig via mailop wrote:
> An attacker may use an infinite number of SPF referrals in their SPF setting 
> and can send an email to a vulnerable mail server which would make the SMTP 
> server make a whole lot of DNS queries. By exploiting this vulnerability, an 
> attacker can block the SMTP queue of the server, flood the associated 
> recursive resolver, or any DNS authoritative server.

That requires a broken implementation for SPF lookups that has no limit.

You are yet another unethical research project that has been actively
attacking people running such broken implementations:

https://forum.iredmail.org/topic18756-iredapd-is-killed-by-spam-i-have-to-restart-every-few-hours.html


Increasing the limit only increases the number of potential DNS queries
from a single email, assuming no minimum cache time on the resolver. The
RFC needs to be updated to match the reality that a lot of email
services for the same domain are outsourced to multiple entities and so
there will be a lot of "include:" DNS queries.


I blocked your domain "net-measurement.org" back in February when you
sent an unsolicited message to one of my servers:

 Forwarded Message 
Subject:Measuring and understanding the behavior of SPF record lookup
Date:   Tue, 15 Feb 2022 17:49:20 +0600 (+06)
From:   Ubuntu 
To: admin@[redacted], abuse@[redacted], postmaster@[redacted]

Hi,
We are a security team at Virginia Tech and we are currently measuring how SPF 
records are being looked up on your end. This is a one-time email and you will 
not receive any further emails from our end. If you do receive more than one 
email from us, please copy and paste the following link on your browser and 
contact us at the given email addresses. We do apologize for this matter and 
thank you for your understanding.

https://vtnetsec.notion.site/Measuring-and-understanding-the-behavior-of-SPF-records-look-up-in-SMTP-servers-4b95e74c017048e781a575eab03b405c
 

Please do not reply to this email, it is not monitored. If you'd like to 
contact us, please visit the given link above.

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

Re: [mailop] Gmail spam scoring via IPv6 different than IPv4?

[Simon Arlott via mailop]

On 12/08/2022 17:22, Jesse Hathaway via mailop wrote:
> Back in 2013[1] we changed our mail config to force MX lookups for gmail
> to only use IPv4 addresses.  We made these change after hearing reports
> of higher spam scoring when sending mail via IPv6. Would anyone from
> Google be able to comment as to whether forcing IPv4 is still needed?
> Yours kindly, Jesse Hathaway

My experience in the past is that because Google insist on a successful
matching reverse DNS lookup for IPv6, it will randomly permanently
reject email for a temporary error. It looks like Google are now doing
this for IPv4 too but I don't know if they've fixed it to handle
temporary DNS errors properly.

The other general problem is that your server's reputation will probably
be different for each address and suddenly swap between IPv6 and IPv4 on
a retry. Ideally random outgoing address selection across all IP address
families should be used to avoid this but Exim can't do that.

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

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Simon Arlott via mailop]

On 03/08/2022 21:05, Jarland Donnell via mailop wrote:
> I don't understand why Firefox did this: 
> https://hacks.mozilla.org/2019/05/tls-1-0-and-1-1-removal-update/
> 
> Clients can clearly click the lock, check the details, and see which SSL 
> version they're using. So if the site says it's secure and it isn't, 
> that's on the client. So why is anyone doing this? You guys are replying 
> to me like I'm some insane outlier here by suggesting that there's merit 
> to a basic security practice of not allowing insecure ciphers/protocols, 
> and I'm sitting here staring at my screen saying "How can anyone call 
> themselves a professional and seriously argue against that?" Just cards 
> on the table here, that's the perspective on this side.

The problem here is the fallback to plaintext. Web browsers don't
fallback to plaintext without user intervention. There is no user to
intervene in email.

I support disabling TLS 1.0/1.1 but there is a trade-off to be made,
especially when the remote client may not even be verifying your
certificate despite using TLS 1.2.

The same issues arise with older ciphers and support for MD5/SHA1.

If there was a viable downgrade attack that could make a TLS 1.2 client
[that isn't providing a client certificate] use TLS 1.0/1.1 then that
would be a good reason for disabling TLS 1.0/1.1 support.

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

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Simon Arlott via mailop]

On 03/08/2022 20:01, Jarland Donnell via mailop wrote:
> End users get headers which is admittedly not useful to most, but the 
> "lock" on Gmail is at least fast becoming an accepted thing, seeing more 
> email clients latch onto that is a bit slow but is happening. Of course, 
> it should only be trusted when it's from the headers added by your last 
> MTA in the transaction, everything between can't be verified.

That's not really something the MUA can easily do... all of my incoming
email arrives using TLS because there's an internal hop.

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

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Simon Arlott via mailop]

On 03/08/2022 16:46, Jarland Donnell via mailop wrote:
> It's a pretty big and well respected security practice to consider plain 
> text to be more secure than insecure SSL for one reason: A plain text 
> connection isn't logged or reported as a secure connection. Both being 

There's nothing that requires you to log a TLS 1.0/1.1 connection as
being secure. You could choose to log it as if it were plaintext. It's
likely to be logged with the protocol and cipher information.

> insecure, only one of the two involves your server negotiating and 
> reporting to the third party that you are accepting it over a secure

Your server doesn't really report to the other server that the
connection is secure, only that it could be established. The other
server may have decided that it's secure based on its protocol and
cipher support.
 
> connection. Which is basically a lie. Plain isn't a lie, and that's 
> worth something.

Having said that, I'm currently accepting TLS 1.0/1.1 connections as a
server with a restricted cipher list but requiring TLS 1.2 as a client
(which will then fallback to plaintext).


Cipher selection is another issue... I have come across one organisation
that had configured their TLS-only servers to only support the x25519
curve when using ECDHE - and my cipher configuration requires DHE/ECDHE.

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

Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?

[Simon Arlott via mailop]

On 22/07/2022 10:21, Laura Atkins via mailop wrote:
>> After that there should be an integrated opt-in process to verify any
>> new email address for that ESP customer's list.
> 
> While this sounds simple and like a no-brainer, it doesn’t account for how 
> complex many companies email programs are. In many, many cases full customer 
> data isn’t kept at the ESP - nor should it be. The ESP doesn’t need to know 
> (and in fact absolutely shouldn’t know) things like credit card numbers or 
> login passwords. There are also a number of systems that don’t keep email 
> addresses at all. Mail is triggered through an API call and all of the email 
> addresses are stored on the sender’s system, “lists” never go near the ESP. 
> All the ESP sees are send requests. 

At no point did I suggest the ESP needs to receive more than the email
address?

Only the email verification message needs to go through the ESP. It
could insert a confirmation token in a URL that the ESP customer then
presents to confirm opt-in for that ESP account.

None of this prevents PayPal, banks, etc. from operating. It also
doesn't prevent online shops from operating but it does complicate the
process of receiving a receipt if that normally comes direct from the
payment processor because all messages would need to use the same ESP.

There's just a conflict of interest between "people pay us to send
email" and "people who pay us nothing don't want to receive that email".

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

Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?

[Simon Arlott via mailop]

On 21/07/2022 10:01, Andrew C Aitchison via mailop wrote:
> On Sun, 9 Jan 2022, Atro Tossavainen via mailop wrote:
> 
>> The basic problem is allowing an ESP customer to import a list that
>> existed before the customer became a customer of this ESP. I can't
>> think of an ESP that would not allow that.
> 
> I saw this again as someone replied to it.
> 
> Sadly, there is at least one legitimate reasons to allow this:
> how else could a customer change ESP ?

It should only be possible to import addresses from a list once or
twice, not on a regular basis.

After that there should be an integrated opt-in process to verify any
new email address for that ESP customer's list.

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

Re: [mailop] [E] What the f**k, Google?

[Simon Arlott via mailop]

On 02/03/2022 18:00, Edgaras | SENDER via mailop wrote:
> We did, several times actually.
> Does nothing.

It doesn't look like you're able to provide an example of an email where
Google have accepted it as belonging to you when the DKIM signature
fails.

Do you only have the IP addresses that were involved in resending your
email? I have no idea what information Google provide to you.

You would be able to tell when Google make DNS queries for selectors
that you have revoked (rotating without removing or modifying them will
not be enough) by monitoring queries on your DNS servers.

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

Re: [mailop] Preventing replay attacks after signing spam email (was: What the f**k, Google?)

[Simon Arlott via mailop]

On 02/03/2022 18:09, Edgaras | SENDER wrote:
>> No, that's quite clearly not literally true. Stop DKIM signing the spam
> email and the problem goes away.
> Yep, and go directly against all the best email practices, guidelines and
> so on.

You're ignoring my point that you should stop sending [signed] spam
email by interpreting it as "stop signing email".

>> You may not like it but Google is implementing DMARC correctly if the
> DKIM signature is still valid.
> The point is not their implementation of DMARC. It's how they handle
> messages from obvious spam sources, which funnily enough don't satisfy any
> of their own guidelines https://support.google.com/mail/answer/81126,
> except for a hijacked DKIM signature.

These emails were DKIM signed by the sender; except for the ones with
additional unsigned headers the signature has not been hijacked. The
sender has DKIM signed a spam email.

If you are unwilling to moderate spam email from new accounts before
DKIM signing their email with your own domain then I suggest you use a
separate DKIM selector for each of them so that you can revoke them
quickly. This does not require additional keys because the selector name
is covered by the signature.

DKIM selectors can include "." so you can even use a wildcard DNS record
for them and only add a non-wildcard record for the ones you need to
revoke. A short TTL will be necessary but you would only need to do that
for the subset of selectors used for email that could be spam.

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

Re: [mailop] [E] What the f**k, Google?

[Simon Arlott via mailop]

On 2 March 2022 17:12:14 GMT, Edgaras | SENDER via mailop  
wrote:
> To clarify further, I will walk through the case where an attacker abuses
> Getresponse (getresponse2.eml).
> What happens here:
> 1. Attacker creates an account at Getresponse using a throwaway spam site
> storagemodels.org.uk
> 2. Sends a single email from Getresponse (using re...@storagemodels.org.uk)
> to himself (arsalanpir...@gmail.com is the attacker's Gmail address)
> 3. The email is signed with getresponse-mail.com, a domain with a good
> reputation at Gmail.

The spam email has been signed by getresponse-mail.com

> 4. Attacker then proceeds to spam from 119.235.249.182, spam mails count
> against the reputation of getresponse-mail.com
> 5. Mails are delivered to countless Gmail users.

> There's literally nothing you can do as a sender to prevent your reputation 
> from being trashed.

No, that's quite clearly not literally true. Stop DKIM signing the spam email 
and the problem goes away.

> What's worrying is that even if the headers are oversigned, DMARC set to 
> reject, it does nothing to stop this attack.

Do you have an example where the DKIM signature is now invalid but Google has 
accepted it and associated it with the victim domain?

You may not like it but Google is implementing DMARC correctly if the DKIM 
signature is still valid.

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

Re: [mailop] [E] What the f**k, Google?

[Simon Arlott via mailop]

On 02/03/2022 15:44, Edgaras | SENDER via mailop wrote:
> Sorry for losing my nerve, but it is harming our reputation for a month
> now, tried all possible channels to report this, and the issue is being
> completely ignored.

These examples have the same problem that the original one in January
did. They're just copies of emails without any explanation as to who
you are and which domain's reputation is being impacted.

Which domains, IP addresses and DKIM signatures are you responsible for
(or not) in the examples?

If you need to redact something then replace it with "example.com",
"example.net", "example.org", etc. and state how each of them fit into
this. Provide a copy of the SPF/DKIM records (where relevant) for any
redacted domains (the immediate sending IP may not be in the SPF record
but maybe an earlier one or Google is).

Which domain's reputation is being impacted?

Without that information it's very hard to identify exactly what is
going on. You've stated previously that "first an attacker sent a test
email from our platform" but these ones don't appear to originate from
you.

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

Re: [mailop] Privacy research spam apparently from a grad student at Princeton

[Simon Arlott via mailop]

On 14/12/2021 18:53, John Levine via mailop wrote:
> I think this is different and really is a botched survey from a grad student. 
>  Poking
> around his department's web site, it seems like the sort of stuff he is 
> interested in.

The way the content is phrased makes them almost identical.

Either:
1. The scam emails are really a version of the survey but using fake
   names and domains.
2. The scammers are now using this researcher's name to make it appear
   legitimate.
3. The researchers have copied the "scam" text.

I've had similar spam from the "CISPA Helmholtz Center for Information
Security and Ruhr-University Bochum in Germany" that looks legitimate
albeit misguided in believing that it's appropriate to email abuse@ on
every website they think lacks a privacy policy.

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

Re: [mailop] 0spam.org DNSBL SERVFAIL

[Simon Arlott via mailop]

On 12/11/2021 18:56, Slavko via mailop wrote:
> I am using bl.0spam.org and nbl.0spam.org RBLs in my custom RBL check
> script, but in more days their DNS server returns SERVFAIL.
> 
> Please, are these RBL gone or it is only mistake in its configuration?

The DNSSEC RRSIG for the SOA RR is out of date, so all NXDOMAIN (not
found) responses will fail to validate:
https://dnsviz.net/d/1.0.0.127.bl.0spam.org/dnssec/

In this case, the signature is for the SOA with serial 2021110401 but
the current SOA serial is 2021110501:
https://gist.github.com/nomis/239c16f5f2321600e9397933b193d955


You can request data even if it doesn't validate by using
"dig +dnssec +cd":

0spam.org.  56 IN SOA ns1.0spam.org. sa.0spam.org. (
2021110501 ; serial
10800  ; refresh (3 hours)
3600   ; retry (1 hour)
1209600; expire (2 weeks)
3600   ; minimum (1 hour)
)
0spam.org.  56 IN RRSIG SOA 8 2 10800 (
20211219192545 20211104182545 53779 0spam.org.
rSfVa/1fDI+075D0UmXxiJJ2o8OJ37cszPhrtuvADk0e
OtNtfVH4q+vTP2mIVZKq3/DeE7aDFSiQNrL4rSoeubvq
+CmD6ACJ+vBW1hvw2teQgtTAV7CmIZgRbA+AJeHNOb9J
32U0hBWUs+s7hWyfjy7GLd3qLe13xBYajJeKLrw= )

0spam.org.  3566 IN DNSKEY 256 3 8 (
AwEAAa4Y6IcV8Aa47O2aJAciBJ+ys9r+ycnpR5nhWWOC
DHCXuLAUQZFWf9LbbNs1z2YrYuvpMhY424AK9nqkbBZl
9mTd+2suXd4PpKSK4AJ4YdA+WkOVF4O2zvQUzseYjAQh
fMaSlT7BwmVE1myRAn+x9gysJ+mBsHTiBvGxDgMAGnhf
) ; ZSK; alg = RSASHA256 ; key id = 53779

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

Re: [mailop] .eml Attachments and the 1000-character SMTP Limit

[Simon Arlott via mailop]

On 12/10/2021 06:19, John via mailop wrote:
> The answer is yes, it's not good practice to block messages containing long 
> lines in emails. That will likely cause problems at either the sender or 
> recipient. Senders may receive non-delivery notifications, recipients may 
> miss mails.
> 
> RFC5322 (2008) advises to handle long lines at least up to 998 characters. 
> However, there is no pressing technical need to filter. The 1000 character 
> rule appeared in rfc821 (1982), probably because it was believed that it was 
> a good idea to limit the format to the capacity of hardware and software at 
> the time. We've moved on, systems have sufficient memory and mail readers 
> have been smart enough to wrap long lines for a long time already.

Exim has a fixed limit of 16384 bytes per line when doing DKIM operations
and version 4.95 now has a default limit of 998 bytes on the (outgoing)
smtp transport. I'd like to fix the DKIM code but it's currently easier
to just recompile with significantly increased limits.

I think Debian still have a default limit of 998 bytes for Exim on
incoming email.

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

Re: [mailop] subscription bombing prevention best practices

[Simon Arlott via mailop]

On 17/10/2021 11:15, C A via mailop wrote:
> On Sun, Oct 17, 2021, Simon Arlott via mailop wrote:
> 
>> confirmation process only if your email passes SPF/DKIM (or DMARC). If
> 
> And if the sender doesn't use either?

If there are no SPF or DMARC records published then you can let them
continue to subscribe on the website and be vulnerable to subscription
bombing?

There has be some form of authentication of the address being subscribed
otherwise there's no way for each individual mailing list service to
know if it should reject a subscription request that's part of an
attack.

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

Re: [mailop] subscription bombing prevention best practices

[Simon Arlott via mailop]

On 20/01/2021 10:50, Stefano Bagnara via mailop wrote:
> I'm looking for brainstorming and updated industry "standards" from people
> handling outgoing SMTP services or ESP exporting APIs to "request
> subscriptions" (confirmed opt-in).

For mailing lists, it occurs to me that we should now be at the point
where SPF and DKIM are ubiquitous enough that sign-up can be by email
only and they should stop accepting sign-up on a website.

To subscribe to a mailing list you should need to send an email (to the
"sign-up address") and then your request would result in the usual
confirmation process only if your email passes SPF/DKIM (or DMARC). If
the sender fails to be authenticated then just discard the request.

If that was implemented everywhere, wouldn't that stop subscription
bombing?

It would at least stop small Mailman deployments from being abused, and
they already have to handle incoming spam so there's no difference
there.

The UX is different because you'd have to use mailto: addresses instead
of a form on a website but you could decide to trigger that from
JavaScript based on the domain they enter (to redirect to alternative
special-case flows for different providers).

mailto:list-subscr...@example.com?subject=Your%20ideas%20are%20intriguing%20to%20me,%20and%20I%20wish%20to%20subscribe%20to%20your%20newsletter.
 

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

Re: [mailop] eBay are sending email with their users' email addresses despite SPF -all and DMARC p=reject

[Simon Arlott via mailop]

No, there's no forwarding involved at all.

eBay failed to deliver it and then sent a bounce directly to my server.

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

[mailop] eBay are sending email with their users' email addresses despite SPF -all and DMARC p=reject

[Simon Arlott via mailop]

This is a bounce from eBay for an email they tried to deliver that uses
my domain for both the envelope sender and From: header. Not sure what's
going on here because they normally mask email addresses even when
sending a copy to yourself.

Delivery status notification:
From: Mail Delivery Subsystem 
Sent: *
To: *@arlott.org
Subject: Returned mail: see transcript for details

The original message was received at *
from *.stratus.rno.ebay.com [10.*]

   - The following addresses had permanent fatal errors -
<*@example.com>
(reason: 550 5.7.1 Email rejected per DMARC policy for arlott.org 
(G15))

   - Transcript of session follows -
... while talking to *.example.net:
>>> >>> DATA
<<< 550 5.7.1 Email rejected per DMARC policy for arlott.org (G15)
554 5.0.0 Service unavailable

The headers of the returned message:
Return-Path: <*@arlott.org>
Received: from *.stratus.rno.ebay.com (*.stratus.rno.ebay.com [10.*])
by *.ebay.com (8.14.7/8.14.7) with ESMTP id *
for <*@example.com>; *
Date: *
From: eBay - * <*@arlott.org>
To: *@example.com
Message-ID: <*@starship>
Subject: * has sent a question about item #*, ending on *
MIME-Version: 1.0
Content-Type: multipart/mixed; 
boundary="=_Part_*"
X-eBay-MailTracker: *
Feedback-ID: todo:*:eBayStarship

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

Re: [mailop] IPv6

[Simon Arlott via mailop]

On 06/10/2021 02:15, Brandon Long via mailop wrote:
> Generally speaking, outside of the obvious differences, most of our spam
> rules are agnostic to IPv4/IPv6.

The frustrating problem with Google's treatment of IPv6 is that the
"must have reverse DNS" requirement means it will return a 5xx permanent
error for a temporary DNS resolution failure, and reverse DNS typically
involves multiple nameserver delegations with no glue so it's never 100%
reliable.

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

[mailop] Abuse reporting to Microsoft?

[Simon Arlott via mailop]

I received a scam email from mail-ma1ind01on060c.outbound.protection.outlook.com
(2a01:111:f400:fea4::60c) so I reported it to the RIR contact,
ab...@microsoft.com and got the following reply implying that they
intend to ignore the problem entirely and expect me to feed it as input
to their spam analysis system for the benefit of their own customers.

If they have identified that it comes from their servers then why can
they not complete the process as an abuse report?

Is it actually possible to report email abuse to Microsoft?

Hi,

Based on the information you provided, it appears to have
originated from an Office 365 or Exchange Online tenant account.

To report junk mail from Office 365 tenants, send an email to
j...@office365.microsoft.com and include the junk mail as an
attachment.

This link provides further junk mail education

[https://technet.microsoft.com/en-us/library/jj200769(v=exchg.150).aspx].

Kindly,

April

Microsoft Online Safety

That email address is the standard one for "I think this is spam" (with
a corresponding equivalent for "I think this is not spam") to train the
spam filter - if you're a Microsoft customer, which I'm not.

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

Re: [mailop] Any mailbox providers that check geolocation of mail sending IP?

[Simon Arlott via mailop]

On 2021-06-10 16:00, Vytis Marciulionis via mailop wrote:

This is not a new process and we did not encounter any issues before.
However, initially this particular range came with geolocation being
registered to Turkey in RIPE.


Check all of the providers on this list have updated the location:
https://www.ripe.net/manage-ips-and-asns/db/tools/geolocation-in-the-ripe-database

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

[mailop] DKIM validation behaviour when multiple _domainkey TXT records are present

[Simon Arlott via mailop]

RFC 6376 does not define what happens when there are multiple TXT 
records for _domainkey selectors.


Some implementations allow this but Yahoo doesn't. It's considered a 
permanent failure.


In my case I accidentally added a second _domainkey TXT RR with an empty 
"" value and only noticed this when email was rejected by DMARC because 
the SPF domain was different and DKIM was failing.



I've yet to find a comprehensive DMARC tester that will handle all of 
the nuances like RFC5322.From and RFC5321.MailFrom needing to be aligned 
before SPF can be considered...


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

Re: [mailop] [EXTERNAL] Re: Registered @ Microsoft JMRP - blacklisted without feedback received

[Simon Arlott via mailop]

On 12/05/2021 04:08, Michael Wise via mailop wrote:
> S3150 is throttling.
> 
> Open a ticket and ask for a more realistic hourly/daily throttle limit.

I'm now having this problem too. My email volume is so small it never
appears on SNDS. There have been 10 messages to Hotmail this month (4
unique recipients) and now I'm getting S3150 replies to everything
despite still receiving email to the same IP from those recipients.

I'm being fed lies like "Your IP was blocked by Outlook.com because
Hotmail customers have reported email from this IP as unwanted".


"Outlook.com Deliverability Support" have also provided me with a link
to this amusing document:

> For more detailed information about best sending practices to
> Outlook.com users, please review the following white paper:
> http://download.microsoft.com/download/e/3/3/e3397e7c-17a6-497d-9693-78f80be272fb/enhance_deliver.pdf

It hasn't been updated since 2007 and it shows.

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

Re: [mailop] Reliability of DMARC reports?

[Simon Arlott via mailop]

On 14/03/2021 07:43, Hans-Martin Mosner via mailop wrote:
> The report also claims that SPF failed, although our SPF record included the 
> outgoing mailserver from the beginning, of
> course.

Did it fail for your IP or another IP?

> So this report looks like a red herring to me - not enough information to 
> debug what may have been wrong (ok for an
> aggregate report) but also containing highly questionable data.

Google generates a lot of noise when it allows an email that it knows is
being forwarded but still reports it as a failure. Often the host doing
the forwarding is inside Google.

> What's your experience with reliability of DMARC reports? Mostly helpful? Too 
> much nonsense?

If your outgoing email is set up correctly then all of the failures in
the report will look like noise. I'd keep receiving the reports for
later reference if something goes wrong.

I do observe IP addresses in China regularly trying to send email from
my domains.

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

Re: [mailop] Good Hosting Suggestions?

[Simon Arlott via mailop]

On 19/02/2021 16:45, Michael Peddemors via mailop wrote:
> For instance, have to shout out to the Linode guys for really improving 
> their reputation, over the last couple of years.. (still wish they 
> provided 'rwhois' entries, at least on customer demand, would make it 
> easier to see when someone started using the IP Address)

Nope, not a "good" provider:

On 14/02/2021 10:32, Linode Abuse wrote:
> Hi there,
> 
> Thank you for sending this email to us. So that we can verify this
> complaint, would you be able to send over the header information in the
> email in a response that isn't an attachment?
> 
> Regards,
> Linode Support Team

I'm not jumping through everyone's hoops to report abuse.


I planned to try and make an ARF plugin for Thunderbird but someone
pointed out to me that I'm just as likely to get people who are unable
to parse ARF messages.

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

Re: [mailop] Spamhaus Public Mirror Error Return Code Update

[Simon Arlott via mailop]

On 15/02/2021 18:25, Bill Cole via mailop wrote:
> On 15 Feb 2021, at 12:53, Jaroslaw Rafa via mailop wrote:
>> Dnia 15.02.2021 o godz. 15:43:56 Matthew Stith via mailop pisze:
>>> 127.255.255.252 - Typing error in DNSBL Name
>>> 127.255.255.254 - Query via public/open resolver/generic 
>>> unattributable rDNS
>>> 127.255.255.255 - Excessive Number of Queries
> 
> Postfix has supported specification of result values for DNSBLs for at 
> least 15 years. Restricting action to specific result values is 
> well-documented and generally considered a best practice, since the 
> problem of DNSBL domains falling into the hands of domain vultures who 
> wildcard all subsidiary names has been a known failure mode for as long 
> as DNSBLs have existed.

Note: it is not really good enough to just filter the responses and
ignore the problem. Invalid responses need to be logged for further
action, either to fix the resolver or remove the lookup.

There's a change in Exim to do this, but it assumes that all of 127/8 is
valid so the Spamhaus codes won't be recognised:
https://git.exim.org/exim.git/commitdiff/cebf4027931177cc70106a84e19705f2085a09f5

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

Re: [mailop] Weird 'tempfail too many recipients' bug/incompatibility EXIM => Postfix?

[Simon Arlott via mailop]

On 2021-02-04 19:04, Graeme Fowler via mailop wrote:
On 4 Feb 2021, at 15:26, Benoît Panizzon via mailop  
wrote:
But I also think EXIM is screwing up the order of the received 
messages

in pipelining mode.


There is a bug introduced in Exim 4.94 when using pipelining and some 
recipients are deferred with 452 but there are non-deferred recipients 
after those: https://bugs.exim.org/show_bug.cgi?id=2693


Disabling pipelining in the SMTP transport avoids this issue.

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

Re: [mailop] Weird 'tempfail too many recipients' bug/incompatibility EXIM => Postfix?

[Simon Arlott via mailop]

On 04/02/2021 10:37, Benoît Panizzon via mailop wrote:
> So how to reproduce... The focus is on the MAIL FROM / RCPT TO lines in
> the SMTP dialogue.

Can you now reproduce this with your own installation of Exim and
with addresses that do not need to be redacted?

It's not going to be practical to identify and fix a bug if no-one knows
the version of Exim or the actual data being used.

For example, are all of the recipients in the same domain? Are the
RCPT commands in any specific [sorted] order?

I don't expect there to be a bug in Exim here. It is not difficult to
send 6 RCPT commands and then process 6 RCPT responses in the same
order.

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

Re: [mailop] subscription bombing prevention best practices

[Simon Arlott via mailop]

On 21/01/2021 09:15, Stefano Bagnara via mailop wrote:
> Of course a DNS method to let domains opt-in to such a generic system would
> be cool, but unless we think 100% of domains will adopt openid we'll still
> have the subscription bombing issue around, for every form not using this
> "new method" and every recient on a domain not using this method.

If you had enough adoption (e.g. from the big mailbox providers) then it
would be viable to require support for from operators of mailing lists
(note: support for the process, not necessarily requiring recipient
domains to use it) and anyone who receives a flood of subscription
requests will then be persuaded to implement it.

> So I like your proposal, but I was looking for best practices to deal with
> what happens now: forms being abused to fill email inboxes of innocent
> victims.

I don't think there is any other option. You have no way of knowing who
else is subscribing the same user, through wildcard addresses or
otherwise.

Even if you had collaboration between major email senders to share this
information there would still be many more independent mailing list
installations.

The next step in the denial of service process would be to ensure that
you can't subscribe to anything because your address is permanently on
the "receiving a flood of subscription requests" database.

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

Re: [mailop] subscription bombing prevention best practices

[Simon Arlott via mailop]

On 20/01/2021 10:50, Stefano Bagnara via mailop wrote:
> I'm looking for brainstorming and updated industry "standards" from people
> handling outgoing SMTP services or ESP exporting APIs to "request
> subscriptions" (confirmed opt-in).

How about a web-based process to confirm opt-in?

Domains could opt into it by a DNS TXT record providing the URL of a
confirmation service. This would function something like OpenID and the
result would be a confirmation or rejection of the subscription.

Some kind of time-limited attestation URL could be used to allow the
result to be relayed elsewhere for further processing.

Potential issues with this include widespread phishing (because the user
won't check they're on their provider's website) and providers gaining
detailed insight into mailing list subscriptions (but they can imply
those already by the email received).

Optimisations could include the provider approving some subscriptions
without user interaction if the intent is solely to prevent subscription
bombing (but it would be nice to have true confirmed opt-in processes).

It would take time to be adopted but it would put an end to "enter your
email address" forms accepting anything that is entered.

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

Re: [mailop] Gmail & SPF=none & Adobe campaign

[Simon Arlott via mailop]

On 14/01/2021 18:53, Pascal HOARAU via mailop wrote:
> From https://toolbox.googleapps.com/apps/checkmx/check
> 
> The SPF string can not be parsed, do you have any typos in it?
> Decision  permanent error in processing
> Explanation   SPF Permanent Error: redirect domain has no SPF record: 
> __spf.campaign.adobe.com
> Recordv=spf1 redirect=__spf.campaign.adobe.com
> 
> I don't understand !

I can reproduce that on my domain and it happens every time.

Testing __spf.campaign.adobe.com itself works, "include:" works, but
"redirect=" does not.

Also... that tool is making queries to authoritative nameservers with
the RD flag set, which it should not do.

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

Re: [mailop] Gmail & SPF=none & Adobe campaign

[Simon Arlott via mailop]

On 14/01/2021 14:27, Pascal HOARAU via mailop wrote:
> __spf.campaign.adobe.com. 120   IN  TXT "v=spf1 ip4:66.117.16.0/22 
> ip4:192.243.225.0/24 ip4:192.243.228.0/24 ip4:192.243.229.0/24 
> ip4:208.67.42.0/24 ip4:192.243.244.0/22 ip4:63.140.47.0/24 
> ip4:185.34.188.0/24 ip4:130.248.192.0/21 ip4:62.210.128.32/27 
> ip4:62.210.161.0/24 ip" "4:66.235.130.0/24 ip4:172.82.224.0/22 
> ip4:192.243.230.0/23 ip4:192.243.232.0/23 ip4:185.15.48.0/22 
> ip4:185.15.49.0/24 ip4:62.210.194.0/24 ip4:172.82.229.0/24 
> ip4:172.82.230.0/23 ip4:52.51.29.0/24 ip4:52.50.57.0/24 ip4:52.209.104.0/24 
> ip4:172.82.242.0/23 " "ip4:195.154.155.0/24 ip4:172.82.196.0/23 
> ip4:130.117.8.0/24 ip4:172.82.216.0/23 ip4:172.82.232.0/23 
> ip4:207.211.34.0/24 ip4:173.212.230.0/24 ip4:172.82.196.0/24 
> ip4:172.82.218.0/23 ip4:192.243.255.0/24 ip4:172.82.197.0/24 " 
> "ip4:172.82.217.0/24 ip4:185.15.50.0/24 ip4:172.82.236.0/22 
> ip4:130.248.176.0/20 ip4:172.82.243.0/24  ip4:130.248.136.0/23 
> ip4:130.248.152.0/22 ip4:172.82.220.0/22 ip4:130.248.139.0/24 
> ip4:130.248.140.0/23 " "ip4:130.248.208.0/21 ip4:172.82.241.144/32 
> ip4:130.248.204.0/22 ip4:130.248.216.0/23 ip4:130.248.158.0/24 
> ip4:130.248.202.0/23 ip4:130.248.224.0/24 ip4:63.140.40.0/23 
> ip4:63.140.43.0/24 ip4:130.248.128.0/23 ip4:130.248.164.0/22 
> ip4:130.248.238.0/24 ~all"

Google accepts this when I test it and I can also break the string in
the middle of an IP address.

I suspect the original domain is missing the TXT record on one or more
nameservers.

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

Re: [mailop] Need help with Microsoft S3150 and Yahoo TSS09 on recently transferred /24

[Simon Arlott via mailop]

Thanks for helping me with Yahoo, Lili.


On 31/07/2020 23:16, Chris Woods via mailop wrote:
> Incidentally, are you also able to try sending via IPv6 or only IPv4?

Neither of those providers have any IPv6 addresses for incoming
messages.

If any server for the domain has an IPv4 addresses, I don't make any
attempts using IPv6. This is largely to satisfy Google who have decided
that any kind of temporary DNS resolution issue for an IPv6 address
should result in a permanent error for the message.


On 01/08/2020 01:23, Michael Wise via mailop wrote:
> And for "HotMail", we would suggest going ... here.
> 
> What to do in that case can be found by searching the archives of this 
> ML. 😃

2020-07-10 SRX1504740980ID "Not qualified for mitigation"
2020-07-25 SRX1505670381ID "Not qualified for mitigation"
2020-08-02 SRX1506075916ID "Not qualified for mitigation"

I reply every time but never get anything else back.

-- 
Simon Arlott

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Need help with Microsoft S3150 and Yahoo TSS09 on recently transferred /24

[Simon Arlott via mailop]

Could someone from Microsoft and Yahoo help me resolve this issue with
209.16.157.42?

550 5.7.1 Unfortunately, messages from [209.16.157.42] weren't sent.
Please contact your Internet service provider since part of their
network is on our block list (S3150). You can also refer your provider
to http://mail.live.com/mail/troubleshooting.aspx#errors.
[AM5EUR02FT039.eop-EUR02.prod.protection.outlook.com]

553 5.7.2 [TSS09] All messages from 209.16.157.42 will be permanently
deferred; Retrying will NOT succeed. See
https://help.yahoo.com/kb/postmaster/SLN3436.html


The /24 network that the server is located in was purchased and moved
from ARIN to RIPE on 2020-06-30 [1]. (Our new ISP was unable to supply
more than 1 IPv4 address.)

The network hasn't been routed since 209.16.128.0/18 was advertised
until 2017-12 by the original legacy IP holder [2].

None of the IPs are on any DNS lists, so I can only assume there's some
kind of "newly announced" restriction or "route origin changed" check
that is preventing it from being allowed to send any email.


Microsoft was previously returning 4xx for 47 hours and then either
disappearing the email or delivering it to Spam but now just returns
5xx. Yahoo has always returned 5xx. Google are accepting messages.

The advice in the URLs in the error messages are meaningless because I
have no "outgoing emails" to review if they're never accepted. This
domain has SPF/DKIM/DMARC configured and the network is registered with
SNDS/JMRP.

I don't get anything but automated or template responses from Microsoft
or Yahoo support.


I have 5 users in total (including myself) and don't operate any mailing
lists. This issue is frustrating when emails to Sky/AOL/Hotmail/etc. all
bounce.





1. Aside from the creation date in RIPE WHOIS, here's the RIPE list of
IPv4 transfers for proof that this was transferred (and when):

https://www-static.ripe.net/dynamic/table-of-transfers/inter-rir/incoming-ipv4.json

{"transferred_blocks":"209.16.157.0/24", "date":"30/06/2020",
"transferType":"POLICY", "from_rir":"ARIN",
"to_organisation":"Edinburgh Hacklab Ltd"}

2. https://stat.ripe.net/209.16.157.0%2F24#tabId=routing

-- 
Simon Arlott

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] weird bounce behavior

[Simon Arlott via mailop]

On 18/03/2020 22:18, Grant Taylor via mailop wrote:
> On 3/18/20 3:10 PM, Miles Fidelman via mailop wrote:
> I agree that the report was sub-optimal at best.  Especially considering 
> that your server (207.154.13.48) did NOT send an email purporting to be 
> from googlegroups.com.

If you look at the Received: headers, Google connected over IPv6 so
207.154.13.48 is the first recognisable origin IP for any process that
doesn't understand that IPv6 exists.

-- 
Simon Arlott

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop