Re: [mailop] Google Mail rejects forwarded email despite `~all` in SPF
On 4/22/24 09:16, Matus UHLAR - fantomas via mailop wrote: I'm afraid this is very long term solution - the recipient needs to trust your ARC signatures. IMHO the "the recipient needs to trust your ARC signature" is ARC's Achilles' heel. I have not seen any way to get around this -- what I call -- priming problem. -- Grant. . . . smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Reason for being listed at Spamhaus CSS and XBL unclear
On 4/19/24 8:31 AM, Jaroslaw Rafa via mailop wrote: I started to monitor all outgoing traffic from my server towards his IP address with tcpdump, then I put up firewall rules that blocked (with logging) all outgoing traffic to his IP other than to port 25. Obviously no packets were going out of my server towards his, yet the guy insisted that strange traffic from my address is still incoming. Indeed, his firewall kept blocking me and he kept unblocking me manually . I wonder if TCP connections were being fully established. Is there a chance that someone was spoofing your IP? Could he produce packet captures for you to analyze? Is there a possibility of a compromised CPE that's hijacking the IP? -- Grant. . . . unix || die ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Off-Topic - VMWare ESXI 7.0
On 4/17/24 2:07 PM, Grant Taylor via mailop wrote: Research clustered file systems and / or clustered LVM. What you find should have SIGNIFICANT overlap with and much of it will probably be possible in Proxmox. Here's some additional reading that might be of interest. TL;DR: Glowsome has been doing the very type of things I was suggesting should be possible. Multiple hosts concurrently accessing shared storage block storage; GFS2 + CLVM + DLM shared storage. Link - Shared Storage in proxmox - GFS2 | Proxmox Support Forum - https://forum.proxmox.com/threads/shared-storage-in-proxmox-gfs2.121604/ Link - [TUTORIAL] - PVE 7.x Cluster Setup of shared LVM/LV with MSA2040 SAS [partial howto] | Proxmox Support Forum - https://forum.proxmox.com/threads/pve-7-x-cluster-setup-of-shared-lvm-lv-with-msa2040-sas-partial-howto.57536/ -- Grant. . . . unix || die ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Off-Topic - VMWare ESXI 7.0
On 4/16/24 23:42, Bruno Flückiger via mailop wrote: Proxmox does not support the current architecture I have at work: clusters of hosts served by a central storage system connected to the hosts by FC SAN. I run few huge volumes on the storage that are shared among the cluster hosts. As I have seen this architecture in many companies I think I can the lack of support for it a shortcoming. This surprises me. The Proxmox VE Storage page implies that it's possible. Link - Storage - Proxmox VE - https://pve.proxmox.com/wiki/Storage The last time I looked at Proxmox (multiple years now) it was just a role specific distribution of Linux. I know for a fact that Linux supports shared storage, I've done it multiple times with multiple different clustered file systems. I would be flabbergasted if you weren't able to add the small number of pieces needed on top of Proxmox to make this work. You'll need a distributed lock manager and a cluster aware file system. There are multiple options for Linux. Research clustered file systems and / or clustered LVM. What you find should have SIGNIFICANT overlap with and much of it will probably be possible in Proxmox. -- Grant. . . . smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Invitation to contribute to a survey about MTA-STS
On 4/16/24 12:36 PM, L. Mark Stone via mailop wrote: If you were really from Virginia Tech or the Max Planck Institute, you would have used a university email address to post, instead of a Gmail account. I don't recognize ishtiaq ashiq, but I do recognize Tijay Chung who sent the same message and same URL to NANOG. Makes you look like a bad actor trying to do data gathering IMHO. I agree that it's a little suspicious. But given interactions with Tijay C. and the fact that the same message and same URL did come from a VT email address, I'm fairly confident that this is a legitimate survey executed slightly less professionally than one might hope. -- Grant. . . . unix || die ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Are there other comparable services like spamcop.net / spamhaus.org?
On 4/3/24 12:55, John R Levine via mailop wrote:
Huh. Nobody tells me nothin'.
Don't feel too bad. I found out after you.
${READ_WHILE_DRINKING_MORNING_COFFEE}++
--
Grant. . . .
smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] mailop and DKIM signatures
On 3/21/24 5:47 AM, Alessandro Vesely via mailop wrote: Mailing lists modify messages in a de-facto standard way. It is possible to automatically undo such changes and verify the original signature, if it is left intact. I feel like this is a "can vs should" type problem. There are a LOT of things that we can do. But the question is should we do them or not. Van Halen and brown M come to mind, wherein when one thing is not done correctly, what else is not done correctly? How much should we accommodate? My personal opinion is to fail hard and fast so that someone can detect the failure and correct it rather than fail soft and slowly block things over time when the change will be lost to time. Returning a 51x error when someone sends an email to an old address even when we know the new address they wanted to use comes to mind. -- Grant. . . . unix || die ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Contact of postmaster for hostedemail.com domains
On 2/26/24 10:43 AM, Jaroslaw Rafa via mailop wrote: At least that's what I see all over from my experience. My experience is similar. However my opinion is that this is the wrong thing to do. Like so many things, email is governed by checks and balances (of sorts). If enough people complain about not being able to receive something, then hopefully the provider will get the idea that something is wrong on the receiving side. We can't cross the "enough" people complaining if nobody complains. This is also what I broadly call "gentle push back" or "back pressure". There seems to be a germane phrase; ...if you don't stand for something you'll fall for anything... IMHO it's (past) time to stand up and request (demand) that people do better. -- Grant. . . . unix || die ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] One click unsubscribe in mailing list messages
On 2/24/24 11:23, Anne P. Mitchell, Esq. via mailop wrote: Not to mention that Federal law requires a one-step unsubscribe method. My understanding is that the requirement is scoped to the 1st party recipient of messages subject to the requirement. I bet that the same requirement doesn't extend to the 3rd party recipient that the 2nd party forwarded the 1st party's message to. -- Grant. . . . smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM signed with parent domain
On 1/26/24 16:06, Gellner, Oliver via mailop wrote: Independent of this I wouldn’t use r...@hostname.example.org as a sender address to external recipients. This doesn’t look professional, I'll agree that sending from root@ is not best practice. But I don't know if it's unprofessional per se. makes replying to those emails impossible I question the veracity of that. Including a Reply-To: and / or an MX for to a reachable mail server that is a smart host that knows how to deliver email to a host that's not directly reachable seems viable to me. and in case hostname.example.org doesn’t have a public IP address it might also increase the risk that those messages are treated as spam or rejected, because they are coming from an unresolvable domain. I question the veracity of anything that balks at a valid MX via smart host for a that is in and of itself unreachble. After all, what is the effective difference in a host that's in a private network using a smart host for outbound and inbound mail and a host usually fully reachable / on the Internet that happens to be offline do to an extended power outage caused by a winter storm? I think that there /should/ be /a/ system that is willing to handle mail for the system, but I don't agree that it needs to be /the/ /system/ /itself/. Many MTAs provide ways to rewrite sender addresses, Agreed. What I don't agree with is the actual need -> requirement to do so. Sure, masquerading sending addresses is a useful tool in the toolbox. But it's not the only tool in the toolbox. This will resolve all questions about subdomains once and for all and doesn’t even require any changes to the applications which create the messages. I question the veracity of that for multiple reasons. Doing this on each source system will likely be a lossy operation and could have serious negative impact on systems inside the organization that would otherwise utilize the masqueraded source address. -- Obviously I think that there are ways to make this email work even if the internal system isn't reachable from the Internet. I have other similar / more obtuse qualms with the idea that masquerading will resolve all questions about subdomains period, much less once and for all. -- Grant. . . . smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is Google jumping the gun for SPF / DKIM requirement?
On 1/25/24 01:12, Marco Moock via mailop wrote: Both don't pass here, so fix SPF and try again. I would hope that redacted.example.net and 192.0.2.1 fail. redacted.example.net is part of one of the (few) names reserved for documentation; specifically example.net. Likewise 192.0.2.1 is part of one of the (few) subnets reserved for documentation. That's why I chose them for my email. The actual value of the non-existent SPF (TXT) record for the documentation domain is orthogonal to Google enforcing things ahead of the published February 1st time frame. -- Grant. . . . smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is Google jumping the gun for SPF / DKIM requirement?
On 1/24/24 22:12, Alexander Neilson via mailop wrote: Was this over v6? Nope. Hence the Test-Net-1 IPv4 address. This was on a friends system and said friend is an IPv4 stalwart in that he sees no benefit for the additional time and overhead for IPv6 for his small business that has sufficient IPv4 space. -- I've tried to get him to use IPv6, even a tunnel from H.E. and he has declined many times. Haven’t they required this on v6 for a while so this may just be that. Yes. -- Grant. . . . smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is Google jumping the gun for SPF / DKIM requirement?
On 1/24/24 22:09, Russell Clemings via mailop wrote: I saw it a couple of weeks ago. I wonder if what they meant by February 1st is that's when they would hit the 100% requirement and they are doing the 1% / 5% / 10% / 50% / 80% / 100% ramp up now. Similar, a server reporting in via cron. ACK It was pretty easy to fix once I realized that I needed a separate SPF for each subdomain. Ya. I'll end up creating very basic SPF records for each host. I guess I know what I'm working on over the next few days. I had thought the record for the parent domain would cover it, but I guess I was the only person who thought that. I used to think that a long time ago. But I don't remember when I stopped or what I ran into that caused me to stop. -- Grant. . . . smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Is Google jumping the gun for SPF / DKIM requirement?
Hi, I knew that Google was going to start requiring SPF or DKIM (in addition to other sender guidelines [1]. But I thought they were starting February 1st, per their own sender guidelines. I saw a bounce from a system (cron job output) trying to send directly to gmail.com, no forwarding involved. <<< 550-5.7.26 This mail has been blocked because the sender is unauthenticated. <<< 550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM. <<< 550-5.7.26 <<< 550-5.7.26 Authentication results: <<< 550-5.7.26 DKIM = did not pass <<< 550-5.7.26 SPF [redacted.example.net] with ip: [192.0.2.1] = did not pass <<< 550-5.7.26 <<< 550-5.7.26 For instructions on setting up authentication, go to <<< 550 5.7.26 https://support.google.com/mail/answer/81126#authentication d20-20020a05683025d400b006dc5452f468si4641458otu.190 - gsmtp 554 5.0.0 Service unavailable Am I missing something obvious or has Google started implementing this new requirement ahead of their published schedule? The only surprise to me is that this happened ~8 days before the published February 1st date. [1] https://support.google.com/a/answer/81126#zippy=%2Crequirements-for-all-senders -- Grant. . . . smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] seeking a spamtrap milter
On 1/23/24 1:40 PM, Michael W. Lucas via mailop wrote: Hi folks, Hi, I have domains that should never receive mail. I'd like a milter that looks for mail to those domains and feeds the IP of the sender to an outside program. I'm interpreting your statement to mean that you are talking about email inbound to local domains that you own / manage / etc. and not outbound to remote domains that you want to never send to. I'm not sure if you need this to happen during the SMTP transaction, milters playground, or just want a near real time processing where a short (O(seconds)) delay would be okay. If a short delay is okay, I would wonder if standard SYSLOG might suffice. I assume that your MTA logs enough data that you could get a list of IPs that send to -- what I'm going to call -- protected recipient domains. I'm going to further assume that you could tune your SYSLOG implementation to send just the facility and level that have the interesting log files to a program for parsing and extracting the IPs sending to the protected domains. I take it for granted that if you the IP in a variable that you can feed it where you want to do whatever you want. Surely someone wrote this spamtrap software? Or does everyone just parse the log? "spamtrap" seems like a much broader term than what I think you are after. I have seen many spam trap configurations, but I'm not aware of them doing what you are after. -- Grant. . . . unix || die ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Authentication Bounces by Gmail
On 9/13/23 12:07 PM, Emanuel Schorsch via mailop wrote: ARC trust is not just a binary. There are also ways that the ARC headers can be used even if the ARC sealer is not 100% trusted. Thank you for making that comment. That helps partially elide what I consider to be a priming problem with ARC. I'll re-consider my use of ARC. -- I had it for a while, but stopped for various reasons, most of which revolved around my perception of the priming problem. -- Grant. . . . unix || die ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Authentication Bounces by Gmail
On 9/13/23 6:04 AM, Jaroslaw Rafa via mailop wrote: If someone forwards mail to his/her account, they obviously know *from where* they forward mail. Aside: I originally thought you were referring to which senders would be sending messages that would get forwarded. But after reading you next statement, I realized that you were referring to the (intermediate) system(s) doing the forwarding. So allow your user to specify a list of IP addresses of servers from where the mail is forwarded. I don't buy it. Even if people did know the IP address of their (former) forwarding inbox provider server(s) at one point in time, things change. Often this change is unbeknownst to the end users. Maybe it's simply a change within the providers network. Maybe the provider outsourced to a 3rd party. Maybe the provider insourced from a 3rd party. Maintaining this list is going to be untenable for most end users. Email from these servers to that particular user will be exempt from SPF/DKIM/DMARC checks. I see that as more complicated than likely desired and potential to be abused. Especially with the complication of multiple recipients per message, one of whom might have more such allow listing. (If the user doesn't know the IP address from which the mail is sent, he/she can probably easily find someone who knows, at the site from where the forward originates.) That's an example of trouble / needing help to do what you suggest from the word go. -- Grant. . . . unix || die ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Any old-school sendmail types here good with the m4?
On 8/30/23 2:06 AM, Dan Mahoney (Gushi) via mailop wrote: Grant, I appreciate the time it must have taken you to write this long callout about how I surely must be "doing it wrong". :-) I've been running mail for 20 years now. *nod* I think I've been running Sendmail roughly the same amount of time. '00 plus or minus depending on how you count things. This is the first occurence of this problem I don't think that "1st time in 20 years" is as appropriate as you might want it to be, seeing as how we're talking about a behavior that I understand SpamHaus to have changed in the last 18 months or so. (and again, only because the local caching resolver that my new host configured...was not recursive). That ... seems problematic. The mix of solutions I've had in play has served me reasonably well. My SA config checks many RBLs. But the volume and load of mails I scan with SA would be easily tenfold if not for SH. To each their own. I still stand by not rejecting out of hand /just/ /because/ an IP is listed in an RBL. I've also discovered (over on comp.mail.sendmail) that SpamHaus's recommended, documented use of the enhdnsbl feature DOES NOT WORK, which I suspect is a bug in how the rules are transformed from .mc syntax to .cf syntax. I can't prove or disprove that. But it sounds like something else is wrong. M4 has been converting macro config (.mc) syntax rules to config file (.cf) syntax rules for more than two decades. There is entirely a possibility that something has happened that has caused the .mc to not behave as desired. I'm thinking something like smart quotes, or CR/LF issues, or similarly almost certainly wouldn't happen if lines were re-typed by hand. (Assuming no typos.) In order to debug the m4 not doing the right things, I need to understand the raw .cf, which brings me back to my original tongue-in-cheek suggestion of greater enlightenment. I interpret that a little bit differently. It sounds to me like you are saying that the underlying .cf syntax -- generated from the .mc syntax -- is broken. Once you have the fully functional .cf syntax, you can then tackle why the .mc syntax isn't generating the desired .cf syntax. If you have valid .cf syntax and .mc syntax that isn't quite generating said .cf syntax, please share it and I'll take a look. A lot of M4 work can be "how can I generate this result" and working backwards to "this will generate that". -- Grant. . . . unix || die ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Any old-school sendmail types here good with the m4?
On 8/23/23 4:29 AM, Dan Mahoney (Gushi) via mailop wrote: I just posted this over on comp.mail.sendmail, but the gist of it is: Sometimes spamhaus hands off a query to their dnsbls of 127.255.255.255 or 127.255.255.254, indicating that you're being rate limited. With all due respect, this seems to be more of a /configuration/ (of Sendmail) problem than it is a Sendmail or M4 problem. First, multiple RBLs use different A(AAA) values to indicate different things and have been doing so for years. You can no longer assume that just because you get an A(AAA) response that an IP is listed. The different values indicate different things. Some of which can be rate limiting, others can be allow (white) listing. I suggest that you re-consider how you are using the RBL. Second, as others have pointed out, Sendmail has other RBL interfaces / implementations. Perhaps consider re-configuring your system to use one of the other methods and / or parameters which behave more to your liking. Third, you can potentially solve this at a DNS level with something like BIND's Response Policy Zone wherein you can cause BIND to return NXDOMAIN in the event that you receive a 127.255.255.255 or 127.255.255.254 so that your existing Sendmail configuration works as you desire without changing Sendmail. This is bad, as when you get that, you start rejecting mail. Again, this is somewhat like saying that it's bad that a soldering iron burns you when you are holding it by the wrong end. -- Sort of an extreme, but I hope it demonstrates my point. I recently discovered this on my personal system as my OS's built in resolver was silently forwarding to 1.1.1.1/8.8.8.8. Ya That's another kettle of fish. Fourth, I believe that SpamHaus made a change within the last 12-18 months where they started rate limiting open resolvers like 1.1.1.1, 8.8.8.8, 9.9.9.9, et al. A single digit number of months (3-6?) before they made that change they were very vocal about what they were going to do, offered free access for small operators, and talked about having a trace period where they would simply return nothing to queries before they finally started returning additional IPs, which were clearly documented as rate limiting, thus causing ... questionably configured MTAs to reject out of hand. Fifth, I think this is a prime example of why some people, myself included, suggest to not reject messages just because an RBL lists an entity (IP, sender, sending domain, URL in the body, recipient, etc.). The recommendation that I've seen for more than a decade is to have something, like SpamAssassin, check multiple RBLs for the entity and add points to the spam score for each RBL that the entity is listed on. Then, and only then, should you configure your system to reject messages if the spam score is high enough. Doing this type of RBL interaction helps protect against entities being listed on a subset of the RBLs that you've configured your system to use. Obviously I've already fixed the DNS problem, Great! but I'd like to prevent this in the future. :-) I'd encourage you to spend a few minutes thinking about how you are interfacing with RBLs and what you do when doing so. You could do something as simple as use a different RBL interface like others have suggested. You could re-architect which part of your email stack you're doing RBL interfacing in. You could put infrastructure around your existing RBL interface to filter out query responses that you don't like. You could sign up for SpamHaus's service (free or for pay) and query them directly in a way that identifies the queries as coming from you to avoid rate limiting like you ran into. There are a lot of things that could be done. It looks like the version of enhdnsbl.m4 simply checks for *any* return code and doesn't know how to skip those responses. And I don't know where to buy the brand of LSD that they did at UC Berkeley when they wrote this, in order to make m4 make sense. I think that the sendmail.cf (configuration file) is much more of a problem than the M4 sendmail.mc (macro configuration) that is used to generate the configuration. I've been using Sendmail for more than 20 years. It does almost all of what I want. Exceedingly rarely do I need to go below the established M4 documented in the cf/README file in the Sendmail source (often included with Sendmail configuration files on systems). I have modified an existing mailer cf syntax to support Mailman (2.x) and promoted that to a MAILER(...) mc syntax to make subsequent use thereof easier. I think I found or did similar for SRS support. I'd bet a fast food lunch for both of us that more than 95% of the Sendmail configuration that I've done over the last two decades has been done at the mc level and not at the cf level. Aside: Notice that the two primary files for the MTA configuration are sendmail.cf and sendmail.mc.
Re: [mailop] Any old-school sendmail types here good with the m4?
On 8/23/23 11:00 AM, Michael Grant via mailop wrote: I've been waiting for someone to layer something like yaml on top of sendmail's M4. First: It's not /Sendmail/'s M4. M4 is it's own stand alone language -- one I find quite useful -- which Sendmail happened to utilize. Aside: Is it IBM's COBOL if nobody else uses COBOL any more? Nope, it's still just COBOL used by IBM. I've not done anything with YAML in M4. I rather dislike YAML. But I have written what a few different things in M4 that have made my life a LOT easier. - ~/.ssh/config file manager combined with make and sed - /etc/hosts file manager -- respin of the previous - rwhois data manager - Q & A formater. The first two were fixed position parameters. So I ended up with multiple macros calls that were effectively: host(`hostname', `username', , , , `jump host')dnl I disliked the fixed position parameters so I created the third and forth as more quasi object oriented. I could do things like the following: router( name(`router1') ip(`192.0.2.1/24') ip(`198.51.100.1/24') rack(`A1') )dnl router( name(`router2') ip(`192.0.2.2/24') ip(`203.0.113.2/24') rack(`B2') )dnl router( name(`router3') ip(`198.51.100.3/24') ip(`203.0.113.3/24') rack(`C3') )dnl router( name(`router13') ip(`192.0.2.13/24') ip(`198.51.100.13/24') ip(`203.0.113.13/24') ip(`100.64.13.13/12') rack(`D4') )dnl I could use the same M4 macro calls to different macro definitions to produce different results. It could easily convert the macros into just about any format of output that I wanted. It was calculating the following given the IP and (sub)netmask: - subnet - broadcast - Cisco wildcard It made it really trivial to maintain rwhois data for a network. The fourth Q & A formatter took things like this the following: question(`What is the square root of three?')dnl And converted it to something like the following: Q: What is the square root of three? A: C: The idea being I could maintain my list of questions as a set of individual lines each calling the question macro. Then when I needed to, I could choose questions at random / shuffle / what have you and run them through M4 and get a series of question, answer, comment blocks output ready to be used in the interview process. M4 is great at converting one form of text to another form of text. It's really only your imagination that is the limit of how you convert things. Come on, admit, i know some of you all have thought this too. Nope, not YAML. Many other things with M4 have crossed through my mind. Yes, Sendmail is what introduced me to M4. But M4 in no way, shape, or form limited to, much less belong to Sendmail. Grant. . . . ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] message attachments, was Guide for setting up a mail server ?
On 7/14/23 9:22 PM, John Levine via mailop wrote: Well, sure. What do you think mailing list MIME digests are? I assume that you're referring to multipart/digest. The disadvantage is that a lot of mail systems, particularly popular webmail, deal poorly with embedded messages. Agreed. I'd be worried that some (web) MUAs would deal with multipart/digest worse than they deal with message/rfc822 contained in the former. Especially with the comment that someone made about inline vs attachment disposition of the message/rfc822 MIME parts. When the IETF was trying to figure out the least bad way to deal with DMARC list damage I mocked up some possibilities including a couple of ways to wrap messages as attachments. We found that unwrapping and replying to them worked poorly, so we decided on per-user From rewrites (my dmarc.fail hack) instead. Yep. Grant. . . . ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Guide for setting up a mail server ?
On 7/14/23 11:20 AM, Slavko via mailop wrote:
Hi,
Hi Slavko,
Possible? Yes. Expected? Hard to tell... See latter.
From which point of view?
My experience is that hard and fast usually surfaces errors much closer
to the time they are introduced.
Conversely soft and slow usually causes errors to surface much later,
frequently after the change that introduced the error has left the
brains cache. I usually see soft and slow errors written off as "I
don't know what caused that, I'll dig deeper if / when it happens
again." Thus becoming a circular loop.
With this in mind, my opinion is that hard and fast is often better /
less problematic in the long term.
We all are doing mistakes...
Yep.
I assume that you are aware of DMARC checking, as defined in RFC 7489,
thus i shorten only important parts. The receiver:
1. gets MIME From: domain
1. gets DMARC policy
2. does DKIM check
3. does SPF check
4. does alignment check
5. applies policy
My understanding of that RFC is that both, SPF/DKIM checks happens
as part of DMARC.
Maybe. Not always.
The DMARC implementations that I use don't do the SPF nor DKIM checks
themselves. Instead there are other independent filters that do those
before the DMARC filter and the DMARC filter uses the results from those
tests.
That RFC clearly states, that fail ("-all") can be applied by **some**
receivers before DMARC checks. I understand that section to be
included as note, that not all receivers does DMARC checks, not
as suggestion to do that before DMARC. Am i wrong?
I'm fairly certain that SPF checks significantly pre-date DMARC.
Just because something can be done as part of DMARC doesn't mean that it
has to be done as part of DMARC.
My understanding is, that DMARC compliant receivers doesn't
do independent SPF/DKIM checks, they are done as part of
DMARC (see diagram in RFC). But doing these independed checks
is is not exactly prohibited, which IMO really lacks there.
Why does the SPF check need to wait until the DMARC check which needs
the body (DATA)?
Why can't SPF be checked very much earlier at the MAIL FROM stage before
the body (DATA) is sent?
Of course, where i wrote independent check, i mean apply
result too.
Agree, but i don't extract bussines to separate category.
There's businesses hosting their own email which only effects them and
then there are businesses that host other people's email as a service.
I think the two are quite different in many regards. E.g. Google does
things quite differently for @google.com email than their Gmail product
does for @gmail.com email. GSuite hosted email is even more different.
Yes, starting without encryption is good. It makes debuging/learning
significantly simpler.
:-)
I remember my 28.8 kbit/s modem and download 50 MB MySQL
upgrade as whole day task ;-)
:-)
eg. MTA are prohibited to modify message. But yes they do it...
I question the veracity of that.
Sometimes MTAs are forced to modify messages. I usually see it when the
MSA or upstream MTAs support 8BITMIME and downstream MTA(s) don't. Thus
the last 8BITMIME supporting MTA *MUST* convert to 7-bit messages if the
sender utilized 8BITMIME.
I know that there are other scenarios where an MTA will alter a message
in transit. This is one of the reasons why DKIM has relaxed and simple
canonicalization.
I was not enough clear, these instances are not running on the same host
(container) for the same reasons as you mentioned, sorry.
Thank you for clarifying.
regards
:-)
Thank you and have a good day,
Grant. . . .
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] Guide for setting up a mail server ?
On 7/14/23 11:31 AM, Michael Peddemors via mailop wrote: You all realize that the poor guy looking for a guide on how to set up and email server long since left, you scared him to death with the complexity.. Why does an active ongoing conversation between multiple parties need to stop because the person that asked the original question walked away? How and why are the currently active and communicating parties dependent on the person that originally asked the question? We need to 'encourage' people to run their own mail servers, not scare them away.. If you read any part of my replies I think you would see that I am trying to encourage people to run their own mail server. I try to be very much here's how you do something, here are the problems that you'll likely run into, and here's how you overcome those problems. Let's talk if you have questions. Suggest you might consider changing the topic, if you want to argue the various nuances and complexities of SPF/DKIM/DMARC etc..? And break existing threading and avoid any ignore thread filters that people have put in place? That seems like people changing email addresses to get around filters. No thank you. Grant. . . . ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: AOL/Yahoo requiring SOA record for MAIL FROM domain name?
On 7/14/23 9:26 AM, Marcel Becker via mailop wrote: Yes, of course. We wouldn't do it otherwise. It's billions. And it kept getting worse. Can ~> will you share any rough (as in order of magnitude / log10) numbers? -- If so, please do. One of the things that I find so confusing about this thread is how the SOA test that Yahoo is doing provides any different results than requiring an MX / A / record for a (purported) sending domain. You can thank the scum of the internet. Once more. I assumed that denizens of the Internet's Mos Eisley cantina were the impetus behind such a test / filter. Grant. . . . ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Guide for setting up a mail server ?
On 7/13/23 10:56 AM, Slavko via mailop wrote: Ahoj, Hi, OK, our opinions are near the same, but still opinions only, without something in RFC. :-) IMO one cannot apply SPF independently nowadays. I absolutely think that it's quite possible to apply SPF independently nowadays. Sure, your recipients might not like you honoring the sending domain's request. But who's problem is it really? Who is the most capable of fixing the root cause of the problem? Should we hold sending domains accountable for what they publish in DNS? Or should we coddle them ostensibly because we know better? "Honesty and ass-kicking" from Taylor Mali's What Teachers Make poem comes to mind. "If you ask for it, then I have to let you have it." Link - What Teachers Make - https://taylormali.com/poems/what-teachers-make/ - https://www.youtube.com/watch?v=RxsOVK4syxU Is it better to fail soft and slow or hard and fast? As discussed multiple times, SPF breaks forwarding Didn't the purported sending domain ask that messages not from authorized sources be treated harshly? (Assuming SPF ends in "-all".) Honesty and ... "-all" means that I am asking you to really reject email not from sources that I authorize. (thus can lead to false positives) I question the veracity of a false positive if it's contrary to the published SPF. Sure, SPF publishers make mistakes. But what's better, to coddle them and have transient delivery errors for a long time (fail slow and soft) or make the errors very apparent to them (fail fast and hard) so that they can fix them? and its (soft)fail result can be overridden latter by DMARC, What does does the requested handling; anything between "-all" and "+all", have to do with overriding the result? Or is it that you're only willing to override specific requests, possibly from specific people? and one don't know DMARC result before evaluate it... So? I'll argue that if I set a "-all" on my SPF record that I really honestly and truly want no server than my authorized server to send email claiming to be from me. This includes mailing lists. IMO applying DKIM independently is pointless from start. Okay. The value of a result of a test is somewhat orthogonal to if the when the test can be run. As this, DKIM is good only for statistical purpose, eg. to count reputation for success DKIM's domain. DMARC finally checks them both + alignment, but can be evaluated only after full message body was received. As it can negate (soft)failed SPF, it must be evaluated, to know if and which policy sender defines. Only after DMARC is evaluated and found no DMARC policy (record) or p=none, pure SPF can be applied. That is one way to apply SPF. But it doesn't mean that SPF can't be applied differently. But one still needs to do DMARC record discovery, and as it is based on MIME From: domain, cannot be discovered before full body is received. That negates one big SPF advantage -- apply before body was received... Success DMARC with p=none has the same wight as with any other policy. IMO the difference is/have to be only on failed DMARC. No, that was not what i talk about. Plain text SMTP is not deprecated nor legacy, it is part of SMTP definition. It have to be not suggested (or avoid) only novadays for reasons outside of SMTP. Perhaps i am too affected by my previous job (army's IT, encryption, etc), or i am simple paranoid. But as Snowden show us many years ago, not only bad boys are spying. And as social networks shows, collection of many small details (which are all not important by self) can reveal important complex information about individuals... I absolutely agree that encryption SHOULD be used. I also absolutely agree that email can function without encryption. Yes, a meet that too, i avoid that services if possible (i know, that you don't like my "if possible"). Avoiding services with an unfavorable configuration doesn't mean that the services don't exist. No. I consider encrypting/protecting network connection as normal behavior. Exactly as anyone distinguish own behavior on public places and at home... I agree that encryption should be the norm. I think it is becoming the norm. But I don't think we are there yet. I my job, i have boss. He is independent manager, but still has own boss (raw terms). From time to time the boss's boss does some resolution or directive, eg. my boss must use their email system. And that email system provides only legacy 587/tcp connection. It is not possible for me to avoid it, as that provider MUST be used... I get it. In any other situation, i will either ask to provide better service (pointless in this case) or change provider (impossible in this case). That is point of "is possible"... ACK Or, i have one appliance with relative old SSH server is running, which doesn't understand nowadays OpenSSH signatures. I had to allow legacy sinature in my client,
Re: [mailop] AOL/Yahoo requiring SOA record for MAIL FROM domain name?
On 7/13/23 10:49 AM, Bill Cole via mailop wrote: It's not at all logically hard to meet that arbitrary requirement, you just need a zone cut everywhere you have a MX record. I've run a DNS and mail hosting environment that way. Zone files are very small and numerous. *Logistically* changing an existing zone with many MXs for subdomains to that model could be a serious chore. I question the veracity of "need a zone cut everywhere you have an MX record". My current working understanding is "you need a zone cut for domains immediately subordinate of the PSL". My (limited) personal testing supports not needing a zone cut for a sub-domain of my personal domain. Grant. . . . ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Guide for setting up a mail server ?
On 7/13/23 4:00 AM, Hans-Martin Mosner via mailop wrote: Has anyone on this list tried forwarding (e.g. for ex-employees) via attachment? I have done exactly this on a onesie-twosie / manual basis. I have .forward files on systems that I administer and can run into problems when I send an email from my main account to said system account -- for testing purposes. The messages make it to the system and the system tries to forward them per traditional .forward. The problem is that my main mail system rejects them as that system is not authorized (SPF) to send messages claiming to be me. -- SPF is working exactly like it should be. The testing that I've done of having those messages be sent as a message/rfc822 attachment have worked out perfectly in this scenario. The original message would be kept intact, while the outer message clearly originates with the forwarding agent who may even add a human readable reminder to the addressee to let the sender know about the changed address. Exactly! Opening message attachments should be possible with most modern MUAs, but TBH I don't really have much experience with that. Sadly, I've run into too many -- what I'll call -- contemporary MUAs that don't handle message/rfc822 in what I consider to be an acceptable manner. Specifically, for a long time one of the email oligarch's web mail interface utterly failed to handle message/rfc822 and had zero hope of forwarding such messages. My intention, once I find sufficing round2it chits is to write something that I can put into venerable .forward files to receive the message from STDIN and compose a new message outgoing message with the incoming message as a message/rfc822 attachment. Aside: I'm still undecided if I want to rely on the system's email stack to send the new message out -or- if I want to have minimal connectivity to my primary email server for outbound submission. If I do the latter I'll likely want to make the script more self hosted and rely on fewer living off the land type resources. I have found that originating a new email with a message/rfc822 attachment to work exceedingly well. Better than .forward did 25 years ago. Specifically it maintains the message as it was received and does not have any additional headers or modifications made to it. Grant. . . . ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] AOL/Yahoo requiring SOA record for MAIL FROM domain name?
On 7/13/23 2:24 AM, Gellner, Oliver via mailop wrote: The requirement is actually less restrictive as it only requires a SOA record and not additional A, or MX records in DNS. It is not necessary that every hostname has a SOA record, that indeed would be unreasonable. Yahoo only requires a SOA record for the organizational domain (base domain). As "or.us" has been added to the PSL and the owner wants it to be treated as a TLD, a SOA record is required for westfir.or.us, however none exists. I keep thinking that someone at Yahoo / AOL has forgotten the difference between a domain and a zone. But then I re-read / test things and realize that this seems to center on things directly in domains listed in -- what I'm understanding to be -- Mozilla's Public Suffix List. So I'm left thinking that this is an artificial -- not necessarily arbitrary -- restriction that Yahoo / AOL is imposing o things directly in PSL. My concern is that it's quite possible to have sub-domains in the parent zone. This used to be common for a lot of smaller entities that simply relied on their parent domain to manage the child's DNS as part of the parent domain's zone, especially with small entities that had no technical need nor desire to host their own DNS. I did some minimal testing after reading this thread and skimming thread that Andy linked to from earlier this year. I sent from the address I'm using now to my wife's Yahoo account and it was delivered to her inbox just fine. I also sent from an address in a subdomain (e.g. test.tnetconsulting.net) to my wife. That second message was delivered to her spam folder, but it was delivered. I don't like this restriction, but I don't object to it as long as it's central to the PSL and direct children therein. If it ever extends further into children of the PSL, then I'll be upset -- for all the good that will do. My concern is that Yahoo / AOL isn't creating an arbitrary "every domain must have an SOA record" and completely loosing sight of the fact that SOAs belong to the /zone/ apex and are not associated with /domain/s. Grant. . . . ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Guide for setting up a mail server ?
On 7/12/23 9:28 AM, Jaroslaw Rafa via mailop wrote:
Despite I said that SPF/DKIM/DMARC adds little to security, I would
disagree with what you write here.
The problem is for recipients, not for senders.
I'd argue that almost all SMTP shortcomings are on the receiving end,
not the sending end.
Assume someone receives a forged mail claiming to be from a delivery
company (like DHL or similar) saying "Your package cannot be
delivered, because additional delivery charge of 1$ is required,
please go here to pay: ".
Detecting (some large subset of) spoofed senders is the primary use I
see for SPF.
The primary use case I see is spoofed $ADMINISTRATOR from $YOUR_DOMAIN
saying that your password is expiring and needs to be reset or that you
have a quarantined message please check it.
Even if one in 1000 people who receive it logs in to the fake
payment gateway - and in turn will have their online banking
credentials intercepted and their money stolen - it is a HUGE damage
if they send this phish to millions of people.
Agreed.
The same type of attack can be performed by impersonating basically
any company that sells something online, because the key point here
is to direct recipients to the fake payment gateway, which allows the
attacker to steal their money ("their" == recipients, not
impersonated company).
That's one of the key attacks. Another is to harvest email credentials
to be used for other campaigns.
Theoretically SPF/DKIM/DMARC should protect against it. But this type
of messages is also very well recognized and filtered by
antispam/anti-malware software.
I see many examples of it where anti-spam / anti-virus / anti-malware
don't detect it.
Almost all of those examples could easily be detected with SPF.
It's also enough that the attacker uses own domain that is similar to
the impersonated one (for example uses dhl-courier.com or
dhl-poland.com instead of dhl.com; both don't exist as of this
writing) to pass all SPF/DKIM/DMARC tests (while the
antispam/anti-malware software should still properly detect and
filter the message).
I consider that to be a testament to how successful SPF can be such that
it moved the problem from impersonation attack to a look-alike / homonym
attack. As in we caused the spammers to change their tactics because
what they were doing no longer works.
Also, as I already said, this type of attack is usually carried out
using SMS messages to mobile phones, not email (at least huge
majority of phishing campaigns of this type that were reported by
security-related websites in my country were carried out using SMS).
I don't remember any serious phishing incident in recent years that
was related to email.
As an email administrator I can't do anything about SMS attacks. But I
can do something about email attacks.
Maybe this is because of more widespread use of SPF/DKIM/DMARC, but I
rather suppose this is because much more potential victims can be
reached via phone than via e-mail, and because it is much harder to
verify on a phone what website you are logging to. The phishing
message uses a link shortener (which seems understandable because of
the limited length of a text message), people just click on that link
and land on a website that looks just like the real one they are used
to.
I've had people be annoyed with me that their password manager didn't
offer to fill their password on the look-alike website only to later
wish they had not copied and pasted their password after learning that
they had just compromised themself.
Fuses blowing and circuit breakers tripping can be annoying. But they
are doing so for a reason. Things are trying to keep us safe. --
Don't put a penny in the fuse box and then wonder why you have an
electrical fire.
I also think that in the realm of filtering methodologies spam / virus
filtering takes more computing than DMARC filtering, which takes more
computing than DKIM, which takes more computing than SPF, which takes
more computing than basic TCP connection filtering. As such I try to do
filtering using the fewest computational resources and thus start with
the simpler things and work up in computational cost; TCP connection
filtering -> SPF filtering -> DKIM filtering -> DMARC filtering -> spam
/ AV filtering. Can SpamAssassin detect something that fails SPF, quite
likely. Do I need the 800 lb gorilla that is SpamAssassin when I can
use the 80 lb monkey that is SPF? Nope. I can use the 80 lb monkey
perfectly fine.
As you say, the problem is for recipients. So, why force the
recipient's hand to use an 800 lb gorilla when they could use the 80 lb
monkey if you simply provide them data to give the 80 lb monkey in the
form of publish SPF information.
IMHO, some -- but not all -- that choose not to publish any information
to make the recipient's lives any easier are somewhat choosing to say "I
don't care, I'm not going to lift a finger, and you must
Re: [mailop] Guide for setting up a mail server ?
On 7/12/23 4:11 AM, Slavko via mailop wrote: BTW, my English is not best, don't take me word by word, please... I don't think I've had any more trouble understanding you / your use of English as an additional language than I have had with others who use English as their primary language. Different uses of meanings of words happens within languages too. Perhaps that was goal, but if so, then i much more like the language eg. of RFC5321: ...something "is out of scope of this document". That works for me. The only problem here is, that some sites/tools doesn't respects that broken signarure have to be treated as no signature. But that is not DKIM's mistake. I consider / classify that as a problem with a given site's use or configuration of DKIM not a problem with DKIM itself. Individual DKIM installations and DKIM in general can cause problems. But the former is much more localized to the specific installation while the latter tends to be common across multiple installations. What is not clear, at least from my point of view, is p=none policy. RFC mention it as way to not enforce any policy, but receive reports. But what then if DMARC's p=none, no DKIM and SPF fails? Have to be applied SPF result or have to be applied none policy? In my opinion, if a domain's DMARC has a p=none, then you don't filter on DMARC. But you still independently apply your site's local SPF filtering policy preferably following the sending domain's stated SPF wishes. The only thing that you would do with DMARC is send the notification of the result. It is not about which action have i to choose. I wonder what one can/have to expect from other sides... Yes i know, their servers, their rules, thus one can expect relative anything. But no one can expect anything even on RFC compliant targets... I think that we should safely expect sites to be largely RFC, or BCP, compliant. I consider that to be the middle of the road and for people to stay on their side of said road. BTW, i apply pure SPF (+ DKIM) in case of DMARC's p=none. 1) I would expect you to apply SPF independently of DKIM and DMARC if the sending domain publishes SPF records. 2) I would expect you to apply DKIM independently of SPF and DMARC if the message has DKIM headers and the sending domain publishes DKIM information. 3) I would expect you to apply DMARC using the aforementioned SPF and / or DKIM results if the sending domain publishes DMARC information. A DMARC policy of none simply elides that 3rd step to me. Of course, i do my best effort to be as interoperable as i can/know. I consider that as crucial in mixed environment, as Internet is. Perhaps ISP was not right abbreviation, sorry for that. I meant email provider, but i want to avoid ESP abbreviation as it is often used with conjunction of mass mail here. I think that ISP and ESP are both correct. ISP is probably the older answer with ESP being the newer answer. As with all things (Internet related) some are abused or used for things we don't like and they can earn an unpleasant meaning. But I believe that Email Service Provider is exactly that, a company that provides email service. What that email service is used for it independent of the fact that it is providing email service. Yes, there are some very questionable / shady ESPs. But there are still many good ESPs. IMO we basically agree, that plain text connection over public net have to be secured. I would consider setting VPN for mail only as too mutch effort, especially for regular users. I absolutely agree that using some form of encryption is strongly recommended and that not using encryption is ill advised. Sure, there are cases when encryption is not needed, eg. i don't encrypt communication to 127.0.0.0/8 and ::1, nor over LXC internal bridge. But my original point was about connections over public and semi-public networks. But then nowadays best practices have to mention it. Yes, encryption of some form is very much so a SHOULD in RFC speak. But IMO in case of foreign services here is another mean: one cannot expect, that it will be provided. That surprises me. Perhaps other parts of the world have been using TLS, either implicit or explicit via STARTTLS, for so long that they are now no longer offering service without TLS. My experience has been that unencrypted connections are still offered in the areas where I'm interacting. Usually unencrypted will work close to the service (as in connected to the ISP's network) but may not work further away. I still people using really old configurations without TLS and ISPs not choosing TLS when helping customers set up new systems. In some ways, TLS has been viewed as "oh, you're one of the people that want to be really secure", let me get the documents. The notable exceptions that I've seen are the email oligarchs, some of whom tend to be charging full speed ahead and dragging the rest of us with
Re: [mailop] No MX but A: broken MTA(s)
On 7/12/23 1:02 AM, ml+mailop--- via mailop wrote: Maybe you can explain how you tested it and which software (MTA?) was used? Sure. I stood up a VPS and configured Sendmail as I have done for 20+ years. I created a (sub)domain-name -- in a different domain than my main domain name -- that resolved to said VPS but no corresponding MX record. I then tried to have my primary client using my primary email system (VPS with Sendmail) send a test message to my user at the test domain. That didn't work. I think that Sendmail in the MSA role rejected things out of hand about the destination not having an MX record. I then tried to have `mail` behind Postfix on a different system send a message to my user at the test domain. That too failed. But I don't remember why. Neither of the two failures seemed to be related to anything other than the lack of MX for the test domain. I say this because as soon as I added an MX record and re-tested, both of the above tests worked. It has been many months since I last did this test. But that's what I remember both with the most recent test and similar results with previous tests. I tend to re-test this every 2-5 year because it comes up in discussion and I'd like to have first hand experience with sending and receiving in such a configuration. I have third, if not second, hand reports of this working for others. Grant. . . . ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Guide for setting up a mail server ?
On 7/11/23 4:20 PM, Jaroslaw Rafa via mailop wrote: For start, I suggest to implement SPF, DKIM and DMARC only for outgoing mail, and in fact only to satisfy Google's requirement that these should be in place. Don't bother checking them on incoming mail. (It's actually how I do it). I am extremely surprised to see that recommendation, especially here on the mailop mailing list. That seems very much like "checklist compliance" and not actual security that said checklist is evaluating. My opinion is what your suggestion of only using SPF, DKIM, and DMARC on out bound email and not checking on in bound email is very questionable. That being said, your servers, your rules. RBLs and content filtering are enough to protect from spam. I see close to zero improvement if I would check SPF and/or DMARC. Of course YMMV. I'm actually more worried about phishing than I am spam. Spam is an annoyance but much less dangerous than phishing. Phishing can cost people a LOT. Send, maybe yes. Having it delivered is the other way. Consider my case: FCrDNS, and not a "generic" one, SPF, DKIM and DMARC in place, domain used for a long time. Yet still Google puts messages from me to Spam folder of the recipients and there seems nothing can be done about it. They simply so strongly dislike my parent domain :(. Maybe I'm lucky. But I think I've had remarkably good luck delivering to Gmail recipients. But we are talking about BCP here, not about a RFC that defines a protocol. I think BCP can be a proper place for clarifying the roles. The problem is that mentioned email oligarchs understand "reputation" as something completely untransparent and internal to their mail systems, not anything related to the community consensus. So. Every single organization running email is free to run it however they want to. Your server, your rules. My server, my rules. Oligarch's server, Oligarch's rules. Community consensus may be a client user base agreeing that something is spam. Nothing guarantees that people outside of the community have visibility into the community consensus. And you can't know in advance what is a "reputation" of a given domain for a given email oligarch (see my problems with Google mentioned above, which are clearly related to reputation, or rather what Google understands as reputation). You can't know for sure. But I suspect that you can have an idea. Grant. . . . ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Guide for setting up a mail server ?
On 7/11/23 4:31 PM, Jaroslaw Rafa via mailop wrote: Hm... does this smell a bit X.400 or is it only my impression? I believe the idea is protocol agnostic. But I used to see it more in the '90s back when X.400 / OSI was much more of a thing. I am quite certain that I've seen this type of B2B networking independent of the Internet done multiple times in the last two decades. Grant. . . . ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] No MX but A: broken MTA(s)
On 7/11/23 3:00 PM, Jarland Donnell via mailop wrote: Does anyone actually receive mail by their A record in 2023? I'd just assume break the RFC and save the resources for retrying and eventually bouncing every email that ends up attempting delivery to an A record. I have seen a-record fallback work, as in legitimate email flow, for others within the last two years. I have not been able to get it to work in my testing. Grant. . . . ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Guide for setting up a mail server ?
On 7/11/23 2:48 PM, John Levine via mailop wrote: If your From: domain has neither an A nor an MX, I don't think you're going to get much mail of any sort delivered. I believe it's possible for two entities to configure their email servers to exchange email with each other without the use of DNS. E.g.: - IBM configures their email servers to send all @lotus.example email to lotusmail which resolves via /etc/hosts to 192.0.2.1 - Lotus configures their email servers to send all @ibm.example email to ibmmail which resolves via /etc/hosts to 198.51.100.5 Ergo IBM and Lotus can exchange @ibm.example and @lotus.example email with each other without the use of DNS. This would most likely be done in a business-to-business partner type configuration where companies wanted to make sure that such B2B communication did NOT traverse the public Internet. Presuming of course that IBM and Lotus had some sort of private connection and routing between each other. I know that this is very far off the beaten path. But I believe it's germane to discussions about what is and is not possible with email as well as what are the minimum requirements. I believe truly understanding these fringe cases help elaborate and foster a better understanding of what is more common. Grant. . . . ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] No MX but A: broken MTA(s)
On 7/11/23 2:45 PM, Michael Orlitzky via mailop wrote: 5.1. Locating the Target Host Thank you for the pointer Michael. Today I Learned :-) Grant. . . . ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF +all considered harmful
On 7/11/23 2:09 PM, Sebastian Nielsen via mailop wrote: I think sender adress should be changed. I think that /forwarding/, as in altering the envelope recipient address(es), probably should have the envelope sender address changed. I say /probably/ because I'm sure there are some situations where it should not be done. I just can't think of them now. The reason is, you didn't compose the email, you shouldn't use the sender's identity. Arguably none of the following composed the message: - Outbound MSA re-sends the message it receives from the submitter ostensibly using the submitted envelope from address. - Inbound spam filter re-sends the message on to the ultimate mailbox server re-using the inbound envelope from address. - Outbound compliance filter re-sends the message out to the world re-using the inbound envelope from address. I think that the envelope from address SHOULD NOT be changed in any of these scenarios. Fortunately, none of these scenarios are email terminal points even though they are SMTP terminal points. When forwarding a email, you overtake the spam responsibility for that email in any case, so you ought to ensure your server isn't used for spam. I mostly agree. On the other hand, you have the responsibility to ensure a forwarding user doesn't set up anyones else's address as forward, by for example using double-opt-in verification or where you really know they hold that email adress (even when authorized users are using the forward system, for example employees of a company). Agreed. Couple these 2 together and you don't risk up ending up on blacklists because a user forwards a spam through your forward, because spam is both filtered AND forward is confirmed only. Confirmation is completely independent of spam. Spam filters can fail open or email can be quite above board but unwanted by the ultimate recipient. Ergo spam can slip through a forwarder. I have always tought it’s a ugly practice to forward the email as-is, as its same as forging someone's signature. I don't know if I would consider it proper or what I would choose to do in a vacuum. However I didn't make the choice in a vacuum. I had prior art both with physical postal mail being forwarded and years of eMail / SMTP before me that I started by matching behavior. At some point I switched to SRS when forwarding. I think I did that as part of supporting and advocating for SPF. You use someone elses identity, because you CLAIM to have received a email from their server. I've said similar using slightly different words. E.g. a mailing list generates a new email that is substantively based on the message that it received, purportedly from a given sender. The receiving server on the other end cannot know this. Agreed. This is why sender address should ALWAYS be rewritten when forwarding an email. I can't agree with the absolute nature of this. There is also the question of what is forwarding. Do the MSA, ESP, and compliance relays listed above count as forwarding? Does me creating a script to receive messages from the LDA and attach them to a new outbound message to a different recipient count as forwarding? Aside: The last bit about attachments is what I want to end up doing for my personal accounts on the various systems I have accounts on. Originate and send a new email from my account on a remote system to an email address of my choosing elsewhere in a way that does not run afoul of SPF / DKIM / DMARC filtering. Grant. . . . ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF +all considered harmful
On 7/11/23 10:08 AM, Benny Pedersen via mailop wrote: on next hub envelope sender changes, so new spf problem when next hub forwards mails This behavior is not guaranteed and SHOULD NOT be relied on. If it works, then great! But don't be surprised if it doesn't work. I remember Sender Rewriting Scheme being discussed multiple different places many different times and the vast majority of people involved in them loathed the idea of the envelope from address being changed at one or more hops along the way. For a long time Gmail actively discouraged SRS et al. saying that that they would associate the spam nature with the domain used in the changed envelope from address, thereby likely associating it with your server instead of the original purported source. My understanding is that Gmail has (finally?) changed sides and now agrees that there are times to change the envelope from address, if not actually recommending it. As for Postfix doing this by default, that's a new information to me and I consider it highly atypical. As someone that has gone out of my way to run SRS on emails that I relay (but not originate) I agree with the idea. But I also think that I'm in the extreme minority in my belief / support of SRS. I take some comfort in Postfix (purportedly) defaulting to it. But I still think that I'm in the minority and that most forwarding will not modify the smtp envelope from. Grant. . . . ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] No MX but A: broken MTA(s)
On 7/11/23 12:35 PM, Michael Orlitzky via mailop wrote: Seriously though, it's not a "fallback" in any pejorative sense. SMTP predates much of DNS, including MX records. It's a fundamental part of the specification. I largely agree, especially from a historic point of view. However, I don't see any mention of a-record fallback in RFC 5321. -- I didn't chase any updates. -- I do see four occurances of "fall" in the document, three of which are fall( )back and all three have to do with something other than MX records vs a-records. As such, I'd question the veracity of current SMTP needing to support a-record fallback. Email, SMTP, is an evolving and changing standard. It's important to know what both current expectations are and I think it behooves you to have an idea what previous expectations were. Grant. . . . ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Guide for setting up a mail server ?
On 7/11/23 8:29 AM, Bill Cole via mailop wrote: It is worthwhile to protect the details of a SMTP session on the wire, beyond simply protecting the contents of email. Agreed. +1 E2E tend to only address data and completely ignores metadata which transport encryption helps. Grant. . . . ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Guide for setting up a mail server ?
On 7/11/23 4:54 AM, Slavko via mailop wrote: If something have to be said, then it have to be said and then doesn't matter who said it ;-) Well said. Nowaydays (especially joung) people tends to feel as experts, when they setup something first time. Thus, when not used word by word, it is good reminder. On other side, i work with computers & networks for more than 30 years, and still have questions ;-) :-) I start to maintain my own mail after 20 years of experiences with other nerwork services (both, LAN & WAN). Before that i afraid, that my experiences are not enough to fight with SPAM (in both directions, incoming & outgoing). But finally i recently (some years) decided to start with it, thus my point of view is relative fresh. Fair enough. Fortunately, with email, especially with a non-high-value domain, can be relatively safe to start with. Setup and get it working is not different than other services, not more easy nor more hard, just different. It requires to learn how to setup particular SW as in other services. I suspect that one of the things that makes email harder is that it encompasses many other interrelated and interdependent things. So if you're starting from zero there is a lot to learn. Other protocols / services tend to have less interdependencies. What i see as more hard with email is: + it is not one protocol (SMTP and IMAP/POP) + it is not one SMTP purpose (MTA/Submission) + terminology is not clear (how many terms eg. for return-path, relay, etc) + it is very flexible, choose proper topology is not easy without some experiences + many roles, which one MTA can do + too many RFCs describing email, and some of them are not well cooperative + outdated or incomplete/wrong guides + lack of (open source) tools to work with eg. MIME mails These things make email harder to start, than other services, but after one got them, it is as easy/hard as any other service. BTW, what i most afraid (before i start) was how i will fight with SPAM to (required) postmaster mailbox. But that simple doesn't happen and that address gots near to no SPAM. I think my concern back when I started administering email was that my server didn't become part of the problem / become a source of spam, relayed email, etc. Functioning as I wanted it was a secondary desire. Fortunately I think I've manged to do just enough of both for quite a while now. Aside: I agree, my RFC mandated accounts get very little spam. Yes, but will iname it as good practice, not as best. Fair enough. I have mixed feel from these. While can be "good friends", it seems that they involved to "bad boss". I feel, that particular RFCs was done by people, who consider them as "must have" and thus they mention cases (eg. DMARCs none policy) in not clear way, and doesn't describe clearly what to do if not all are implemented (eg. SPF without DMARC) on receiver side... I suspect that some of that was on purpose as to not dictate what recipients should do. After all, your server, your rules. I think SPF itself is relatively straightforward. 1) A domain owner publishes where they will send email from and what they would like recipients to do with email that does not match said publication. 2) A receiving email server uses that published data to influence their local filtering algorithms. IMHO DKIM is slightly more complex: 1) A sending server applies a cryptographic attestation of (part of) the message that it is sending. 2) A receiving email server uses that cryptographic attestation to influence their local filtering algorithms. DMARC is more complicated yet in what it checks. 1) A domain owner publishes filtering criteria that they would like applied to their domain. 2) A receiving email server uses that published data to influence their local filtering algorithms. Notice how all three are someone publishing information and someone (else) using that published information to influence recipient filtering configuration. What each filters on and how it does the filtering is different. But at a basic level, they are all similar two part systems; publish information and use said information. That oligarch's behaviour is IMO direct result of aforementioned "must have" approach. I'd have to go back and reread the various RFCs, but I don't remember anywhere in the specification what values should be in what fields, just that specific fields should be populated. Of course this is predicated on you wanting to utilize said specification in an interoperable way. I meet rejects due forward confirmed reverse DNS fails, then i setup it. But i agree, that mention it as requirements is wrong. Yes, you will very likely need your forward and reverse DNS to match. But those values matching has nothing to do with what those values are. 3-2-0-192.CITY.STATE.ISP.EXAMPLE.IN A 192.0.2.3 And 3.2.0.192.in-addr.arpa. IN PTR
Re: [mailop] Guide for setting up a mail server ?
On 7/11/23 8:15 AM, Bill Cole via mailop wrote: Surprisingly, A-record fallback works just fine for B2B email. My experience differs. I've found A-record fallback to work inconsistently. I think that A-record fallback is dependent on the sending MTA. No one notices. Or at least no one appears to reject mail solely for that reason and inbound mail works perfectly. It is, after all, the way email was originally designed to work. The few times that I've tried to use A-record fallback -- testing for science / discussions like this one -- have resulted in failure. Though if memory serves that's because my MTA of choice balks at the lack of MX record for the recipient domain. IMHO, A-record fallback in 2023 is what Bob Ross would call a happy little accident. However, I admit my evidence for that is ~2y old. I wouldn't *intentionally* allow an actively mailing domain to rely on A fallback... I tried A-record fallback (on a test domain) some time in 2022 and it failed when I tested. Grant. . . . ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Guide for setting up a mail server ?
On 7/11/23 4:26 AM, Jaroslaw Rafa via mailop wrote: TECHNICALLY, any email (there is no technical difference if it is B2B or not) requires only a machine that has an A record and a running MTA. I'll wager a lunch that A records aren't even required. Maybe not any name resolution at all. Things like /etc/hosts and NIS(+) for resolution aside. The thing that I was thinking about when I wrote my longer email was businesses explicitly configuring email routing in their MTA such that messages for a given destination domain were routed to a specified IP address or even host name. That IP address, or hostname, can be locally significant and not known by anyone outside the organization. This type of bidirectional configuration would only be done between organizations expressly trying to make sure that messages didn't flow through the open Internet. The most likely entities to do this are businesses. Yes, individuals can do this, I've done it with friends as a proof of concept. But such individuals are such the minority as to be a rounding error. And I understand Grant was writing from a technical, and not administrative point of view. I think that the pair of entities explicitly configuring their MTA to route email to the others MTA independently of MXs also speaks to administrative points of view. After all, it was likely a business decision / administrative decision that prompted the desire to do such. You can mail to username@hostname.domain, you don't need to have a MX record. MX records are just a convenience so you can mail to username@domain instead of username@hostname.domain. Agreed. I'll add that TCP/IP networks don't /need/ nor /require/ a *default* gateway. They just need a route, whatever that route is. It can be an explicit route solely for the destination which doesn't apply to any other destination. I've found that what the vast majority of what people do is a significant subset of what is possible to do that it's not even funny. What's worse is that -- in my opinion -- too many people fail to understand that there are options that don't require doing what others do, e.g. MX record for email or default gateway for IP routing. These are Google requirements, not SMTP protocol requirements. We should not confuse one with the other. I absolutely agree. Google, et al., have chosen to configure their email servers to require things that the SMTP protocol does not require to function. Each postmaster is free to configure their server(s) as they / their organization sees fit to do so. But that does not make such configuration good. Grant. . . . ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Isn't SpamEatingMonkey's SEM-URI broken?
On 7/11/23 4:18 AM, Jaroslaw Rafa via mailop wrote: Sadly, you're probably right. It would take someone as universally trusted (and as trustworthy) as Jon Postel was once, to run such a service. But there are no people like Jon Postel in decisive positions anymore... Yes, I try to find the good in others more so than many. However I don't think that it would require someone like Jon Postel. Though I would implicitly trust him. I think that what I'm describing could be done in the open above board and completely visible to all. Much like how Certificate Transparency logs provide visibility into what Certificate Authorities do. I don't necessarily need to trust the local scribe if what they record is publicly visible and authenticateable (using contemporary technology). Look at how we -- ostensibly -- trust the DNSSEC for the root zone. It's open, it's visible, it's auditable. I think that if we really wanted to we could come up with something like that to assess if a given RBL operator (entity) has provided evidence that they are adhering to a minimum level of acceptable behavior and / or exceeding it. To me, this is largely just data that is publicly available that is run through a definable / publishable algorithm. As such, there is not as much trust in the organization holding the data as the data and public algorithm itself. Yes, I agree there is an opportunity for questionable practices to be done in a closed system. That's expressly why I'm thinking about an open / visible / auditable system. I genuinely believe that we could come up with something that (the vast majority if not everybody) could be trusted. Or at the very least make it easy to detect when someone did something wrong. Grant. . . . ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Isn't SpamEatingMonkey's SEM-URI broken?
On 7/10/23 2:40 PM, Jarland Donnell via mailop wrote: The problem is, running any blacklist and wanting to constantly speak to people who are often just confused about how relevant your list even is, are very often two different things. So there's not anyone to talk to, at least not from a public-facing angle. It would certainly be nice if anyone on this list that might be representing SEM wanted to speak up on the matter. This sounds to be a case worth speaking up on. I found myself wondering if there was anything like the Better Business Bureau or some sort of accreditation that RBL operators can apply for wherein they need to: - demonstrate that they are responsive - publish what is required to be delisted - provide points of contact The intention being that an RBL operator is taking steps / effort to be genuinely good. Yes, mistakes and accidents happen. It's how those mistakes and accidents are responded to that make all the difference. I'd wonder if someone like M3AAWG or the likes could fulfill this function. If such an accreditation existed, then perhaps various filtering software providers could default to only enabling accredited RBLs. I hope it goes without saying that I would want it to be relatively easy to become accredited. I suspect it would need to be even easier to have such accreditation revoked. All players start somewhere small and some grow into big players. Grant. . . . ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Guide for setting up a mail server ?
Dear ${FELLOW_EMAIL_ADMINIATRATOR},
I don't know how to preface this email other than to say -- I believe
the following needs to be said lest we loose even more control of our
email community.
I'm sorry that both 1) I feel that the following needs to be said and 2)
that I'm the one that's saying it.
...
I can't say that any of Richard's comments are technically wrong. But I
will say that the tone of what the email represents is both
disappointing and concerning to me.
N.B. that Richard is one of many that have said similar things. My
comments are *NOT* directed at Richard.
Rather many of us are culpable for allowing things to get into this
state by not actively fighting against it. -- The first step is
admitting you have a problem.
...
I agree that email is not easy by any stretch of the imagination. But
comparatively I suspect it's easier to host your own email than starting
a company to build a car from scratch. Is this a good comparison,
probably not. But is it true? I really hop so.
On 7/10/23 7:48 AM, Richard Clayton via mailop wrote:
not that I know of -- arguably there should be one, but perhaps it
will just encourage unwise activity. I am reminded of Usenet advice
of not posting for the first six months and if you ask why that is
good advice then add another six months...
I agree with -- what I'll call -- auditing. I don't agree with asking
questions meaning that you need to extend the audit time. I've seen
some EXTREMELY intelligent questions asked by people very knew to the
situation.
Simply asking a question does not, in and of itself, mean that someone
is ignorant of the topic. Quite the opposite can be true. E.g. "Is
there any reason to ever run an open relay? There seem to be LOTS of
negative points to doing so; ." type thing.
I recently reviewed an IETF draft on (de)centralisation which
observed that running your own mail system, rather than using a
centralised provider was far too hard.
This disappoints me, greatly. Both the idea that running a
decentralized mail server is hard and more so that such recommendations
would admit or worse support such a stance.
In discussions with Eliot Lear we ended up with a list of things you
had to do:
* configure and manage the MTA
This is obvious and not specific to email. You have to configure the
service for any and all services. Chances of defaults doing exactly
what you want are quite rare.
* arrange for a backup MTA
I'll argue that requiring a backup MTA is not strictly required.
I'll absolutely agree that a backup MTA is best practice.
There is a really big delta between strict requirement and best practice.
* manage DNS MX, DKIM, DMARC and SPF records
None of those are strictly required either. Business to business email
can function without any of them.
I'll VERY STRONGLY ENCOURAGE at the very least MX record(s).
SPF, DKIM, and DMARC are the order that I'd advise others be implemented.
Chances are quite good that you will be able to exchange email with
domains that aren't hosted by the email oligarchs.
Aside: Have enough email administrators given up the torch and now
started praying at the alter of the email oligarchs?
* manage reverse lookup records, including managing the uncertain
chain of authority between the instance and the nearest SOA
I didn't have a problem with reverse DNS being required 22 years ago and
I have even less of a problem with it today.
Yes, this can make it harder for someone to run an email server at home.
But if they really want to do this, they can find ways to make it
happen. I'm happy to help people make it happen too.
There is also the fact that unless the ISP is doing egress filtering --
that's it's own independent discussion which the lack thereof helps me
in this discussion -- users can probably have acceptable success with
all but the email oligarchs if they simply have their MTA hello as the
name that the ISP assigns to the connection presuming that the ISP has
forward and reverse DNS configured therefor.
* manage certificates associated with TLS for SMTP and IMAP
I'll argue that TLS is not strictly required.
I'll absolutely agree that TLS is a best practice.
I'll also posit that IMAP is not required for email.
* manage DKIM certificate
I maintain that DKIM is not a strict requirement.
* manage one's upstream to address PBL issues
Maybe, maybe not.
* keep the MTA secure and free from DOS attack
I have problems with that statement.
1st: What is "secure" in this context?
2nd: Why is anything other than an MTA less susceptible to a DOS attack
than an MTA?
Also, Michael W. Lucas's I Have A Dream comment about "goals" vs
"dreams" comes to mind.
TL;DR: Focus on goals, things that you can influence, and don't worry
about dreams, things that you have no influence over.
Link - I Have A Dream
- https://mwl.io/archives/22749
ALSO back in 2011 (when the world was a little
Re: [mailop] Mimecast Adimin Probation Block - 74.203.49.59
On 6/28/23 11:07 AM, Chris Truitt via mailop wrote: The Mimecast spam checking appears to be clicking every link. This has inadvertently caused an uptick in Unsubscribes. Aside: Isn't this why the unsubscribe links are encouraged to use / require a POST so that simple GETs don't accidentally trigger the unsubscribe? Grant. . . . ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Tightening of delivery rules for Exchange Online
On 3/28/23 12:49 PM, Mike Hillyer via mailop wrote: In the spirit of splitting hairs, as someone who has opened a retail business, code violations are usually something that *hasn't* been done. In this case updating a server. Eh ... a choice, possibly unconscious, was made to not do what was required. In a "failing to plan is (tantamount to) planing to fail" sort of way. Other than Microsoft's statement, I don't see a requirement that SMTP servers be running current (Microsoft) software. I see no reason why the email industry in general should follow suit. What's more, is it's likely dangerous for us to follow Microsoft in this regard. I suspect that they have a MUCH better understanding of what version strings translate to what version of their products than people outside of Microsoft. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Tightening of delivery rules for Exchange Online
On 3/28/23 11:37 AM, Mike Hillyer via mailop wrote: But the fire marshal can shut down a business before it burns to the ground for code violations. The operative phrase is "for code violations". As in something has been done. I'm not aware of any widely recognized code that says that your SMTP implementation must be less than X number of Y units old. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Tightening of delivery rules for Exchange Online
On 3/28/23 11:07 AM, Al Iverson via mailop wrote: You're sort of trying to argue me out of agreeing with you. Here's the parallels I see. ? A Sendmail server so old that it can only be an open relay. Block it proactively? Or block it only after it has been exploited? 1st, I said /contemporary/ Sendmail. ;-) An Exchange server so old that it HAS to be vulnerable to XYZ spam relay exploit. Block it proactively? Or block it only after it has been exploited? I think both of them are /only/ /block/ /after/ it has been exploited. The fact that it is exploitable does not mean, much less guarantee, that it will be exploited. Consider an ancient NT 4.0 w/ Exchange 5.5 and line of business application that is only used from the physical console to look up old records in said LoB application. It's behind multiple levels of stateful packet inspecting firewalls from multiple vendors. Consider a /contemporary/ *nix system running a /contemporary/ version of Sendmail that is only bound to localhost and used to send email updates from a sensor attached to a USB port. I view both of those systems as being very nearly impossible to exploit in the way that I think you are talking about. /What/ /have/ /these/ /systems/ /done/ to warrant being blocked? N.B. one is ~25 years old and the other is ~25 weeks old. /How/ are you going to differentiate between SMTP from Exchange 5.5, SMTP from /contemporary/ Sendmail, and SMTP from MS-O365? I think that it's very audacious to say that SMTP from software older than X number of Y units. Who sets the X number and Y units? I find it a "grey area" because it feels wrong at some level to block without evidence of being exploited. As well it should. Which is what I thought your point was. Yes. But we're all debating for debate club's sake. Who gives a shit what we think? It's not our call. Their server, their rules. We, as an email industry decide what we collectively think. Hopefully what we as an industry collectively think has some influence on what Microsoft decides to do with their servers. I'm going to spend only the TINIEST amount of time shaking my fist at the sky. I feel like we all should do more than that. There are many parallels throughout history. There was an episode of MacGyver /many/ years ago where a comment was made about killing an individual ant. It's not the one at that's the problem. It's the millions of it's relatives that are coming to the funeral that are the problem. Our collective voice as (part of) the email industry are those millions of relatives coming to the funeral. We /collectively/ put the fear into the person that kill us individually. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Tightening of delivery rules for Exchange Online
On 3/28/23 10:19 AM, Al Iverson via mailop wrote: Eventually we have to stop allowing connections from misconfigured servers that are being exploited to do bad things. But what is "misconfigured"? How do you define that from a technical level? How do you identify that? I agree that "servers that are being exploited" is something that can be identified and evidence of bad behavior. I don't agree that simple mis-configuration without any exploit is a threat. E.g. what grounds do you have to block an Exchange 5.5 system someone is running in their home lab protected from the internet and sending three pieces of legitimate email a week? This seems tantamount to states saying that you can no longer drive cars that are more than X years old. Even if they are in pristine condition. This is borderline oppression to me. Conversely "being exploited" is demonstrable and justifiable. We have an analogy in the legal system; the police can't act until /after/ a crime has been committed. There are different and longer processes that must be gone through to take action before a crime has been committed to revoke people's rights. This seems like a good thing to help both reduce the exploitable damage that can be done by these servers and also nudge their admins to wake up and patch up or shut down. Each admin has the right to run their email server the way that they want to. -- This includes both running ancient software. This also includes the right to refuse to allow a system to connect to send email. But how do you identify the aforementioned Exchange 5.5 from contemporary Sendmail, both of whom are speaking perfectly valid RFC compliant SMTP by all contemporary rules? And what grounds do you have to object to the Exchange 5.5 if it's doing nothing wrong while allowing spam from a breached account behind the contemporary Sendmail system? Reminds me a bit of blocking open relaying mail servers back in the day. Not really. Blocking open relays was a binary test of openness and blocking if it was open. Any MTA, new, old, beta code, or ancient bits must all adhere to the test the same way. Simply deciding that something's too old to play is a very bad thing in my opinion. Like back then, I do worry about blocking servers that may not have been used for badness. If it's only that they COULD be abused, it's a little more grey area to reject mail from them versus they HAVE been abused. I don't think it's grey area at all. Just because someone / something /could/ commit a crime (send spam / steal something) does *NOT* mean that they will do so. But also, their server, their rules. Meaning I think Microsoft has the right to do this, regardless of how we might feel about it. I think we as an industry SHOULD PUSH BACK VERY HARD on anything along the lines of "too old to play" mentality. I'm okay if Microsoft wants to say "you must use one of these supported communications methods to play". I strongly suspect that even the venerable RFC 821 SMTP from 1982 will likely suffice for a very long time. To re-iterate, I think the "too old to play" mentality is a VERY BAD THING and a VERY SLIPPERY SLOPE. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] mailgun anybody? (variable sender address) time
On 3/26/23 2:32 PM, Jaroslaw Rafa via mailop wrote: One big downside: you need to have two MXes. I don't view multiple MX records as a bad thing. Or are you referring to IPs that two different names resolve to? -- There are multiple ways around this. I don't understand ~> appreciate the problem you're talking about. Will you please elaborate so that I hopefully understand? -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] mailgun anybody? (variable sender address) time
On 3/25/23 3:10 PM, Heiko Schlittermann via mailop wrote: We used MX sandwiching/NoListing on our own MXs and had issues sending messages to remote sites which did sender verification via a poorly implemented callback. So, is it fair to say, that you had problems sending to site that used a questionable implementation of a questionable practice? Please note the question mark above, I don't want to blame *any* vendor without proof. Time passed since then, maybe they improved their callback implementation. ACK 1st MX: TCP RST (either by open firewall and no listener on port 25, OR done by the firewall directly (iptables … -j REJECT --reject-with tcp-rst) 2nd MX: listener on port 25 3rd MX: firewall, dropping incoming TCP SYN The "sandwich" makes more sense when depicted like that. I was just thinking in terms of a non-answering (at the SMTP level) MX /before/ any and all other MXs. I assume that there is (are) one (or more) functional MX(s) at a lower priority / higher number. Conversely, it seems like the "MX sandwich" is a specific configuration that happens to involve No Listing. That's what I understand as a sandwich ;) Fair enough. The configuration I'm using is a bit different: 1st MX: No Listing 2nd MX: standard primary 3rd MX: standard secondary 4th MX: anti-spam solution looking for bad actors. Proper sending sites try the 1st one, and fastly move on to the second. Poorly implemented senders either give up after the 1st one, or try to be clever and use the 3rd one (as this one is often less prepared for spam rejection as the primaries), and hopefully give up. That's why I have the 4th MX. Same here. Unfortunately Renate from mailgun didn't respond yet. I'd like to hear their intentions with this approach. I don't know if it's the case or not, but I've heard that it might be in the same spirit as to why different IPs in the network send subsequent attempts instead of the same host ~> IP as the first time. Namely multiple systems sharing a common spool of queued messages waiting to be re-tried. But even that tends to have the same envelope from in the instances that I've spent time looking at. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] mailgun anybody? (variable sender address) time
On 3/25/23 2:25 AM, Heiko Schlittermann via mailop wrote: Ah, ok, that's what I know as MX sandwiching. Interesting. I'll have to research that phrasing to see if I can learn more about it. Ok, that was your point. Sure. We tried this (NoListing, MX sandwiching) for a while and had problems when *sending* messages. Are you indicating that you had problems sending to others who were using NoListing / MX sandwiching? Or are you saying that your equipment had problems going through NoListing / MX sandwiching in your outbound infrastructure? Some appliances (barracuda?) on the remote end implemented sender verification as callback, but where stupid enough to contact the 1st MX only (the one which did the TCP RST). As a result, they didn't accept our mails. Well ... the idea is that a proper / RFC compliant SMTP stack is used ... which rules out some vendors. }:-) I've never been a fan of Barracuda for a number of reasons. Would you mind elaborating how you tested NoListing / MX sandwiching? Did you 1) timeout connections, 2) send a TCP reset, or 3) send an ICMP error? I've got an IP bound w/o a daemon listening, so the TCP/IP stack responds as if the SMTP service isn't currently running. -- I prefer that over a timeout as I think it's a fail hard ~> fail fast ~> move on to recover type sequence of events. It's good to hear about others that have tried No Listing / MX sandwich and their experience therewith. With our current greylisting implementation (using MAIL-FROM/RCPT-TO) as key, we didn't have issues so far. Until mailgun started (?) using variable senders for each delivery attempt. I never understood different envelope senders for each attempt of a given message. -- I can see different envelope senders per message, a la. VERP. But I would naively expect each message to have a fixed envelope sender and recipient from submission time until delivery time. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] mailgun anybody? (variable sender address) time
On 3/24/23 4:01 PM, Heiko Schlittermann via mailop wrote: Hm. Maybe I'm stupid. Nope. I'm sure that's not the case. We all learn things when exposed to new things. ;-) What does this change? From senders PoV it is a temporary error. The sender will retry. NoListing works by causing the sending server to cascade through multiple MXs. First MX either doesn't respond /or/ sends a TCP reset. Thereby causing the sending MTA to try the next MX. The next MX responds like normal. The cascading from one MX to the other MX achieves a very similar result as grey listing. But it does so in a way that is indifferent to the actual addresses used. There is also no state to be maintained by the receiving system. And on my side I still do not recognise their 2nd attempt, if they use a variable MAIL-FROM. With no state to maintain it doesn't matter what the envelope from is, variable or static. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] mailgun anybody? (variable sender address) time
On 3/24/23 1:24 AM, Renaud Allard via mailop wrote: I would say, that's called greylisting. But with a changing envelope, the message has no chances to pass any greylisting process. The behaviour from mailgun would make them unable to pass any kind of greylisting anywhere. That's one of the advantages of NoListing (TCP reset or timeout on high priority / low numbered MX) in that it would be compatible with this. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] IP RBLs and large cidr blocks
On 3/9/23 12:45 PM, Michael Peddemors via mailop wrote: Okay, better expand on what I am saying.. say you have a bunch of IPs from Linode, .. you 'might' want to indicate better what they are for.. eg.. sharedhosting.hisdomain.com mailout.hisdomain.com etc.. If the PTR's still reflect the generic li1072-208.members.linode.com He probably won't get them removed from an RBL.. I guess there are people that don't configure reverse DNS on their Linode (et al.) IP addresses. But I can't fathom doing that for anything even remotely production unless "linode.com" was in my employer's name. Usually this is ONLY done for a /24 or greater by upstream providers. Ah. So maybe it's more they "won't" support it than "can't" support it. (While it can get done for smaller blocks, you end up with that ugly double PTR record, one from the provider and one from your DNS server) Please elaborate on what you mean by "ugly double PTR record". RFC 2317 Classless IN-ADDR.ARPA delegation comes to mind and I bet that's not what you're referring to. Yes, we see that.. it does occur.. but pretty obvious usually. Take a look at the OVH guys with fake ownership.. but it can be used to help positively identify good operators, and that value is important as well. ACK Strange, wish Linode would pipe up on this on list.. Ya. I wish that more providers would be active on industry mailing lists. Thankfully I find that I can get some engagement on Twitter. But sadly, often the people that respond aren't able to do much. Though occasionally they do manage to unwedge things. Some segments are REALLY bad, and other segments never generate a complaint.. They must be differentiating internally some of their customer signups.. I wonder how much of it has to do with age of the segments and / or VPSs therein. If the hosting provider doesn't provide 'rwhois', speak with your feet. Given their recent announcement of 20% rate increase on a lot of products / services, I'm probably going to be re-evaluating things. Even GoDaddy offers it, and as much talk about bad GoDaddy, a person with a correct 'rwhois' can usually get off an RBL a LOT quicker. ACK -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] IP RBLs and large cidr blocks
On 3/9/23 2:03 PM, Gellner, Oliver via mailop wrote: Also some MTA may use different or stricter checks for IPv6 than for IPv4, so it‘s possible that a message gets rejected while it would have been accepted if delivered via IPv4. I believe Google has more stringent requirements for IPv6 than they do for IPv4. Admittedly they are for things that are SHOULD be the case in IPv4. Google just chose to make them MUST in IPv6. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] IP RBLs and large cidr blocks
On 3/9/23 10:45 AM, Michael Grant via mailop wrote: If I can get this spamhaus issue solved, why should I not just leave it in place so my mailer will talk ipv4 or ipv6? Why just stick with ipv4? I realize it's not necessary today to be able to send on ipv6 but why should I not get this working? You are opening yourself up to /some/ issues related to the preference of IPv6 over IPv4. I've had a few receiving domains that I needed to break IPv6 for email. I've seen a LOT of ... data ... noise ... information ... something about people strongly preferring IPv4 over IPv6 for email if not outright actively discouraging IPv6 for email. It's a proverbial Your Mileage May Vary. Just be mindful that you may run into some unexpected things, like your IPv6 address being on an RBL that your IPv4 address is not. And the complications related thereto, like your MTA preferring IPv6 over IPv4 to the destination checking said RBLs. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] IP RBLs and large cidr blocks
On 3/9/23 9:45 AM, Michael Peddemors via mailop wrote: Yes, it's called 'rwhois'. Of course, linode can SWIP the larger portions, with a clear indication of what parts of the IP space are used for what. I've opened multiple support tickets with Linode over the years asking for SWIP and / or RWHOIS and they have always responded that they do not support that. Do you have evidence to the contrary showing that they do support SWIP and / or RWHOIS? AS well, you 'could' change default PTR's for segments used differently. I find the idea of requiring PTRs to contain a magic string to be unappetizing at best and appalling at worst. IMHO *NOBODY*, and I mean absolutely /nobody/ gets to tell me what I name my own system. That extends to things that tie into the host name, e.g. rDNS PTR records. This would also be predicated on there being a single string that the entire industry would accept. I find this to be extremely unlikely. At least you are asking how you can do things differently. I mentioned to Michael -- in a direct email -- that I wonder if there is an opportunity to put something in parent DNS zones in the .arpa sub-domains, much like DS records for DNSSEC go in parent zones, so that an IP provider (or at least naming authority) can specify that a range is delegated to another entity. I also mentioned that miscreants would be likely to abuse this and artificially divide their IP space so that bans on some parts would not effect other parts. Hence the need to have a larger addressing / naming authority provide this. I think the distributed nature of rDNS could work well for this /if/ there was an agreed upon way to signal this /and/ we could get addressing / naming authorities to support it. I know there has been a lot of Linode 'slagging' on the list, but it isn't as bad as some other networks. I'm using Linode and still having reasonable luck. Though I do see evidence that the neighborhood is running down in some places. Now, having said that that, you are looking at the IPv6 space. Are you planning to run email on IPv6? Many challenges ahead. I am and have been running a dual stack email server for many years. I've only got a few recipient domains that I've artificially broken IPv6 on. As a customer, ask Linode to provide 'rwhois' for you. I have done exactly that multiple times. Each and every time they say that they don't support it. But for email, you should stick to IPv4. Just my two bits. I apparenlty have different two bits. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mail Sending Self-Test Platform
On 3/2/23 12:27 PM, Tobias Fiebig via mailop wrote: The tool looks for a perfect world, which there isn't. ... Still, if i'd not deduct points for those things, everyone would get a 10. ;-) I have no idea if your infrastructure / UI could support this or not, but what if you had an option to turn off / not count a test when displaying the results. E.g. doesn't like lack of rDNS signing, so instead of saying 7 out of 8 what if you said 7 out of 7* where the * means that some tests are disabled / ignored. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mail Sending Self-Test Platform
On 2/28/23 2:51 PM, John Levine via mailop wrote: It's not common and I would be astonished if anyone checked as part of delivery. I wouldn't mind if the test called it out mostly in the sense that: - I would want case consistency - I'd be worried about tickling a bug in someone else's software / configuration thereof. As such a polite heads up would be appreciated. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] How to get Google to set a null MX for gmail.co ?
On 2/16/23 1:47 PM, Benny Pedersen via mailop wrote: please dont suggest this I agree that these ... questionable ... solutions are sub-optimal. However I fully agree that each email server operator is free to run their own email server as they see fit (or allowed to do by management). I think I would personally add a rule that would reject the destination domain rather than re-writing it. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Feedback Loops and Sub-Domains
On 2/9/23 2:21 AM, Gellner, Oliver via mailop wrote: In my experience the spam report button is not only used as a sort of fast unsubscribe, but also as a replacement for the delete button. Knowing how unreliable training the end user is, I wonder if it's worth altering the equation wherein we (as the email industry) train email client programs to conditionally react differently when the make-this-message-go-away button is pressed. Wherein if the message is obviously ham, delete the message or if the message is obviously spam, report the message, or optionally ask what to do if it's not obvious and default to delete the message. Alter the equation, sort of like making people remove their ATM / debit card before they get cash reduced the number of cards left in machines. A "Smart Delete" button if you will, similar to the "Smart Reply" button that fairly gracefully handles multiple different types of replies. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Simple mailing list expander program for aliases files?
On 1/11/23 3:39 AM, Jaroslaw Rafa via mailop wrote: Why? Another primary use case I have is a company owner moved a system from the office to their house as they moved states and the new ISP filters destination TCP port 25. So having something in the mail wrapper being able to communicate directly to the central server bypasses many such restrictions. It's sort of the MTA vs MSA type solution. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Simple mailing list expander program for aliases files?
On 1/11/23 3:39 AM, Jaroslaw Rafa via mailop wrote: Why? Your script will run as a part of existing mail flow anyway, within an existing MTA. Making use of this existing MTA seems to be the logical choice, instead of trying to replicate its function yourself. Consider a scenario where the local MTA is rather ... limited or an environment where the local MTAs don't have an SMTP route out to the world. So messages piped into STDIN of sendmail (either proper name or wrapper) don't make it out to the world. In short, there are times when I want to send the message directly to the receiving MTA / infrastructure with as little interaction with the sending MTA / infrastructure as possible. Independent of hat color. For me it's like trying to not rely on OS's file system, but implement a filesystem on your own and making direct writes/reads to disk blocks... I think it's a bit different and more nuanced than that. Consider a brain dead installation that only knows how to deliver messages locally, possibly even with localhost.localdomain domain parts. IMHO there is a reasonable chance that more needs to be configured correctly both on the system and out on the Internet for receiving email servers to accept messages. I feel like there are times when bypassing the local MTA stack / infrastructure has advantages. Another way to think about it is if the ~/.forward wrapper was gatewaying message into another non-SMTP protocol. Would the "Why?" question be any different if I wanted to push the message from STDIN into something MQueue? It seems to me like the client portion of the output side would quite likely be independent of the local system's MTA stack / infrastructure. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Simple mailing list expander program for aliases files?
On 1/10/23 2:59 PM, Dan Mahoney via mailop wrote: Sometimes a problem comes across your desk that you say “wait, how is this not solved yet?”. Ya I too have wanted something like this to enhance ~/.forward files on servers that I manage, while addressing all the problems that you're describing. So I’ve gone down the rabbit hole, looking for various combinations of remailer scripts, forwarder scripts, group forwarder scripts, mailing list expanders, etc. And I’m coming up surprisingly short. I'm actually not surprised that you're coming up surprisingly short. Could I knock something together myself in perl in a half hour? Sure. This is one of those things that you can get proof of concept code in 90 minutes. Would it likely have its own untested edge cases for us to discover? Absolutely. But you'll spend too much time over the next 3 days / weeks / months dealing with edge cases. In a world of DKIM/DMarc compliance, especially, where “blow away the original headers and forward anew” is the best answer, I’m shocked to not find something like this as well. I'm convinced that the best thing to do is to attach the incoming message as message/rfc822 MIME part. 1) Don't butcher the message that you may want redacted data from. 2) Create a new message from the local source (envelope & headers) that is fully authorized and clean. I just haven't found sufficient round-2-its to sit down and do this yet, despite the fact that I would deploy it to a bunch of systems darn near immediately. It doesn't help that part of me wants to integrate the SMTP client into the script instead of relying on the local MTA stack / infrastructure. If I'm doing that I want to support TLS. I don't want to embed credentials to relay in a script. I don't want to deal with certificate based authentication AA EINSUFFICIENTROUND2ITS Our needs are simple: a unix program we can pipe a message to that will preserve the original message mime portions and subject, but discard most of the previous other headers. How in 30 years of email, something that I can’t just pkg install isn’t easily findable baffles me. Because not many people want to do this particular activity. The overlap between those that want to do so adhering to contemporary and evolving email standards is shockingly small. If someone knows of something, let me know. Pick your language de jure, burn a few hours, and fix problems as they come up. That's my plan anyway. But I'm serious about the suggestion of attaching the incoming message as a message/rfc822 MIME attachment. At least unless you have a specific reason to NOT do so. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is there a way to unsubscribe from Nextdoor emails?
On 12/19/22 8:21 AM, Daniele Nicolodi via mailop wrote: it seems that Nextdoor recently went on a mission to expand their user base and are mailing former users with whatever crap. I assume that their excuse for why the contact is CAN-SPAM compliant is because of the "established business relationship". I wonder how long before the "established business relationship" should be considered to be expired. I'm guessing somewhere between one and five years. If you've not had any interaction in that time, there is no longer an established business relationship. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] IBM: [to unsubscribe] please enter your first, last name, email and country
On 12/7/22 6:46 AM, Matt Vernhout via mailop wrote: CAN-SPAM, CASL and several other Anti-Spam/Digital Marketing laws require that the recipient only need to supply their email addresses to unsubscribe. It may also be a requirement of their ESP, send a note to the abuse desk for 1 unsolicited emails, 2 possible violations of local or relevant legislation. Nothing says that the name that you give during the unsubscribe has to be accurate. I'll commonly use First M. Last when I'm coerced into filling out such forms. Sometimes it's not worth tilting at the windmill. -- So saith someone who oft tilts at the windmill. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF (and other email security protocols) Survey
On 11/23/22 8:38 AM, Slavko via mailop wrote: Anyway, using SPF on shared environment is something, what negates SPF purpose at all, as anyone from that shared provider can succesfuly pass SPF for any other domain in it (sharing the same TXT records). Thus in these shared services is SPF mostly cosmetic or part of PR/marketing only. Whole result then depends only on that, if particular provider checks spoofing from own customers, which is a) not published and b) moves trust to smewhere else. I don't agree with SPF being mostly cosmetic on a shared hosting environment. Yes, other people on the same host can send messages without authorization while still passing SFP checks. However, others, not in said shared hosting environment /can't/ send messages while still passing SFP checks. The difference is in the scope of who can pass SFP checks, the /just/ the shared hosting environment verses the entire Internet. I believe there is some value in SPF even in a shared hosting environment. It's just less value than in a dedicated hosting environment. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPFBL - was Re: Recommendations for host with good IP reputation or use external SMTP?
On 11/2/22 3:26 AM, Alessandro Vesely via mailop wrote: By comparison, DNSWL.org seems to be more widespread, as it is often queried by commonly used tools like SpamAssassin and Rspamd. Registration is automated and free[†]. I agree that DNSWL is also a good resource. However, I also believe in multiple signals being a better thing. After all, I think many people check multiple RBLs and use them each as negative signals. So why not use the same methodology for positive signals too? -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPFBL - was Re: Recommendations for host with good IP reputation or use external SMTP?
On 10/31/22 11:39 AM, Andrew C Aitchison via mailop wrote: If it is useful isn't three bucks small enough for the spammers to pay too ? My understanding is that spammers are trying to be as cheap as possible. Considering that the price per listing of each IP is 60% of the price of the smallest Digital Ocean VPS (last time I looked), I doubt that spammers would be willing to pay. I also expect that SPFBL would catch on to the fact that a client is listing a bunch of IPs that are quickly failing and being delisted. -- Insert business analytics for fake customers and the IP space that they are playing in. There is also the inherent delay between spinning up the VPS and the SSPFBL listing. Plus requesting the listing is a manual out of band (email) process. I suspect that this functions as some modicum of gating that thwarts massive abuse. But yet still modest enough that humans doing this for artisanal mail servers aren't impositioned. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Recommendations for host with good IP reputation or use external SMTP?
On 10/30/22 5:35 PM, Ian Evans via mailop wrote: DO admits their IP reputation sucks and so won't intervene with vadesecure on behalf of my IP. I'm surprised and disappointed that Digital Ocean won't do anything to vouch for "yes, this customer is using this IP, and has been for $TIME". I'm new to this list, so is there a thread in the archives that might discuss VPS hosts with clean IPs? There are occasionally threads about small email servers. See the recent "the oligarchy has won" thread and the recent T-Online / Orange default block threads. Is it better to use an external SMTP provider whose whole biz is having clean IPs? That depends, what do you consider to be "better"? Do you mean less of your time / effort? Or do you mean fighting for the right to self host email? Aside: Check out SPFBL's allow list service. I spent the one-time $3 per IP to list my two VPSs. I consider the price low enough that it's reasonable for me as an individual to be able to do. Read: It's within my reach. I don't like the idea of needing to pay, but I think it is a small amount that demonstrates that I'm serious about trying to run a good mail server. At least more so than those that won't pay. https://spfbl.net/en/dnsal/ -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] How do I break Gmail forwarding?
On 10/24/22 12:01 PM, Tara Natanson via mailop wrote: The forward is set up to send out our postmaster@ address, So I can't let it bounce. :( I can respect that. I wonder if it would be possible to implement a conditional rejection that matches details of the problematic message. I would also wonder if it requires a real time rejection during the SMTP transaction with Google, or if a correctly formatted DSN would convey the necessary information. -- I would expect that it wouldn't be too much trouble to fabricate such a DSN for this white hat purpose. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Tangent: Banks and imprint requirements in Germany
On 10/22/22 12:55 PM, Sebastian Nielsen via mailop wrote: Think the "imprint" as a hygiene certification for a public for-pay internet service. Think like a digital restaurant, and you understand why these laws are there. I'm not so sure about that. I thought the imprint was simply official contact information. I don't see how that also speaks for current health / safety inspection / certification. Here in the U.S.A. businesses can have a license to operate a business which is independent of food / safety inspection. They are two completely different things. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Tangent: Banks and imprint requirements in Germany
On 10/22/22 12:31 PM, Slavko via mailop wrote: As fan & contributor to open source software i do not agree, no, not all is about money only. I am particularly impressed with the FCC's use of "no pecuniary interest" when discussing operating on an amateur radio license. My understanding is "pecuniary" is that you benefit in some way, be it monetary compensation, favors, preferential treatment, or benefit in any way. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Tangent: Banks and imprint requirements in Germany
On 10/22/22 9:00 AM, Sebastian Nielsen via mailop wrote: If you provide free services, customer can't expect anything, and you are free to do as your wish. If your email service goes down, so what? Customer got it for free, not our problem. If you win a toaster in a free competition that required no entry fee, customer can't complain then when that toaster breaks down, because theres no warranty or requirement to repair or replace a toaster that you got completely for free. Sebastian's entire comment, especially the last (quoted) paragraph, seems like the imprint / impressum is really the legal identification for consumers to use when filing a complaint / warranty / etc. Which really seems like official data for consumer protection purposes. If that is the case, it does make sense that said information should be readily available /somewhere/. It's just that what information and where it is available can cause some people ... indigestion. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Update: it's not. Re: T-Online is now really blocking messages from non-commercial and simliar senders
On 10/21/22 1:02 PM, Jaroslaw Rafa via mailop wrote: As many have pointed out, putting this information online may be harmful to privacy and even facilitate criminal acts against you. I still feel like there is room for an abstraction layer wherein you provide a postal address and telephone number which does (eventually) make it to you, but does not expose personal / private information. E.g. "You can contact us via our legal representative at $POSTAL_ADDRESS and $PHONE_NUMBER." You are talking about a "company", while the whole thread started with the problem that *private* (non-commercial) mail servers run by *indiiduals* (not companies) have trouble delivering mail to t-online.de... Ignoring the privacy implications for a few minutes, my understanding is that private (non-commercial) mail servers can also put the same information / imprint / impressum on their web site and thereby qualify to be white listed by T-Online. Is that not correct? -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Update: it's not. Re: T-Online is now really blocking messages from non-commercial and simliar senders
On 10/21/22 10:30 AM, Laura Atkins via mailop wrote: I know a number of mailservers that are able to successfully send mail to t-online.de and have never contacted the tosa@ address. I wonder if that hints at a thus-far un-discussed aspect of T-Online's policy. There is every chance that T-Online did some sort of analysis of email traffic to identify likely legitimate senders and primed their white list with those domains / IPs. E.g. ratio of outgoing messages to domains / IPs verses spam complaints therefrom. Similarly, I suspect that T-Online also primed their white list with the email oligarchies. -- If I can borrow / re-use what I consider to be an apt description. After all, every single list has to start from something. Good lists organically grow (and shrink) over time as needed. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Update: it's not. Re: T-Online is now really blocking messages from non-commercial and simliar senders
On 10/20/22 9:53 PM, Jyri J. Virkki via mailop wrote: None of the three analogies is really comparable (phone call, postal mail, taxi) because in each case the person doing the rejecting is the intended recipient. Who certainly has the moral right to reject. All three scenarios can be extended in effectively the same way that you did: - phone call - you make outgoing calls, but return calls are routed to a switchboard / screened. - postal mail - inbound postal mail passes through a mail room that screens. - tax - door man exactly as you outline. Try this: You live in an apartment and invite a friend over for dinner (message sent by you and received by your friend). They take the taxi over to your place and arrive (response email IP packet reaches t-online). But, your building has a cantankerous doorman who doesn't like how your friend looks and slams the door in their face. The doorman doesn't check whether you wanted this visitor and doesn't even tell you what they just did. So, you sit in your apartment all night waiting and wondering why the friend isn't arriving but you will never know. I believe that building owners should have the ability to post a doorman to do exactly that. I would certainly have a well known and clearly published policy explaining this to tenants. -- If $SOMETHING is not done, non-tenants don't get in. Where $SOMETHING is tantamount to a guest pass. I see exactly this type of behavior in multiple buildings. I've seen /automated/ forms of this via alarm / access control systems. If you don't have a badge or an access code you don't get in. This type of security is often referred to as "gated communities". That's a good analogy for t-online. Both the sender and recipient are innocent victims of t-online's oddball behavior. If the pizza delivery driver doesn't have a gate code, then they don't get into the gated community. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders
On 10/20/22 9:14 PM, Kai 'wusel' Siering via mailop wrote: But their "policy" does not adhere Yes, T-Online /does/ adhere to T-Online's policy of only accepting email from senders that T-Online considers to be blessed. No. They 554 anyone, including me from any of my 1k+ v4 IPs except for 2 of them. No, T-Online doesn't 554 /anyone/. T-Online quite obviously 250s many blessed senders. Let me compute 2/1000, I came up with 0. Please correct my math, really, really please … The math doesn't matter /because/ T-Online /does/ 250 blessed senders. Granted. OTOH, nothing states that _that single outcast_ shouldn't be properly casted in the default configuration of any mailserver there is. I believe there have been multiple others beside myself that think that T-Online should NOT be shunned in MTA /default/ configurations. As has been pointed out before, doing so *does* increase deliverability, *does* increase transparency. No. It makes deliver-ability *WORSE*. As pointed out before, your choice to refuse to accept email from T-Online means that *you* break communications between a T-Online user and /you/ wherein the T-Online user sends a Reply-To: set to their Gmail address. /You/ *WOULD* be able to communicate with them /without/ sending any email to T-Online. But /you/ have chosen to block that email at /your/ server. Sure. Totally agree. But: IF it is a KNOWN FACT that they DO NOT ACCEPT MAIL FROM ANY SERVER except those where they previously whitelisted it's IPv4, AND THEY ARE THE SINGLE ONLY MAILSERVICE ON PLANET EARTH to do so, THEY MUST BE MARKED AS SUCH. I suspect that there are *MANY* Business-to-Business email servers that use similar filtering and only allow /specific/ previously white listed addresses to communicate. That's the exact same thing that T-Online is doing. The only difference is that T-Online has a more public user base. As anything else leads to broken communication. I'm okay with you being okay with that, but you cannot chance sides afterwards. And this is not over yet. I have no problem receiving messages from T-Online. I will honor a Reply-To. Or I'll put an impressum on my web site and ask T-Online to white list me. -- I have no problem with what T-Online is doing. It's their server(s) and thus their rules. I made that clear multiple times already; feel free to check the archives. No. You have made it abundantly clear that you strongly disapprove of what T-Online is doing. You have not provided justification for why MTAs should alter their default configuration to banish T-Online. You're apparent vehement dislike for T-Online is not in and of itself justification for banishing them. Years ago a few email servers started requiring reverse DNS PTR records. People wanted to shun the first few that required such as outliers. Now the PTR record is SOP. As stated above, there are many B2B email servers that only allow white listed peers. Do you also want to identify those B2B email servers and equally banish them? If not, why not? Why do you think that T-Online deserves anything different than other B2B email servers? Anyone's policy has to work within the parameters of the choosen protocol and it's policies, otherwise interoperability is not possible. T-Online *IS* working within the parameters of the SMTP protocol. Servers that are white listed can speak bog standard SMTP / ESMTP to T-Online without a hint of a problem. Hence T-Online is using standard protocols. As such, t-online.de's policy is not compatible with how the SMTP protocol is supposed to work: 554'ing basically anyone is NOT the way to go. It may not be a /good/ way to go. It might even be a /bad/ way to go. But it is still within the SMTP specification. Besides, mx*.t-online.de don't comply to RFC 5321, Section 3.1: "a 554 response MAY be given in the initial connection opening message instead of the 220. A server taking this approach MUST still wait for the client to send a QUIT […]". They don't. And they aren't Joe Random following a bad HowTo. t-online.de is deliberately breaking standard's track RFCs to, as it seems, gain a competative advantage. This mustn't hold. I understand why you might think that. However RFC 5321 § 3.8 -- Terminating Sessions and Connections -- states: """ An SMTP server MUST NOT intentionally close the connection under normal operational circumstances (see Section 7.8) except: ... o After a timeout, as specified in Section 4.5.3.2, occurs waiting for the client to send a command or data. """ The letter of RFC 5321 § 4.5.3.2 -- Timeouts -- talks about /command/ timeouts. I believe that the initial greeting / hello banner is within the spirit and can leverage timeouts. Thus the server can time out connected clients in an extremely short interval and naturally close the connection. RFC 5321 § 7.8 -- Resistance to attacks -- also goes into more details about what
Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders
On 10/20/22 4:49 PM, Kai 'wusel' Siering via mailop wrote: Another rule from an earlier era outlines one of the fundamental principles of the Internet Agreement: I will accept your traffic, *subject* *to* /my/ *policies* and agreements, if you will accept mine, *subject* *to* /your/ *policies* and agreements. Yes, but as t-online.de fundamentally breaks with this principle, No they do not. /Their/ /policy/, which they have published on the Internet, is /their/ prerogative. What's more is they /are/ /accepting/ your email *subject* *to* /their/ *policies*. Nothing states that anyone has to approve their policy or that they have to adhere to anybody else's policy. Each and every single email administrator (or organization) is free to run their email server(s) as they choose to. giving a 554 to *any* IP per default, they should be single cased out for good by default. What grounds do you think that T-Online should be singled out? How are they not operating their email server subject to their policy? -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Update: it's not. Re: T-Online is now really blocking messages from non-commercial and simliar senders
On 10/20/22 1:22 PM, Kai 'wusel' Siering via mailop wrote: Well, it's both at the SMTP layer: Same level. You are obviously as free to run your server(s) as you want as T-Online is to run their servers as they want. I don't get your point, as that is what t-online.de is effectively doing. There's no problem with the phone line / connection. The pone line / connection is working well enough for someone to rudely say something to you and hang up. Try this: Does the taxi fail to take you to someone's house if the person opens their front door, sees it is you, and then slams the door in your face? -- Did the taxi fail to get you to the person's front door in any way? Similarly, did the postal service fail to deliver a letter if the recipient sees who it's from and immediately tosses it into the trash? Well, some...@t-online.de would now know, if that would have been a real SMTP session. It will prevent responses written into the void. That's a Good Thing™. I'm not convinced of that. There are plenty of ways that someone could (inadvertently) cause one of your users to try to send a message to T-Online. The Reply-To: header comes to mind. t...@rx.t-online.de is there to help T-Online users in these cases. And who is to help your users when they send a message to T-Online? Perhaps via replying to a message from somewhere other than T-Online that had a Reply-To: directed to T-Online. Yeah, so what you are saying is: because t-online.de has 12 millions more mailboxes, it is OK for them to mail my users but to block my user's responses at the same time? I disagree. Nope. That's not at all what I said. Nor is it what I implied. I'm confident that you knew that too. I do agree on that. Hence the move to make sure future postmasters will not be bothered _unless_ _their_ users initiate the conversation. It's, after all, not their fault that t-online.de is setup north-korean style. Less lost mail in my view _is_ better, Lost tends to imply accidental. Conversely, you are consciously preventing email in an additional direction. So my opinion is that you are making things worse than they already are. The flip side of the Reply-To: is someone sending to one of your users from their T-Online address and setting their Reply-To: to something else; maybe Proton Mail or Gmail. therefore I completely disagree with your counting. See my reply to an test email I sent yesterday from @t-online.de to a test server of mine wait for expiry ... # mailq -Queue ID- --Size-- Arrival Time -Sender/Recipient--- 098221201B0 916 Thu Oct 20 21:07:45 some...@testmail.uu.org (host mx01.t-online.de[194.25.134.72] refused to talk to me: 554 IP=931.620.721.400 - A problem occurred. (Ask your postmaster for help or to contact t...@rx.t-online.de to clarify.)) some...@t-online.de Nice IP address lookalike. ;-) How long is that message going to sit in your queue? Given that it has a 554 response, I would have expected your MTA to have sent a DSN already. This would have been prevented if some...@t-online.de would not have reached that mailbox in the first place. Getting the bounce directly that they cannot sent there, they might use another known email address of the receipient or revert to other means of contact. Or even reach out to tosa@rx to clarify the situation with testmail.uu.org's postmaster. That assumption is predicated on the T-Online sender 1) receiving a DSN with your error message, 2) the sender understanding it, and 3) the sender being able to take other action. As t-online.de is not likely to change their setup, the sanest approach is to limit the overall damage, which is to reject mail from t-online.de _unless_ they whitelisted one's sending IPs (as per SPF, most likely). That is your opinion. It happens to be an opinion that I disagree with. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Update: it's not. Re: T-Online is now really blocking messages from non-commercial and simliar senders
On 10/20/22 10:32 AM, Jaroslaw Rafa via mailop wrote: I consider this being purely a connectivity thing. Except that it's not a /connectivity/ thing. At least not on any OSI layer. The rejection that you are advocating for is sent across / over / through the established connection. So, no, I don't believe it's a /connectivity/ thing. Do you call the pone company to report a problem calling a phone number when they answer the call, say "I'm not talking to you.", and hang up on you? T-Online customers can send mail to any mailserver and they aren't aware of the fact that they can't get a reply because T-Online has a "default block" policy, unless whitelisted. They are harming connectivity in a way that is invisible to their users, doing in fact misservice to those users. I agree completely. The proposed configuration change only makes this visible and clear, I disagree that it will make it visible. I doubt that it will make it clear. First and foremost, that relies on the rejection notice, and details thereabout, to make it back to the sender. What's more is that it requires the sender to have (access to someone with) a modicum of understanding. Even if the sender is clued into what is happening on a technical level, you are still left with the mismatch in size of companies, the larger company tends to have an advantage (at least) as large as the size discrepancy. Senders will almost always say "well I can send to others so it can't be on my side thus it must be on the recipient's side". introducing also default blocking in the reverse direction (unless whitelisted, which you can always do). I think that a block you know about is "better" than a block you don't know about. I believe such a block is setting things up for a self fulfilling feedback loop. -- Once two parties start "doing something because the other is doing it to them" there is no exit / end / termination of the loop without external influence. T-Online customers trying to send mail to other mailservers will hit that block, and if the reject message will exactly specify the reason - something like "We block mail from T-Online because they block mail from us" - and the customer forwards this message to T-Online support, I assume they'll at least have to explain the situation to the (probably angry) customer. I seriously doubt that's going to work out satisfactorily for anyone other than T-Online. Maybe over time their will consider changing their "default block" approach. Isn't there some rule / guideline / law that states that the longer that something has been in place the longer it is likely to stay in place? Seeing as how T-Online has purportedly had this in place for a decade, I doubt that it's going to change any time soon. Finally, I feel like the old adage of two wrongs don't make a right comes to mind. After all, I think most of us can agree that what T-Online is doing is wrong. And you're advocating that more of us make the same wrong choice. What's more is that you're advocating to codifying this wrong choice in default configuration for multiple MTAs. I think that's an order of magnitude worse than the original wrong. So now I think we're up to 12 wrongs; T-Online's default block is 1st, your reactionary default block is 2nd, and your desire to codify this is another ten. P.S. Reach for / strive for better, don't settle for what we have. If at all possible don't make things worse. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Update: it's not. Re: T-Online is now really blocking messages from non-commercial and simliar senders
On 10/20/22 9:17 AM, Jaroslaw Rafa via mailop wrote: +1 Could you please repost this to appropriate Exim and Postfix mailing lists? -1 I believe providing a config which is enabled by default that rejects email from a provider is a disservice to the industry at large and will only promote fracturing things. Having the config there but remarked / commented out is something different. Let's promote being inclusive. We already have enough things working against us, see the recent oligarchies thread for an example. Let's not choose to divide things even more. Aside: I wonder if having a provider blocked by default is a form of defamation. I suspect multiple lawyers could retire on such a question /if/ we were to pay them to decide. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders
On 10/20/22 7:51 AM, Kai 'wusel' Siering via mailop wrote: Well, just use your ISP's submission service, problem solved. Or pay someone to MX you domain, problem solved. I don't agree that the problem is /solved/. Rather I think using such an external problem /changes/ or /moves/ the problem in such a way as to make DT/T-Online happy. Similar to how lines of credit don't /solve/ money problems, they simply time shift them. As a German, you have to have an imprint on anything that is considered a "service", yes, even on your personal, non-monetized blog. It the law ;) And also off-topic here. Please forgive ~> humor my ignorance, but what does the imprint / impressum (?) /need/ to have in it? Do imprints / impressums for brick and mortar stores include the CEO's personal information? Or, instead, do they include contact information for a company employee that can handle inquiries and connect them with the proper other internal employees on an as needed basis? Sort of like many businesses have an operator that answers phone calls and connects people with internal departments. This sort of seems like the quintessential $BUSINESS is licensed in $STATE and $LAWYER is the official point of contact that is common for a number of (above board) small businesses in the U.S.A. Would said $LAWYER's contact information in an imprint / impreessum suffice? Or is there supposed to be something more direct? I ask as I'm genuinely curious, not wanting to object. I'm trying to understand the laws / regulations / rules of business for another country on the common spinning body of water and rock riding through the solar system. Aside: I wonder if there is any use for the old Responsible Person DNS record or a TXT record for something like this. Obviously people would have to support it. I could see value in something like . being a TXT record that either provides the details or points to the impressum (e.g. URL). -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] mailop Digest, Vol 27, Issue 21
On 10/19/22 9:01 AM, Benny Pedersen via mailop wrote: imho same problem as i reported here https://gitlab.com/fumail/fuglu/-/issues/262 There may be a legitimate bug in the DKIM implementation /if/ it's signing things without the knowledge of the operator. That being said, over-signing is a concept in DKIM to protect against bad actors prepending additional instances of the header in question. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders
On 10/19/22 7:25 AM, Johann Haarhoff via mailop wrote: T-Online: the IP address is delegated to your provider and there is no owner data in the public whois record for your domain. Thus, the person or company who is responsible for this host is essentially anonymous to third parties. Therefore we would expect that there is a page giving full contact details which can be reached via http:// or http://www. Do you use privacy options in WhoIs for your domain name? Since you (understandably) obfuscated your domain name I can't check. I wonder if having real, non-privacy options, in a domain name helps with this. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Thread-Index header too long
On 10/18/22 8:28 AM, WIlliam Fisher via mailop wrote: I'm pretty sure DKIM wouldn't include the non-standard threading headers. /Default/ DKIM configurations probably don't include the threading header(s) (References & In-Reply-To). But it's certainly possible that they are included. That being said, I see that both References: and In-Reply-To: are included in the DKIM-Signature: of the message that I'm replying to. I've re-wrapped it to make it easier to read. DKIM-Signature: v=1; a=rsa-sha256; bh=2HJH0z8OPqiZSksYlT5t9QkCZyw3VikRfFdD5Blq7oU=; c=relaxed/relaxed; d=earthlink.net; h=from: reply-to: subject: date: to: cc: resent-date: resent-from: resent-to: resent-cc: in-reply-to: references: list-id: list-help: list-unsubscribe: list-subscribe: list-post: list-owner: list-archive; q=dns/txt; s=dk12062016; t=1666103332;x=1666708132; b=QSe+qudK+EvZiTVCfIIyY1ZZVBmtwmw1sEI1OSB0BRPEpgwr/IM41U43QjJNOOmku5a328ciBXHw1g3ncgL69gfnBrkXSAgcxavl6uQL7J2/3AbNe5w0Kj29w7mZpSPa/8YNMp8KkTaGCrN54EUWys2Zglz0a1EocvpRg3JjeJ99l66dKGxj0EJN7G/akyw26EXdjbbTy7OrNvVQn5z1vaFtLFZtsgmAAJRTsHRspoyaSlnAom7R5vBIUrd5ILqHKcrDpWV9KjsYmLl+pRv3dU57RaEt8VGrATwkfAbyJmTnF3uKNuM03K73NQ9ewWjIgkDhep3RRLesdgjPdrb0iA== Including the resent-* headers is interesting to me, seeing as how they aren't included in the message. I don't know if this was an intentional over-sign or over zealous configuration. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Thread-Index header too long
On 10/17/22 10:17 PM, Brandon Long via mailop wrote: Right, but you can't stick a non-compliant message into a DSN directly and have that be a compliant message... so you either make the non-compliant message compliant when you stick it into the DSN, or you figure that a sender who sends a non-compliant message can handle a non-compliant response. Are you talking about the 3rd and optional part of RFC standard Delivery Status Notifications, a.k.a. Bounces? -- I'm going to assume yes until corrected. First, the message that caused the ""bounce is optional. Second, why would you send the entire message (message/rfc822) in the DSN? There's too good a chance that you inadvertently send (as in originate a permutation of) -- at best -- questionable content. I'd think that you would want to only send the headers (text/rfc822-headers). Or are you talking about a completely new message that is a stand in for an RFC standard DSN but looks completely different? Either way, I see no reason to worry about altering the message. Send a sub-set of it (which is often sufficient to identify the original message) or don't send it. Either way, there's not enough to worry with DKIM validation of what was received by the mail system generating the DSN. And while this particular case of re-wrapping lines is fairly easy to fixup when generating the DSN, }:-) other cases like embedded non-utf8 8bit characters are more complicated... just auto-detect the language, convert to utf8 and embed in a message/global, I'm sure their system will know what to do with that ;) I would snarkily reply add the original message as a message/rfc822 attachment that is base64 encoded. Except Google has a propensity of disliking message/rfc822. -- For the longest time Gmail didn't support it. Or that you autowrap the lines to generate the DSN, and then bounce it for too longer headers, and they go "oh, your engineers can't even properly count the number of characters on a line, clearly there isn't a line here that's too long, let me add that to my manifesto" LOL -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Thread-Index header too long
On 10/17/22 9:11 PM, Brandon Long via mailop wrote: Certainly, but do you consider some edge cases like composing bounces or relaying messages as generating messages? Yes, generating a DSN is generation of a message. No, /relaying/ is not generating a message. I'm using "did the outgoing message exist before this server's involvement with it?" as the litmus test. We typically took a much harder line at "from scratch" messages, or places like MSA where we could safely fix messages. The current team seems to be imposing more strictness for their own reasons, so YMMV, but it's definitely safer to be strict on what you generate. "Be liberal in what you accept and be conservative in what you send." Also. "Brown M" Read: damned if you do and damned if you don't. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Thread-Index header too long
On 10/17/22 8:35 PM, Brandon Long via mailop wrote: The line length limit was clearly designed for a different time in terms of memory usage, and I think a lot of mail software has much larger workarounds for specific client/server bugs... I'd just raise the limit. I'd be okay with raising the line length limit /as/ /long/ /as/ it is supported by an RFC at some point in time. Even if that's an RFC that's written in the future to document the general consensus of the then email echo system. I'd personally be loath to /generate/ messages that exceed the current (then) standards. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Thread-Index header too long
On 10/17/22 4:02 PM, Heiko Schlittermann via mailop wrote: Hi, Hi, how do you deal whith incoming messages having a Thread-Index header ... with about 1200 chars. I can't say as I've had the (dis)pleasure of dealing with such. I would (try to) configure my MTA to re-wrap the logical line to conform to the physical line length limits set in RFCs; 1000 characters /including/ the trailing . The regular Exim config doesn't forward this (and probably can't bounce it, as a copy of the headers would make it into the bounce message, which in turn has an oversized header then too.) I would naively assume that Exim (or any contemporary MTA) could deal with logical (unfolded) header lines of largely any length. I would also assume that it would re-wrap any non-compliant physical lines to be compliant. On 10/17/22 4:11 PM, Heiko Schlittermann via mailop wrote: To be more precise: The one I have is 1000 chars w/o the header field name and w/o the line ending terminator. It then continues on the next (indented) line, which is ok. If it wasn't for the messages purportedly being from MS Outlook 16, I'd wonder if this was some sort of attack. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Certificate Question
On 10/14/22 10:41 AM, ml+mailop--- via mailop wrote: Almost no MTA cares about the certificate content unless explicitly configured to do so. Emphasis on MTA. I've witnessed Thunderbird, and heard tell of other /MUAs/, caring about the CertSubject and AltNames matching the name used to connect to said MTA. So MTA-to-MTA probably doesn't mater much if at all. However MUA-to-MTA probably does matter. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] The oligopoly has won.
On 9/29/22 9:59 PM, John Levine via mailop wrote: but nobody's ever had much use for notifications that "yes I delivered the mail" even though there's been a spec for that for a long time. I find that I use "RCPT TO:<...> NOTIFY=SUCCESS" about once a year for various reasons. Usually when I'm trying to confirm that the SMTP path between my server and as close to the recipient's server is not blatantly failing. Sometimes I get lucky and find that the message is handed off to the LDA. As such, I can usually rule out interim SMTP channel problems and go to the recipient / recipient's administrator and persuade them to look a little bit more than they did when offhandedly saying you're smaller than us so the problem must be on your end, go a way. How they actually say this varies. I usually also add ORCPT into the DSN. Likewise with "MAIL FROM:<...> RET=HDRS ENVID=..." because why not fully utilize DSNs if I'm going to the trouble of using them. Aside: Any time I write a client SMTP engine, I make sure to utilize them if I can. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] gmail: Benefit of a generic SPF-record?
On 9/29/22 1:42 PM, Jaroslaw Rafa via mailop wrote: But exactly because TLS is a TLD, which means both bad and good actors can register under it, you should not treat a whole TLD (any TLD) as a spam source. The operative /word/ there is "SHOULD". The operative /concept/ there is that each receiving server is allowed to do whatever they want to do. I've also seen many people talking about banning some of the newer -- let's go with -- vanity TLDs outright in order to avoid spam therefrom. I've also seen many people doing the same thing with IPv6. You should conside every domain under the TLD individually. See my operative concept comment above. }:-) -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DMARC Stockholm syndrome, Reject vs spam folders
On 9/16/22 4:32 PM, John Levine via mailop wrote: Yeah, that's the lousy workaround most people use to avoid DMARC breakage. I want to be crystal clear. I do not believe that the messages being /from/ /the/ /mailing/ /list/ to be a hack of any kind. Rather I believe that it is a first class solution and that what has oft been done for the last 30 years to be a cheat which is well past it's best by date. I am exchanging messages with the mailing list. It just so happens that the mailing list manager generates new messages with content substantively from messages that it receives. In some ways, you could compare what I'm advocating for to be akin to an application layer proxy receiving incoming email and generating multiple outgoing emails. Conversely most mailing lists are akin to (duplicating) NAT. For thirty years we all used mailing lists that didn't mess with the author's name or address, so you could easily reply eiher to the authors or the list There are many things through history that are considered questionable at best or out and out taboo. Smoking on planes, dumping sewage into the street, and many more. Just because we have always done it that way is never a sufficient reason to continue doing something that way. (and please don't mansplain to me what Reply-To does.) I won't. But I will say that I think that the way that most mailing lists use the reply to is broken. That stopped working when AOL and Yahoo repurposed DMARC to outsource the support costs of incoming spam due to their own security failures. Now I see it's been long enough that people are forgetting that this hack is a hack, and why nobody did it until events forced them to. I don't think that it's a hack. I think it's a failed attempt to treat the mailing list as a first class netizine. Consider, if you will, for 30 seconds the following: - The mailing list /is/ the (1st class) endpoint that you are communicating with. - The mailing list is effectively it's own (sub)domain; listname.example.net. - When you send / post messages to the mailing list; p...@listname.example.net, your messages are re-generated received, and re-sent, in duplicate, as being from y...@listname.example.net to each recipient's preferred address. - People can reply to the list; p...@listname.example.net, or directly to you; y...@listname.example.net. It's their choice. They have all the data they need to complete either choice. - The fact that messages com from y...@listname.example.net means that your real email address is not made public by the mailing list. - The list can act as an intermediate for spam to y...@listname.example.net and do a number of different things with it: - reject it if it's not from a current (or possibly former) list member. - queue it and send you a notification that there are queued messages for you to preview / release / reject / drop on the floor. In summary, promoting the mailing list to and treating it as a first class netizine has many advantages and seems to me to address most, if not all, of the complaints that I've seen with mailing lists and contemporary email / spam / virus filtering. So what you are referring to as a hack and going too far, I consider to be an incomplete implementation that doesn't go far enough. - No SPF problems with messages with an SMTP envelope originating from listname.example.net. - No DKIM issues with messages originating from pos...@listname.example.net. -- The only DKIM headers in the outgoing message are new for the new outgoing message. - No DMARC issues with messages originating from pos...@listname.example.net because SPF and DKIM are happy. - People have a valid email address to send messages to each other, via y...@listname.example.net and m...@listname.example.net - No need for Reply-To: hacks because the From: /is/ an address that the listname.example.net MX is responsible for. - No privacy issues introduced by the mailing list because it is the 1st class netizine that everybody communicates with. If you think this idea is crazy, I suggest that you take a good look at how Craigslist email works for contacting selelrs. In short, you will find a unique email address at Craigslist that is a 1st class netizine. Craigslist then send a new message, substantively based on your email to them, to the seller while sending the message as a different unique email address at Craigslist that (at least temporarily) routes back to you. -- Go look. Try it out. I think you will find that it works quite well without exposing any of your information. Consider treating a mailing list as the 1st class netizine that it is. Proxy the email at the application (RFC 822 internet text message) layer and stop NATing it at the network (RFC 821 SMTP) layer. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___
Re: [mailop] Reject vs spam folders
On 9/16/22 10:57 AM, John Levine via mailop wrote: Nope. SPF is somewhat useful as a signal that "this is real" but it is not useful, and -all is particularly not useful, as a signal that something is fake.* I understand why you say that and acknowledge that a lot of people say the same thing. However, as someone that has advocated for and has used SPF records that end in -all for more than a decade, I have to question the veracity of the sentiment behind your (and other's) statement(s) to that effect. Maybe I live in / am exposed to too small of a world to sufficiently appreciate things the way that some people do. There are way too many ways to send real mail that SPF cannot handle. Again, I question the veracity of that. Rather I think that there are ways to deal with it and that not everybody does sufficiently deal with it. I may be naive in my belief, but I do believe that you know how you operate your email better than I do, and that if you tell me that you only send email from X, Y, and Z, and that anything else is not from you, well, I'm going to believe you. As for all the nominally outsourced marketing, well I think that's misconfigured way too often. That's one of the reasons we have DKIM and DMARC, and we all know how much pain they have caused for mailing list mail that recipients actively want. That gets into a different disagreement. I'm sending this message to the mailop mailing list. I'm not sending it to you John L, or any other subscriber in particular. I view the mailing list as a terminal point. The email, as an SMTP envelope and contents, is between my MUA and the mailing list MUA. The mailing list is the terminus of the message that I'm typing. The mailing list is also a origination point of a new message substantively based on the contents of my message. But it is not my email. As such, I fully believe that the emails that the mailing list sends should be wholly from the mailing list, perhaps with my name in the human friendly part of the from address while the actual email address reflects the mailop mailing list. -- I say this to say that in my head, SPF, DKIM, and DMARC are all perfectly compatible with how I believe things should work. Anything that falls short is a misconfiguration /in/ /my/ /opinion/. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Reject vs spam folders
On Sep 15, 2022, at 9:57 PM, Cyril - ImprovMX via mailop As someone whose addresses is regular forged in spam: NO. On 9/16/22 7:18 AM, Bill Cole via mailop wrote: +1 I thought that we were to a point that SPF was mitigating a lot of out-and-out forgeries. At least between purported senders that publish sufficiently strict SFP records and recipients that honor said SPF records. Don't do reporting without a *trustworthy* explicit request to do so from the owner of the address being reported to. ARF reports to randomly forged putative senders is not going to go well. I wonder if there's room to leverage ~> extend DSN's NOTIFY to add an ARF option wherein this is a flag to the last responsible mail server to conditionally send an ARF if the message is not accepted / delivered normally. Wherein the condition would look up information on the purported sending address / domain to see if it should send an ARF and the details therefor. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Reject vs spam folders
On 9/15/22 2:51 PM, Cyril - ImprovMX via mailop wrote: So basically, what would be interesting to have is both : land the email in the spam folder but notify the sender about if, maybe via an ARF report ? I think this would be a slippery slope and leak information, akin to "your password is wrong" vs "your username or your password" is wrong. I could see some benefit for enabling ARF (like) reports when there is evidence of bi-directional communications between two emailing parties. E.g. the candidate sent their application and a recruiter replied asking for more details. This bidirectional pairing could serve as an indication that it's probably safe to send an ARF (like) report to the candidate without revealing too much information. Maybe an algorithm as simple as up to one ARF to a sender per outbound message to them. But, as they say, "there be dragons", related to many technical / procedural / policy details. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
