Re: [mailop] Noticed Google now suggests changing envelope sender for forwarding

[Aaron Richton via mailop]

On Thu, 1 Jun 2023, Robert L Mathews via mailop wrote:

Maybe other people have noticed and discussed this and I'm just behind 
the times, but for more than a decade, Google specifically said:


"Avoid changing the envelope sender when forwarding email to Gmail."


You're kind of proving the point with the archive.org link -- but you're 
not behind the times per se, the problem was the system behavior changed 
without the documentation changing.


(The other issue is that one of the common 5xx texts in this scenario 
references "PTR records," as Jarland's thread last month discussed -- 
which sadly gets you looking in the wrong direction.)


Nice to see docs that match reality, and it's also interesting to see the 
hat tip toward ARC for forwarding...


(You can see this as recently as last November at 
.)


Because of that, we didn't do it. But I noticed that the current page at 
 now says the exact opposite:


"Change the envelope sender to reference your forwarding domain."

So I guess it's time to add SRS rewriting for Gmail addresses...!

--
Robert L Mathews
___
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] Opinions? Email Abuse over TOR Network? (spamtraps)

[Aaron Richton via mailop]

On Tue, 18 Feb 2020, Matt Palmer via mailop wrote:

great, but it's an unfortunate side-effect of providing anonymity. 
Frankly, if you were feeling up to the job of scripting it, 
pre-emptively putting all Tor exit nodes which allow connections to port 
25 in your RBL would not be a bad idea (exit nodes and their exit 
policies are publicly available, so you could scrape the list and 
maintain RBL entries based on it).


Asking tcp/25 only might be more complex, but there's a starting point:

https://www.dan.me.uk/dnsbl

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

Re: [mailop] postfix postmaster wanted - howto instantly bounce when remote site refuses TLS

[Aaron Richton]

On Mon, 10 Sep 2018, Stefan Bauer wrote:

i know this is not postfix mailing list - but postfix list said - its 
not supported yet - so hoping for a trick from postmasters ;)


Huh, that's curious, unless they mean "you need Postfix 3.0" perhaps? But 
anyway...


Sep  9 23:40:35 postfix/smtp[29230]: 988B7809D4: to=, 
relay=mail.b.c[1.2.3.4]:25, delay=18342, delays=18342/0.03/0.1/0, 
dsn=4.7.4, status=deferred (TLS is required, but was not offered by host 
mail.b.c[1.2.3.4])


This is literaly the example for *_delivery_status_filter in postconf(5) 
man page, a feature "originally implemented for sites that want to turn 
certain soft delivery errors into hard delivery errors."


Check the Postfix 3.x RELEASE_NOTES under "Major changes - delivery status 
notifications" for full discussion/examples.___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] DMARC p=quarantine pct=0

[Aaron Richton]

On Mon, 9 Apr 2018, Jesse Thompson wrote:

2) When people start seeing headers rewritten we can use that as an 
attention mechanism to make people aware of email authentication as a 
concept, and convince people to tackle the other indirect mail flow 
issues.


What / where are you intending to rewrite headers?

Are you hoping that seeing "Hmm, I see From: , maybe I 
should be doing that too?" will encourage non-compliant sites to do the 
same, as a second-order effect? (Free advertising?)


And/or are you intending to actively try to "fix" alignment with rewrites 
within your services? (Would that be better than the violation of least 
surprise principle?)


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

Re: [mailop] Microsoft IPs automatically unsubscribing recipients?

[Aaron Richton]

On Tue, 27 Feb 2018, Jesse Thompson wrote:

Then, I guess, why not POST (or GET) the unsubscribe link anyway?  If 
the user indicated a desire for a facilitated unsubscribe, why not try?


The major issue in this situation is that the users *didn't* indicate 
desire.


Moving forward, when there's actual user involvement...having mail readers 
take indirect action might be OK as a "privacy guard" proxy, subject to 
standard "you're intentionally introducing a MitM" caveats.


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

Re: [mailop] Microsoft IPs automatically unsubscribing recipients?

[Aaron Richton]

On Fri, 23 Feb 2018, David Carriger wrote:


I've just received an interesting escalation from our support team. We have a 
customer sending mail to recipients at the following domains:

[...]
With the exception of Rutgers, these are all hosted on Office 365. Once 
the mail has delivered, I'm seeing all of the links inside the email hit 
within a span of time varying between 1-10 seconds. For example, here's 
an unsubscribe in our database for @mssu.edu:


And although the Rutgers MX listed aren't (.*)outlook.com, the underlying 
mail stores (especially within the domains you listed) are frequently, but 
not always, O365. If you have any recipients at e.g. sas.rutgers.edu 
that's IN MX 10 sas-rutgers-edu.mail.protection.outlook.com. and I'd 
expect you to find similar behavior.


Are we the only ones experiencing this, or are others seeing this as 
well?


Nope, we're seeing it as well, can easily replicate it, have a case open 
with MS about it, and contacted one particular ESP who apparently worked 
with MS on some sort of workaround that, in light of your message, may 
have been specialized to that explicit ESP. And this isn't 0day; I think I 
first heard rumors along these lines at least 3 weeks ago.


I'll toss your details over to the O365 side of the postmaster team here 
to append to our case...thanks for the additional data points, I suppose.


-Aaron Richton
Rutgers University, Office of Information Technology___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] IMAP to IMAP

[Aaron Richton]

On Fri, 15 Dec 2017, John Levine wrote:

I have a client who's moving from one mail system to another, and has 
quite a lot of mail on the old system's IMAP server that they want to 
take with them.


While I can certainly write a python script that enumerates the 
mailboxes and copies stuff, I was hoping someone else already had.


Take a look at https://wiki2.dovecot.org/Tools/Doveadm/Sync -- pretty sure 
you can set up imapc to imapc, although I've never done it personally.


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

Re: [mailop] Outlook.com bad behaviour (blocked by fail2ban?)

[Aaron Richton]

On Mon, 25 Sep 2017, MRob wrote:

The bounce senders are getting is not helpful, makes it look like an 
internal Microsoft problem (below).



Generating server: MMXP123MB1200.GBRP123.PROD.OUTLOOK.COM
Receiving server: MMXP123MB1200.GBRP123.PROD.OUTLOOK.COM


Yeah. It would be great to be able to translate their internal hostnames 
into something useful.


Is there a place I can get a list of their outgoing SMTP servers so I 
can do the tedious job of seeing if they are in our firewall block list 
(and see if the fail2ban log element is still there)?


Somebody replied with the outlook.com servers. But I have a feeling these 
are probably from the EOP side of the house, especially for values of 
"example.com" not equal to "outlook.com." Try


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

for more IP ranges.

Finally, Microsoft's internal hostnames aren't helping, but this seems 
needlessly difficult with the fail2ban "firewall block" implementation. 
Switch that to a twist (preferably separate from your SMTP server 
software) outputting "421 fail2ban says I'm shutting down now, so far as 
[$IP] is concerned" and you'd get meaningful-to-you text AND the remote IP 
in the resultant DSNs.


(Or it's not fail2ban after all. Which also would be clearer if you 
generated meaningful protocol text instead of blackholing.)


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

Re: [mailop] IMAP load and iOS 11 release

[Aaron Richton]

On Wed, 20 Sep 2017, Kirk MacDonald wrote:
[...]

lift in IMAP traffic/load yesterday, roughly coinciding with the iOS 11


iOS 11 has some serious interop issues with Exchange ActiveSync, e.g.

https://support.apple.com/en-us/HT208136
https://forums.developer.apple.com/thread/79446

Perhaps there are users that would give up on EAS and move to IMAP (if you 
support both) as a workaround? Or maybe they got multiple mail protocols 
wrong this time around...


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

Re: [mailop] myapple.com MX points to 127.0.0.6

[Aaron Richton]

On Sun, 3 Sep 2017, Peer Heinlein wrote:


Somebody here from Apple?

They're sending mails from @myapple.com which has MX-Records pointing to


If the @mac.com / iCloud teams are the same as @myapple.com (or perhaps 
they have a referral?), you can try icloudad...@apple.com.



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

Re: [mailop] Curious: Strange NDRs from gmail.

[Aaron Richton]

On Thu, 23 Feb 2017, Luke Martinez via mailop wrote:


Some G Suite domains are returning this response to us long after the messages 
are delivered. More of a curiosity than anything else. Wondering if anyone has 
seen this behavior before.

[...]

Reporting-MTA: dns; googlemail.com
Received-From-MTA: dns; 
bounces+2323606-70a0-ccrawford=spotsylvania.k12.va...@sendmail.joezooapp.com
Arrival-Date: Wed, 15 Feb 2017 05:45:07 -0800 (PST)
X-Original-Message-ID: 

Final-Recipient: rfc822; ccrawf...@spotsylvania.k12.va.us
Action: failed
Status: 4.4.2
Remote-MTA: dns; 205.174.120.102 (205.174.120.102, the server for the domain.)
Diagnostic-Code: smtp; read error: generic::failed_precondition: read error 
(0): error
Last-Attempt-Date: Wed, 22 Feb 2017 09:37:18 -0800 (PST)

[...]

It sounds like this is a generic "they didn't talk the protocol I wanted" 
from the G Suite MTA (which presumably is trying to forward/cc/etc. from 
b...@google.hosted.us --> onpremises@[205.174.120.102] living under 
spotsylvania.k12.va.us.)


Seeing that a connection to 205.174.120.102:25 smells like a PIX, it's 
quite likely that Google is getting some awful Ciscoized SMTP, which may 
indeed not be the protocol they want.


If you have available bandwidth to Fix The World, pinging 
spotsylvania.k12.va.us to check their SMTP logs (especially at any 
middleboxes in the way) might be enlightening. Or in the event my crystal 
ball is fully functional today just point them to:


https://community.spiceworks.com/how_to/42809-cisco-asa-disable-smtp-fixup-in-asdm

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

Re: [mailop] Issues Receiving from MSN/Hotmail

[Aaron Richton]

On Thu, 1 Sep 2016, Dave Brockman wrote:


For Example:

UmVwb3J0aW5nLU1UQTogZG5zO0JBWTAwNC1PTUMzUzE1LmhvdG1haWwuY29tDQpSZWNlaXZlZC1G
cm9tLU1UQTogZG5zO05BTTAyLUNZMS1vYmUub3V0Ym91bmQucHJvdGVjdGlvbi5vdXRsb29rLmNv
bQ0KQXJyaXZhbC1EYXRlOiBXZWQsIDMxIEF1ZyAyMDE2IDA2OjMwOjQ4IC0wNzAwDQoNCkZpbmFs
LVJlY2lwaWVudDogcmZjODIyO1RNYW5yZXNhQHdkZWYuY29tDQpBY3Rpb246IGRlbGF5ZWQNClN0
YXR1czogNC40LjcNCldpbGwtUmV0cnktVW50aWw6IEZyaSwgMiBTZXAgMjAxNiAwNjozMDo1NCAt
MDcwMA0KDQpGaW5hbC1SZWNpcGllbnQ6IHJmYzgyMjtSTWNDbGFpbkB3ZGVmLmNvbQ0KQWN0aW9u
OiBkZWxheWVkDQpTdGF0dXM6IDQuNC43DQpXaWxsLVJldHJ5LVVudGlsOiBGcmksIDIgU2VwIDIw
MTYgMDY6MzA6NTQgLTA3MDANCg==


That's just base64, use e.g. openssl enc -d -base64 which gives:

Reporting-MTA: dns;BAY004-OMC3S15.hotmail.com
Received-From-MTA: dns;NAM02-CY1-obe.outbound.protection.outlook.com
Arrival-Date: Wed, 31 Aug 2016 06:30:48 -0700

Final-Recipient: rfc822;tmanr...@wdef.com
Action: delayed
Status: 4.4.7
Will-Retry-Until: Fri, 2 Sep 2016 06:30:54 -0700

Final-Recipient: rfc822;rmccl...@wdef.com
Action: delayed
Status: 4.4.7
Will-Retry-Until: Fri, 2 Sep 2016 06:30:54 -0700

(somehow I'd guess that you are aware of the delays. Perhaps the final 
permfail will have more details, if you're lucky? Or perhaps network 
investigation looking critically at


$ dig BAY004-OMC3S15.hotmail.com. +short
65.54.190.153

would help. I can ping that IP -- can you?)

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