Re: [mailop] Reason for being listed at Spamhaus CSS and XBL unclear
Dnia 19.04.2024 o godz. 14:25:49 Grant Taylor via mailop pisze: > > I wonder if TCP connections were being fully established. Is there > a chance that someone was spoofing your IP? I was also thinking this. > Could he produce packet captures for you to analyze? Sadly no. > Is there a possibility of a compromised CPE that's hijacking the IP? My server is a VPS at a hosting company, so I don't think so. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Reason for being listed at Spamhaus CSS and XBL unclear
Dnia 19.04.2024 o godz. 10:47:56 Sebastian Arcus via mailop pisze: > In a sense I haven't managed to make further progress with this. > Spamhaus have been very vague about the problem - which to some > extent I understand as they don't want the bad guys to exploit their > systems. But at the same time, their latest correspondence keeps on > dropping hints about port 25 - which doesn't make any sense, as port > 25 outbound has always been blocked on this network - so in that > case the blacklisting should have never happened. I've just tested > yesterday again - and not only I can't do outbound port 25 > connections from inside the network, I am getting, as expected, > automatic warnings from the server when the attempts happen - which > I configured a long time ago. This reminds me of an issue I had about a year ago with one of the members of the Postfix mailing list. I wanted to reply to him directly and it turned out my server got firewalled on his server, apparently - as his logs did show - for some strange (non-SMTP) traffic coming from my server. 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 was never able to find out what was going on. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Off-Topic - VMWare ESXI 7.0
Dnia 16.04.2024 o godz. 06:47:44 Bruno Flückiger via mailop pisze: > Similar products are Microsoft Hyper-V, Oracle Linux Virtualization > Manager (OLVM), Proxmox and Nutanix. Each one of these products has > some shortcommings compared to VMware. If you don't need a GUI to > manage your virtual environment you might consider using KVM (Linux) > or bhyve (FreeBSD) as hypervisor. You can very well have a GUI when using KVM - virt-manager is a very nice piece of GUI to manage virtual machines running under KVM... Of course it's not a web-GUI, ie. virt-manager is just an ordinary X application running on the host OS (I routinely use it remotely, from my desktop Linux PC which has a full X desktop running). -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Debt Collection Client Email Servers
Dnia 25.03.2024 o godz. 16:10:47 Rob Kendrick via mailop pisze:
> > The problem I am trying to fix is that these are legal emails and I
> > need a way to signal that to the providers. With many states and USA
> > government stating that email is a legal form of communication, how
> > can we guarantee it to the inbox if many of the users mark it as SPAM
> > and potentially blocks other communication.
>
> You can't. If you want to make sure they receive an important legal
> communication, send them a recorded delivery letter. At least then you
> have evidence of its delivery (or lack of).
Does USA have a government-certfied platform for electronic delivery of
documents (like many European countries have) where every person can create
a "trusted account" ("trusted" means the identity of the person is confirmed
in some way based on some documents the person provides) and then have such
legal communications delivered to their "trusted account" and not via
e-mail?
Such a thing would be the best tool to use in such scenario.
--
Regards,
Jaroslaw Rafa
r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] [spamhaus] de-listing requests successful, but only for a couple of days.
Dnia 17.03.2024 o godz. 16:17:10 Hans-Martin Mosner via mailop pisze: > >My current ISP (BTW, one of the biggest cable providers in Europe, you can > >probably guess which one it is) currently provides by default an IPv6 *only* > >connection to the home users, even if you have IPv4-only devices in your > >LAN. They use the solution called DS-Lite: the modem/router they lease to > >you does an IPv4-over-IPv6 tunnel(!) to some point inside the ISP's network, > >where the packet is decapsulated, a CG-NAT is done to some public IPv4 > >address and the connection continues via IPv4 to the target address. IPv6 > >connections just pass through unchanged. > > I would prefer to avoid going through a NAT, but for most home users this > is probably not an issue. With my ISP, you can request to switch your connection from IPv6 only to dual-stack IPv4 and IPv6, then you get a public IPv4 address and NAT is performed at your home modem/router (you can then control it, do usual port forwarding stuff etc.). This does not differ from any other ISP, where you usually also get a single public IPv4 address and must do NAT. > My point is mostly that it's quite possible to get IPv6 if you want, > most small or medium organizations just don't have the expertise to > do it, and the providers are not very helpful. Well, doesn't the fact that the provider I'm talking about (and it's a really very big one) is *mostly* IPv6 based, somehow contradict that? -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [spamhaus] de-listing requests successful, but only for a couple of days.
Dnia 17.03.2024 o godz. 08:30:39 Hans-Martin Mosner via mailop pisze: > does IPv6 (not exclusively though), and I've been trying to usher in > the future by setting up at least dual stack on my home DSL > connection (that at least works now after years of IPv6 routing > issues with my previous home DSL and no way of contacting tech-savvy > support there) and in our company (where I set up an IPv6 tunnel > which worked until the tunnel provider closed shop). I don't quite understand what exactly the end user has to do to have dual stack on his home connection. The ISP either provides IPv6 to you or not, there's nothing to do for you. My current ISP (BTW, one of the biggest cable providers in Europe, you can probably guess which one it is) currently provides by default an IPv6 *only* connection to the home users, even if you have IPv4-only devices in your LAN. They use the solution called DS-Lite: the modem/router they lease to you does an IPv4-over-IPv6 tunnel(!) to some point inside the ISP's network, where the packet is decapsulated, a CG-NAT is done to some public IPv4 address and the connection continues via IPv4 to the target address. IPv6 connections just pass through unchanged. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] mailop and DKIM signatures
Dnia 16.03.2024 o godz. 16:57:54 Andy Smith via mailop pisze: > On this list one might argue¹ that we all have MUAs capable of > filtering etc. without subject tag and that we all know where the > mail came from without an explanatory footer because we know to look > at List-* headers. So maybe there is a better argument here for > doing away with all of that in an effort to preserve DKIM > signatures. I prefer to have the subject tag on the list mail, because if I would automatically filter list mail to some specific folder, I would often end up not reading that mail at all. The fact that the mail stays in my main inbox *makes* me read it, and only after reading move it manually to the folder dedicated for that list. However, I don't consider the added list footer in the message body to be useful in any way. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Google unsolicited mail rejected with 421
Dnia 16.03.2024 o godz. 13:08:52 Benny Pedersen via mailop pisze: > > bingo its why its tempfailed, gmail should redesign how to handle > maillists where message-id can come to inbound on gmail, should not > count on message-id abuse counts Well... from Google's point of view, it seems like a pretty effective mechanism to force people to move to *their* mailing list service, instead of running mailing list themselves... A monopoly wants to be a monopoly. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] freenet.de routing issues anyone? (Cloudflare-OVH issue?)
Dnia 8.03.2024 o godz. 12:45:18 Paul Gregg via mailop pisze: > I can confirm your observations. I can't see their NS from my OVH box, > nor can I connect to port 25 of the 3 IPs behind their MX. > From home (UK broadband), I can see and query DNS servers, but I can't > talk to port 25. > From non-home/non-ovh, I can see DNS and talk to port 25. I can confirm as well. From my server (hosted at OVH) I can't even query their domain, nor can I ping the address you mentioned (194.97.8.138). From my home computer, both DNS query and ping work OK. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Filter out emoji from email adresses
Dnia 7.03.2024 o godz. 13:12:27 Julian Bradfield via mailop pisze: > > If you have a mail client that is so badly written that it crashes > when it encounters a missing character in a font, you need to replace > or fix the mail client, or file a bug report against the library > causing the problem. An emoji is just another character. +1 -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Contact of postmaster for hostedemail.com domains
Dnia 26.02.2024 o godz. 10:50:44 Grant Taylor via mailop pisze: > 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. Fully agree. That's why I mentioned it at all. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Contact of postmaster for hostedemail.com domains
Dnia 26.02.2024 o godz. 10:19:54 Kris Deugau via mailop pisze: > Also try getting your recipients to complain to their mail hosting > provider - complaints from the people who want to *receive* the > message are far more effective than complaints from the sender. The typical reaction of an average recipient when they aren't getting mail they expect is to contact the *sender* (in any way they can, eg. by phone) with a request like "could you please send it to me some other way, because I haven't got the email". The *last* thing they would like to do is to complain to any mail provider. They just take it for granted that "it is so" that the recipient sometimes doesn't get the email, and you have to live with it. At least that's what I see all over from my experience. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] One click unsubscribe in mailing list messages
Dnia 24.02.2024 o godz. 13:16:45 Anne P. Mitchell, Esq. via mailop pisze: > > pointing out that Federal law mandates a one-step method; completely Not everybody is located in the USA, and "federal" law has no meaning to those who don't. > two-step method, even though a one-step is implicit in the law's "visiting > a single Internet Web page" (i.e. having to click 'submit' on that page > takes you to a second page, making it not 'visiting a single Internet Web > page") That's simply not true. I routinely write scripts that after clicking "submit" take you back to the same web page, ie. to the same URL. The content on that page, however, doesn't need to be the same :) That's actually the default behavior of a form if you specify an empty ACTION="" attribute in the HTML FORM tag. You can also write the script so that it doesn't leave the page at all after clicking "submit", and only sends the data internally to the server using AJAX and displays the response that is received back, all without ever leaving the page. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Dnia 15.02.2024 o godz. 10:54:56 Philip Paeps via mailop pisze: > > Having said that: I have seen S/MIME and even PGP signed spear fishing. I'd dare to say, that aginst *spear* phishing there is no viable technical protection. The only protection against this is common sense and awareness of the user. If a phisher is targeting the particular recipient, he does it for a reason. So he always finds a way - one or another - to reach his target. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Dnia 12.02.2024 o godz. 14:47:41 Sebastian Nielsen via mailop pisze: > When you pass traffic on layer 7, you are the de facto recipient of the > traffic, and when you then “resend” that received traffic somewhere else > than its actually destined, you become responsible. That’s why a reverse > proxy operator becomes responsibility for content he “host”, even if that > is just forwarded requests to a third-party. Don't think in terms of network layers. Think at one level above the network layers :), on the level of conceptual integrity and flow of the communication as a whole. We may call it a philosophy of communication. We have four parts to any communication: both parties that are communicating, communication channel (which may include proxies, forwarders etc. - it's not important at philosophical level) and the message itself. The communication is integral and true if both parties know who are they communicating with (ie. none of the parties is mis-represented) and the contents of the message is not altered. If you are hiding the original IP that is behind a proxy, you are mis-representing one of the parties, so you are modifying the communication. (BTW. As far as I remember from setting up Squid, it adds the "X-Forwarded-For:" header by default, you don't need to configure anything special. So it's not true that "all proxies are anonymous by default".) Similarly in reverse proxy case you are mis-representing one of the parties, because you are posing as someone else. You make the message apparently come from your domain, while in fact it comes from another source. You are pretending you host the contents, even if you actually don't host it. Which you shouldn't be doing, because you are just a part of a communication channel. And it doesn't matter if you do it on layer 7 or on lower layers. If you are just passing on the message, without modifying its contents, and without mis-representing neither sender nor recipient of the message (note that a "traditionally" forwarded email has both From: and To: headers indicating the original sender and recipient!), you are just a part of a communication channel, and, from logical point of view, you shouldn't have any responsibility. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Dnia 12.02.2024 o godz. 14:44:43 Sebastian Nielsen via mailop pisze: > > Nope, you just open the encapsulated email (open the .EML attachment), and > respond to that. Very cumbersome. Speaking from my own experience. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail blocking
Dnia 10.02.2024 o godz. 11:18:17 Al Iverson via mailop pisze: > That error message, though, makes it sounds > like IP reputation which is a rare error. Actually, it has been mentioned here on this list several times. It usually happens "out of the blue", for servers that were able to send OK previously, and seems to have no obvious reason (I also had this issue a year or two ago), and it usually disappears by itself after a few days, a week or two. Seems like some glitch in Gmail filtering logic. I suppose that logic has gotten so complicated that nobody at Google is actually able now to determine how it really works. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Dnia 12.02.2024 o godz. 12:15:08 Sebastian Nielsen via mailop pisze: > > However, if an end user SENDS something via the proxy, let's say a forum > post, the proxy usually bears the responsibility for the content, which we > have seen in numerous court cases where a proxy have been used to hide the > origin of illegal content, where the proxy owner have knowlingly been a > forwarder of such a content (eg, been negligent and refusing to for > example block forum posts from his proxy). Which is fundamentally wrong. An "anonymous" proxy, configured specifically to hide the original poster is a totally different thing and you should not mix it in here. Such a kind of proxy is *actively modifying* the communication, so of course its owner bears responsibility - it was his deliberate decision to modify the communication. Like in the case your described, when a HUMAN user MANUALLY forwards mail and modifies the headers or encapsulates mail in another mail - it was his deliberate decision to do so, and he, not the original sender, bears responsibility for the forwarded (MODIFIED) mail. Let's talk about regular proxy that doesn't hide the originating IP. The same applies for regular automatic (not manual) mail forwarding. A proxy job is by definition to pass ANY traffic, NOT to block anything. Pass it in as unchanged form as possible from the purely technical point of view. Of course, the proxy can deny access altogether to the user who is not authorized to use the proxy. But if user is allowed, the proxy should NOT mess with traffic. Like the telecom operator job is to pass any traffic and not to block anything. If telecom operators block anything (and we know they do), even if it's required by law, that only means that this law is nonsense and against logical reasoning. Nobody who is an intermediate link in a communication should mess with the contents of the communication. Only the end receiver has a *logical* (let's put legal aside) right to reject/block/filter anything. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Why is mail forwarding such a mess?
Dnia 11.02.2024 o godz. 00:10:54 Thomas Walter via mailop pisze: > Remember when we had an SMTP status code 551? > > 551 User not local; please try Would be an ideal solution if sending SMTP servers would actually react to it like web browsers react to HTTP 301 or 302 status code, ie. automatically resend mail to specified . -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Why is mail forwarding such a mess?
Dnia 10.02.2024 o godz. 07:52:43 Sebastian Nielsen via mailop pisze: > Try it yourself in your email software. > Click Forward. > Sending this email will basically rewrite the headers and add Fwd: into > subject. > > You can also click "Forward as an attachment", which will forward the > original email unmodified as a message/rfc822 object. > > This transfer the responsibility for the message to the forwarder, which > means all DKIM, SPF and DMARC signatures are verified against the > forwarder and not original sender. Which is true and correctly reflects the actual reality in the case you describe, ie. if a HUMAN, MANUALLY, KNOWING the message contents, forwards an email to someone. The automatic forwarding by the server is a completely different thing. Conceptually, it's more like a HTTP proxy server. One cannot claim that the owner of the proxy server assumes any responsibility for the contents of webpages fetched via the proxy, and similarly one cannot claim that forwarder assumes any responsibility for the CONTENTS of the message in this case. So the message definitely should keep the original sender's From:. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Why is mail forwarding such a mess?
Dnia 10.02.2024 o godz. 12:42:36 L. Mark Stone via mailop pisze: > 1. We have trained our Zimbra users who want their email to be copied > someplace else to configure the someplace else to log in and collect their > email from Zimbra, after having educated them that Forwarding is > problematic and can get their domain blocklisted. That isn't and never will be an alternative to forwarding, because it requires to give the "someplace else" the credentials for the account you are collecting mail from. This is unacceptable in MANY situations. > 3. Zimbra's web client has a nifty "Edit As New" option that, instead of > Forwarding an email, copies the entire body of the email thread into a > newly-composed email. Once we train users to do this instead of > Forwarding, everyone is much calmer and they notice their Deliverability > improves. Someone claimed in a sibling thread that mail forwarding is "forging". What you propose is no doubt an ACTUAL forging. I would never use a mail provider that recommends such things to their customers. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Dnia 12.02.2024 o godz. 01:36:09 Benny Pedersen via mailop pisze: > if spf should be pr email addresses, thay could add ipv6 pr sender > email :=) > > and have ipv4 with nullMX or simply remove ipv4 in mx, will it ever > happen ? Yeah, use only IPv6 for sending mail and cut off deliverability to half of the Internet. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Dnia 10.02.2024 o godz. 05:02:12 Sebastian Nielsen via mailop pisze: > Disadvantages --> Every email will look like an empty email containing a > attachment that you have to click to open. Many antispam filters will right away classify such an email as spam. > Also, that’s how forwarding ALWAYS have work when you press the "Forward" > button (and "Forward as attachment" is the message/rfc822 way) in your MUA > and have always worked with SPF and DKIM for decades. > So why shouldn't we adopt it also for server-configured forwarding? Because these are two different things. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Dnia 9.02.2024 o godz. 18:06:41 Slavko via mailop pisze: > Hmm, and are you sure that regular users know what S/MIME is and > are able to reliable distinguish email with and without it? I don't think > so... While they are probably not capable of signing S/MIME mail (which requires getting your personal certificate in the first place), they don't have to do *anything* to verify S/MIME on incoming mail if they use any decent mail client, because the client verifies it for them automatically and displays the verification result prominently next to the message, in a quite clear and obvious way. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Dnia 9.02.2024 o godz. 07:13:31 Marco Moock via mailop pisze: > S/MIME exists and I really don't understand why banks and online shops > don't consequently use it. I must say that my bank is and always was using it. Same for my phone provider. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Dnia 9.02.2024 o godz. 13:03:28 Philip Paeps via mailop pisze: > > Most people don't actually use email anymore. Email is for > marketing and receipts. Yeah, that's probably the main reason why they can live with such problematic service like Gmail. I have heard numerous times from Gmail users that they "just didn't get the email from someone" and they treat it as something normal, that the email just got lost somewhere. In such cases they try to arrange the communication some other way, eg. using Facebook Messenger or any other similar tool. They don't have the attitude (which I am very committed to) that email is something very basic that just "has to work", and if a message gets lost somewhere, it's at least a case that needs investigating, and not just taking it for granted. But sadly it's not a common attitude nowadays. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Dnia 9.02.2024 o godz. 06:58:40 Marco Moock via mailop pisze: > Not possible if some receivers require SPF, like Google for bulk > senders. > One possibility is to add ?all instead of -all. That makes it possible > that sites that check SPF and reject on -, but accept no SPF, will > accept the message. -all is never a good idea, but I had problem with deliverability to Google also when using ?all, despite the fact that I'm in no way a bulk sender (I already described my problems several times here - Google files all mail from my domain to recipients' spam folder). I seem to have better results with ~all (mail is less often going to spam). -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Dnia 8.02.2024 o godz. 11:49:39 Kai Bojens via mailop pisze: > > Google wants you to use ARC for forwarded mails: > > https://support.google.com/a/answer/13198639?sjid=7229117128739116669-EU I don't see anywhere on this page a statement that you must (or even should) use ARC. It only describes what ARC is and how it can be used. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Dnia 7.02.2024 o godz. 20:51:15 Jarland Donnell via mailop pisze: > Nearly 100% of > users who forward email do so because they want it in Gmail. I am always wondering - as Gmail gives so many problems that have been discussed multiple times - why anybody who has another mail account would want to use Gmail, and moreover - have his mail forwarded to Gmail? I would definitely do it in the reverse direction... Gmail's web interface is just horrible, completely inefficient to use (and I say this as a person who must use Gmail at work, as our company email sits there - it is feasible only via a regular IMAP client, I wouldn't be able to work with it if I had to use its web interface). And if somebody uses a regular IMAP client, what difference does it make if it's Gmail or another service? -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] problem setting up open-dmarc
Dnia 7.02.2024 o godz. 14:41:02 Andreas S. Kerber via mailop pisze: > > This only applies if your sending more than 5000 messages per day. That is a "MUST" in RFC sense ;), because otherwise they reject mails from you. But if you read their sender guidelines, they say since long ago (long before they start enforcing the limit above) that *every* sender (regardless of volume they send) SHOULD (again, in RFC sense ;)) have SPF, DKIM *and* DMARC set up. If you have a delivery issue with Google (eg. like in my case when my mails are constanly filed to recipients' Spam folders) they require you to fulfill all the mentioned guidelines (including having DMARC set up) before you submit an issue to them (which usually doesn't get resolved anyway... :() > Most smaller senders are still fine using only "SPF *or* DKIM" and do not > *need* a DMARC record: My experience says otherwise. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] problem setting up open-dmarc
Dnia 6.02.2024 o godz. 15:13:47 Michael Peddemors via mailop pisze: > Some days.. it's like F* DMARC.. hehehe.. > > Anything that created a multi-million dollar industry of consultants > on how to set up DMARC, well.. email should NOT be that difficult.. > > I still remember when email administrators didn't know how to set up > DNS correctly.. (oh wait, some still do) > > You went the path of SPF, and even went a step farther with DKIM.. I > would not sweat DMARC yet.. (next it will be the rest of the ARC > stuff) > > I know, probably not a popular opinion on this list but.. IMHO > > Unless you are a big budget email sender, don't stress to much. > Maybe tomorrow we will need something like DMARC, but thankfully not > yet today. Are you talking about incoming or outgoing mail? For outgoing, Google requires that you have DMARC record set up. So if you are sending anything to Google, you need that. For incoming, I agree, you don't have to bother with DMARC (In fact, I don't check also SPF nor DKIM on incoming mail - DNSBL, manual blacklists and content filtering are completely enough to filter out spam). -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Support contact for Shaw.ca
Dnia 6.02.2024 o godz. 15:26:33 Aric Archebelle-Smith via mailop pisze: > Beginning in late January, we received user reports that mail was not > being delivered to Shaw.ca addresses. Users did not receive a > non-delivery notification, but our logs show the following rejection: > `status=sent (250 2.0.0 xxx...@pobox.com sender rejected.)` Wonderful nonsense. Status code 250 and "sender rejected". -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DMARC on srs forwarding domains?
Dnia 3.02.2024 o godz. 13:34:43 Philip Paeps via mailop pisze: > (There is something to be said for hard-enforcing specifically > "v=spf1 -all", but policies with anything between the v=spf1 and the > -all are overwhelmingly configuration errors, and should only count > for scoring.) I am glad that someone has the same point of view as mine. I was always saying that while "-all" as the *only* entry in the SPF record should be strictly obeyed and the mail rejected, rejecting due to "-all" if the SPF record contains other entries as well is wrong and should not be done. Yet they are still many who do... :( -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamfolder mini rant (Was: Contact Google Postmaster)
Dnia 28.01.2024 o godz. 22:04:26 Jay Hennigan via mailop pisze: > Conversely, when the receiver purges everything else in the spam > folder without opening it, this gives feedback that the decision to > route it to spam was correct. And this is often the problem, because - as I mentioned - users tend to think that spam folder is something they don't need to look at, because "by definition" everything in it is spam. Thus, if a (non-spam) sender once lands in spam folder and is never "pulled out" from there, a false signal is given to classify further messages from that sender as spam, and thus a sender falls into a positive feedback loop, continually increasing their rating as spam, which is almost impossible to get out of. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamfolder mini rant (Was: Contact Google Postmaster)
Dnia 28.01.2024 o godz. 23:44:29 Scott Mutter via mailop pisze: > What if the receiving mail server tagged the message in some way in their > final acknowledgement of the message. For Google. instead of: > > 250 2.0.0 OK 1706409809 > h4-20020ac8584400b10427e71c979dsi9837397zyh.449 - gsmtp > > If the message is redirected to the user's spambox, the message could be: > > 250 2.0.0 OK 1706409809 > h4-20020ac8584400b10427e71c979dsi9837397zyh.449-spam - gsmtp > > Or provide some number attached to the ID that identifies how much > spamminess the receiving mail server thinks the message is. Or at least include some information in the DMARC report they send, how many messages have been classified as ham or spam... -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamfolder mini rant (Was: Contact Google Postmaster)
Dnia 27.01.2024 o godz. 13:21:46 Thomas Walter via mailop pisze: > > To me it just doesn't make a lot of sense to basically have two > inboxes to check - the regular one and the spamfolder. > > Also having to tell people to check their spamfolders every time > they are missing an email is annoying too. > > I'd rather know that my email was considered spam than trying to > figure out why someone did not reply after a few days. At least that > would give me a chance to use a different contact method or try to > resolve the issue in the first place. > > Yes, I know, spamfolders are used for training, but perhaps there > should be other ways? There are "edge cases" when the mail couldn't be reliably classified as spam or non-spam. Even with best tuned spam filtering systems false positives will happen. If the mail provider isn't *extremely* supportive to their users with regard to fine-tuning the spam filtering rules, spam folder is a good solution for these edge cases. Rejecting should be reserved only for "obvious" spam, for example if your spam filtering system (whatever it is) gives a message a score above 10, it is rejected, if below 5 - it goes to the inbox, but between 5 and 10 it goes to the spam folder. Just having a binary distinction - reject or deliver to inbox - would be a much bigger obstacle to communication than delivering to spam folder, because it's still easier to reach the recipient in some different way and tell them to check the spam folder, than to make the recipient's provider fine-tune their email filtering to exempt you from rejection. I had only once encountered an email provider where process of lifting the block was very easy and almost effortless - it was mail.ru. I wrote a message to one user there and it was rejected, with a link to a page that contained a very simple form I needed to fill in to have the block lifted. I did and in a couple of hours I got an email saying that I was unblocked. If everyone behaved like that, I would be very much supporting your stance - either deliver to inbox, or reject. But the fact is that with most recipients, if your message is rejected, you can't pretty much do anything about it - at least it isn't quick and easy. So the spam folder is still a better solution. Of course, the users should be aware that they *should* check the spam folder, which means, the provider should inform them about this with a very clear and prominently visible message. Sadly, most providers don't do it, therefore the users are convinced that they don't need to check the spam folder at all, since it's clearly labelled "spam" or "junk", so "by definition" it cannot contain anything useful to them. This is a main problem in my opinion. The providers should clearly inform users, that there MAY be non-spam messages in the spam folder, and if they don't want to lose mail, they SHOULD check that folder. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM signed with parent domain
Dnia 26.01.2024 o godz. 22:06:44 Gellner, Oliver via mailop pisze: > Independent of this I wouldn’t use r...@hostname.example.org as a sender > address to external recipients. This doesn’t look professional, makes > replying to those emails impossible 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. While you are obviously right about the unresolvable domain case, but if hostname.example.org is resolvable (and if that host is a MX for example.org, it will be), what makes you think that replying to an email from r...@hostname.example.org is impossible? In the past I've done it dozens of times and it always worked. Unless of course root account was configured to reject mail, but this is not a common configuration. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Extortion spam from OVH-hosted *.sbs domains
Dnia 25.01.2024 o godz. 22:00:08 John Levine via mailop pisze: > > As I may have said once or twice before, when you pick the cheapest, > crummiest option, often you get what you pay for. s/the cheapest, crummiest option/the option you CAN actually afford/ Certainly you, John, are not the person who needs to be taught about the fact that Internet is not only an American thing, and even more - it's not only a "Western" thing, and that there are HUGE economic discrepancies between countries in the world, as well as different financial regulations, different currencies etc. But even people who have extensive theoretical knowledge often fail to actually apply it when it comes to practice. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Extortion spam from OVH-hosted *.sbs domains
Dnia 25.01.2024 o godz. 07:10:13 Hans-Martin Mosner via mailop pisze: > It's probably pointless to call for a general OVH boycott, as much as I > would like to do that :-) I would be the first to object to that, because my server is hosted at OVH :) -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is Google jumping the gun for SPF / DKIM requirement?
Dnia 24.01.2024 o godz. 21:48:39 Grant Taylor via mailop pisze: > > 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. Apparently they started to do it quite a time ago, not only 8 days before... -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [External] seeking a spamtrap milter
Dnia 24.01.2024 o godz. 11:57:13 Randolf Richardson, Postmaster via mailop pisze: > > But, in reality not really worth the trouble.. domains are easy to > > forge, and innocent companies maybe trying to verify the address, > > because a bad guy used it in a contact form.. > > Not when SPF/DKIM/DMARC are configured properly. Unfortunately, you > are generally correct because many domains that are actively used for > legitimate eMail don't employ SPF/DKIM/DMARC to prevent forgeries. :( As far as I understand, this staement was referring to *receiving* domain, and not the *sending* domain - especially that "contact form" is mentioned. The OP wants to process messages *received* by domains that *should not be mailed to* and use these messages to feed a spamtrap. The "domains are easy to forge" statement referred - in my opinion - to the fact that some malicious actor can put an address in this "not-to-be-mailed" domain for example in a newsletter subscription form on a completely legitimate website. That website will send a confirmation message (which will be properly SPF/DKIM/DMARC autenticated) to a "spamtrap" address, thus ending up blocked. -- Pozdrowienia, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamhaus contact?
Dnia 19.01.2024 o godz. 12:42:49 Randolf Richardson, Postmaster via mailop pisze: > UCE Protect also has level 3 listings for the worst offenders, > although I don't recall the list being downloadable for firewall use: > > UCEPROTECT Blacklist Policy LEVEL 3 > https://www.uceprotect.net/en/index.php?m=3=5 UCEPROTECT Level 3 is totally unreliable and gives a lot of false positives. UCEPROTECT themselves ever warn against using this list for blocking. Nobody should be seriously using UCEPROTECT levels 2 and 3. Only level 1 is something that has any reliability. Also, many email operators consider UCEPROTECT being just a money-making scheme, as it is very easy to get listed by them and they request large fees for so called "express delisting". -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Samsung and SIZE
Dnia 15.01.2024 o godz. 07:54:47 Sebastian Nielsen via mailop pisze: > Problem is, that when MUA or first MTA has a incorrect date set, the email > comes like last in inbox... have seen emails set with 1970-01-01 00:00:00 > Or, even worse, it has a date that is like, several months off, so you > have to SEARCH your inbox after that unread email that was popped into the > middle. The solution to the problem is, use a MUA that auto-positions on the FIRST UNREAD message when opening the inbox... Many MUAs have that feature, and it helped me many times to not miss the email, even if it has a date set to many days backwards... -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Displaying logos
Dnia 15.01.2024 o godz. 08:07:28 Sebastian Nielsen via mailop pisze: > A better solution would otherwise to make a BIMI extension to SMIME in > that case, that will override the server BIMI in SMIME signed emails. > Where the BIMI logo becomes part of the SMIME certificate by an > non-critical extension. (SHA512 hash + URL of BIMI logo) That's probably the best idea, because BIMI will then become simply an additional feature to something that is actually useful (S/MIME certificate). This may also promote use of S/MIME for actual end-to-end email authentication, which undoubtedly *is* the most reliable from of email authentication, but is very rarely used today. Going through all this process you have described just to get a BIMI-validated logo seems still a waste of time and effort for me. We return here to the original question: what is the actual added value that BIMI gives? For me it looks like a typical case of "solving a problem one has first created themselves", ie. first we create another artificial barrier of entry for someone wanting to operate own email server, that by itself gives little to zero added value (the value does not justify the effort needed to set it up), and then we try to find a solution to make that barrier of entry "lower" and less obtrusive. Instead of returning again and again to the question, is this barrier of entry actually needed at all? And a final remark regarding your draft: believe it or not, but there *are* people in the world who want to run their own mail server, but do not use - and do not want to use - smartphones. So, no NFC or QR code scanning. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Displaying logos
Dnia 13.01.2024 o godz. 16:58:27 John Levine via mailop pisze: > > That's why it's not silly that BIMI tries only to show legit logos, even > though > it makes it impractical for anyone other than largish organizations. Which brings us back to my original point - which you now have confirmed - that BIMI is not practically feasible, as you can't *force* MUA developers to have *only* BIMI-validated logos displayed. In fact, quite the contrary is very probable as I doubt that email apps that are already showing avatars would give up on them in favor of displaying *only* BIMI logos. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
Dnia 12.01.2024 o godz. 13:23:07 Todd Herr via mailop pisze: > There is no such thing as "BIMI-authenticated". BIMI isn't authentication, > and doesn't claim to be. I quote from the Abstract of > https://datatracker.ietf.org/doc/html/draft-brand-indicators-for-message-identification > > BIMI permits Domain Owners to coordinate with Mail User Agents (MUAs) to > display brand-specific Indicators next to properly authenticated messages. > There are two aspects of BIMI coordination: a scalable mechanism for Domain > Owners to publish their desired Indicators, and a mechanism for Mail > Transfer Agents (MTAs) to verify the authenticity of the Indicator. > > The "scalable mechanism" is the DNS, and the "mechanism for MTAs to verify > the authenticity" is the Evidence Document, a.k.a., the VMC. And that's what I call by a shortcut "BIMI-authenticated". A properly authenticated message that also conforms to the BIMI spec and has a validated logo (VMC). In other words, a message that is qualified to have the logo displayed, according to the BIMI spec. Let's step aside a bit from the technical details and conformance to the specs and return to the basic question I'm asking from the very beginning, a question that needs to be viewed in "big picture" and not only in terms of conformance to the specs or what piece of software does what. Let's look at the whole *system*, as it is done in system testing, and try to test the design from the end user point of view. The question is: What problem is BIMI supposed to solve, and/or what benefits it gives to the user? From the very paragraph you quoted above, the answer is more or less so: it allows for displaying of *verified* logos alongside messages, which can serve as a visual signal to the user that the message is genuine. I emphasized the word *verified*, because the whole sense of BIMI depends on this very word. If the logos are not verified, their presence or absence isn't any useful signal to the user. So, if a MUA (it's not important at the moment whether it is a mailbox provider's webmail client, or some independent application - *something* has to display these logos anyway), displays besides verified BIMI logos also other logos, obtained by different method from a different source (for example Gmail profile pictures as it is today), we have exactly this case - the presence or absence of logo says nothing to the user with respect to whether the mail is genuine or not. The user can get a similar visual experience with a spoofed message that has a logo obtained eg. from someone's profile picture and with a legitimate message that has a verified BIMI logo. And that was the whole purpose of BIMI, that the presence of the logo should help distinguish real messages from the fake ones, right? In other words, the design fails the end-user test case at this point. So if a MUA displays other logos besides verified BIMI logos, it effectively defeats the purpose of BIMI. The "big picture", high-level purpose, not the one understood as conformance to the specs. I wonder how you can not see this and say that: > BIMI is not the end-all and be-all of display of logos or avatars at some > place in an MUA; it is one specification for having such logos appear, > either in the folder list, next to the message after it's opened, or both. As I have shown above, for BIMI to be useful, it *has* to be the *only* specification for having such logos appear, and no other options could be possible. If other options exist, the design fails the usability test. Also Tim writes in similar tone here: Dnia 12.01.2024 o godz. 14:04:59 Tim Starr via mailop pisze: > BIMI's value is not dependent upon MUAs > never doing anything outside its spec. Yes, it is. Because it depends on the condition that the logo is displayed only if it is a verified BIMI logo. If that condition is not met (and logo is displayed in other circumstances too), BIMI fails the usability test. If I'm wrong, please explain in detail (but not in technical detail with regard to the spec, but rather try to refer to some hypothetical end-user test case as I did) where I'm wrong. Because again, I don't see BIMI fulfilling its purported goal if it's only *one* of the mechanisms to display logos. To fulfill this goal, it must be *the only* mechanism. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
Dnia 12.01.2024 o godz. 11:18:32 Tim Starr via mailop pisze: > By publishing the BIMI spec. No one's required to follow the spec, but if > they don't, then they're not doing BIMI, and that's not the fault of the > spec. Does the BIMI spec *require* that *only* BIMI-authenticated messages can have logos displayed alongside them in the MUA? In my understanding no. If it actually states so, then it's far too restrictive and unacceptable (and this *is* fault of the spec). That's what im talking about all the time. So MUAs that display "other" (non-BIMI !) logos, are doing BIMI *plus* something else. They are not contrary to the BIMI spec. They are just in addition doing something that is completely orthogonal to BIMI, but gives similar visual experience to the user. Which actually defeats the purpose of BIMI, as I understand it. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
Dnia 11.01.2024 o godz. 17:02:01 Tim Starr via mailop pisze: > The image has to be specified in the DNS, and it has to be certified w/ a > VMC. The VMC certification process includes checking if it's trademarked. > So, in order for a trusted brand's BIMI logo to get spoofed, the email > would have to be DMARC-authenticated and the logo specified in the DNS > would be the one presented to the mailbox provider when they do DNS lookups > on the authentication domains. Under the assumption that that he MUA will display *only certified BIMI logos* and not any other "avatars" with the emails, ever. How are you going to force MUA developers to do that? Assume the recipient uses a MUA that displays not only BIMI logos, but eg. avatars from Gravatar service as well. The attacker just sets as his Gravatar picture the logo he wants to spoof. Then sends mail to the recipient. Recipient sees a familiar logo (without BIMI being used at all!) and assumes the mail is genuine. As I wrote previously, the only method to prevent this is a (totally unrealistic) *legal prohibition* for MUA developers to display any other images than certified BIMI logos. Not possible. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
Dnia 11.01.2024 o godz. 14:34:16 Laurent S. via mailop pisze: > The trademark verification is only for those that pay for it. Nothing > forbids a MUA from displaying an unverified BIMI. Most are luckily not > doing it (yet), I just want to warn that if this becomes common, it will > be abused for sure. I don't think that the regular user will check if > the little extra lock is there on the icon. They'll see a version of the > paypal logo on the phish and have an extra feeling of safety. Dnia 11.01.2024 o godz. 17:52:34 G. Miliotis via mailop pisze: > What I believe will happen is most non-big mail client apps will > support BIMI if they support avatars, otherwise, they won't, cause > the arguments on the receiver side are the same for both features. > > I don't buy the "promoting authentication" argument. And it's clearly visible from the Laurent's mail that if MUAs will display the unverified BIMI logos (and what would prohibit them from that?) the "authentication" factor can be even weaker than with no avatars at all - because user who is convinced that the logo being displayed means that the message is genuine, may not even look at the actual sender field. Also, if a hypothetical MUA displays BIMI logos, but also displays avatars obtained by other means (one of the users in the thread mentioned a MUA he develops that uses eg. favicons, or Gravatar service for that purpose), how the user is supposed to distinguish which avatars are verified BIMI logos, and which ones come from a totally different source? Trying to look at the "broad picture", I realized that the whole concept of BIMI may actually work as designed *only* if MUA developers could be somehow *legally prohibited* from displaying any other avatars than verified BIMI logos. Which not only seems totalitarian in nature, but also politically completely impossible to actually implement. Otherwise, the non-BIMI avatars displayed along the messages, mixed with BIMI ones, will just facilitate phishing instead of making it more difficult. All the manual work on verifying logos and money invested into it will be basically a wasted effort. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: BIMI boycott?
Dnia 10.01.2024 o godz. 14:05:26 Marcel Becker via mailop pisze: > > https://bimigroup.org/mailbox-providers/ Marketing blah-blah only. No actual explanation. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] BIMI boycott?
Dnia 10.01.2024 o godz. 22:57:21 Louis Laureys via mailop pisze: > Just wanted to add that I actually like it for visual clarity. Though I would > have liked a more general avatar implementation not geared towards businesses. If someone, *as a recipient*, likes having avatars next to email, I have nothing against it - but *only if it's totally optional and decided upon by recipient* (and by recipient, I mean the individual person and not the organization that runs the receiving mail server). Then the recipient can choose to use a MUA that supports avatars (of course, there should always be the possibility to turn them off in configuration - which also solves the issue of tracking; if someone doesn't want to be tracked, he/she can turn the avatar support off in options, and their MUA won't fetch any avatar images from any website). But what would be actually desirable, is exactly what you wrote - an implementation *not geared towards businesses*. BIMI is nothing like this, as John clearly explained below it *is and always will be* geared towards businesses. And for me BIMI looks more like push from the *senders* (and in particular, big marketing senders) on people to use the avatars (and use them only in a particular way dictated by big businesses), rather than a response to an *actual need* from *recipients* to use them. Dnia 10.01.2024 o godz. 21:21:16 John Levine via mailop pisze: > While it would be nice to make BIMI available to small organizations > without costing a lot of money, the question "is entity A allowed to > show logo X" is very hard even for people, and not amenable to > authomation. In a few cases where the entity has already paid to put > the logo in a trademark database it's easier but that sure doesn't > scale. There is a very real danger (and this is even predicted in the document linked in the previous email) that adoption of BIMI by big mail providers will serve as another "antispam" measure; messages having verified BIMI mark would be treated by ISPs as more "trustworthy" and "reputable" than the messages that don't. This would clearly lead to dividing email service in two categories: "first class" would be an email from businesses that are big and rich enough that they can afford having their email BIMI certified, which would give them a kind of "guarantee" for their emails to be delivered to all the big ISPs - and a "second class" consisiting of all the other senders, who lack BIMI verification, and thus can only hope to have luck that their email gets through the filters (which will happen gradually less and less often). As it has happened with DMARC, which also in the beginning - as the document states - was purely optional and meant only for specific, often-phished domains. This is a very bad perspective, and BIMI is in my opinion a road straight to this direction. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] BIMI boycott?
Dnia 10.01.2024 o godz. 11:32:36 Seth Blank via mailop pisze: > The hope is that as BIMI gets more widely adopted, the cost (and > automation) of the logo validation drops. Time will tell. > > Of course, for broader adoption, we also need to progress beyond > trademarks, which have their own cost and timeliness issues. The working > group is leaning heavily into this, as its our top priority to make BIMI > more broadly accessible. > > This covers our technical intent: > https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00 and The document fails to convincingly answer THE one basic question: WHY in the hell is such a strange feature needed at all and for whom? As the OP has written, the only ones that may be interested in this may be marketers. Nobody else needs any logos, avatars etc. displayed alongside the email headers. There is a reason why the early attempt at this - I'm talking about the X-Face header, which you even refer to in this document - never gained any popularity. Simply, nobody needs this. The fact that Gmail implemented in its web client putting up some images alongside email headers (which, by the way, show anything non-default only if the sender is another Gmail user and has a profile picture defined in his/her account) shouldn't be any reference nor guide for designing email applications at all. NOBODY NEEDS THESE IMAGES. Also, I see no feasible way - neither now nor in the future - to use it any meaningful way in person-to-person communication, which is the topic OP asked about, and you seem to have ignored it completely in your answer. The document you are linking to isn't even trying to address this use case! It speaks all the time about "organizations" or "brands" and their logotypes, like companies or organizations were the only senders of emails. Or maybe this is the actual intent? To make individual people only reicipents of emails, without the ability to send? In section 3.3 you even predict that BIMI is about to go the same path DMARC went - "DMARC started with limited use to protect heavily phished domains", and now we have arrived to the point when you almost can't send mail to any big mail provider without having DMARC properly set up. You predict that likely the same will happen for BIMI, which means, you won't be able to send mail to any of the "big players" if you don't have BIMI set up. Which *will* cost money - you are also clear about it. Is the goal to make email a closed ecosystem in which only the big players can participate? This was a bad idea from the beginning (I would even say, a crazy idea) and will still be a bad idea no matter how much work and effort you put into it. So maybe it's better not to waste that effort at all and direct it towards something actually useful. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?
Dnia 1.01.2024 o godz. 23:10:22 Jaroslaw Rafa via mailop pisze: > > This is basically equal to the new configuration setting > "smtpd_forbid_unauth_pipelining = no" which is a default for Postfix > versions >= 3.9. Sorry, of course I made a mistake here. I meant "smtpd_forbid_unauth_pipelining = yes" which is equal to "smtpd_data_restrictions = reject_unauth_pipelining, ..." and is a default in Postfix >= 3.9. "smtpd_forbid_unauth_pipelining = no" turns that restriction off. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?
Dnia 1.01.2024 o godz. 21:53:59 Gellner, Oliver via mailop pisze: > > Yes, but as with Postfix the update alone does not fix the vulnerability. > You have to additionally change the config as instructed. The vendors and > distributions don’t do this automatically as this changes the behavior of > the MTA. It was usually always advised in Postfix documentation to have the following setting in the config: smtpd_data_restrictions = reject_unauth_pipelining, From what has been recently said in the Postfix mailing list, having this setting in the config blocks this attack (*unless* both sending and receiving side support BDAT format and the attacker will smuggle the second message using that format (but BDAT support can be disabled using another setting in the configuration). This is basically equal to the new configuration setting "smtpd_forbid_unauth_pipelining = no" which is a default for Postfix versions >= 3.9. So if you were using the "recommended" configuration from the start, your MTA is not vulnerable to this attack (minus the BDAT case) even if you don't patch Postfix. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail now deferring email which meets their published reqs
Dnia 30.12.2023 o godz. 22:58:25 Simon Wilson via mailop pisze: > > The error message from Google is specifically: > > 421-4.7.28 Gmail has detected an unusual rate of unsolicited mail > originating from your SPF domain [howiesue.net 35]. To protect our > users from spam, mail sent from your domain has been temporarily rate > limited. For more information, go to > https://support.google.com/mail/?p=UnsolicitedRateLimitError to review our > Bulk Email Senders Guidelines > > Google search tells me this is NOT the message they use when the IP > address is the issue, but that they are having some unknown issue with the > domain. I have had exactly the same issue about a year(?) ago. All of a sudden, when I sent a message to - if I remember correctly - 7 recipients, of which 5 were on Gmail, I got this rejection message and the message, as well as subsequent ones, even if sent to only one recipient, were deferred for many hours. The issue lasted for maybe a week or two, then disappeared on its own. On average, I send maybe three-four messages to Gmail users per day IN TOTAL. Sometimes I don't send any message to Gmail at all even for two-three days, so the message about "unusual rate of unsolicited email" seems pretty ridiculous in this context. Similar to you, I have SPF, DKIM, DMARC etc. all in place, valid PTR, IP not on blocklists (except occasionally the entire ISP's netblock falls onto UCEPROTECT level 3), I have owned this domain for multiple years. I have also registered my server and domain on DNSWL. All this doesn't help in any way. I have also my domain registered in Postmaster Tools, but it doesn't show any data due to too small number of messages. I guess Google's mail system is just tuned towards big senders who send large amount of mail and totally doesn't "know" how to handle small senders which send only a handful of messages. If I were Google, I would just exempt the small domains (those that are too small to show up in Postmaster Tools) from most "sophisticated" checks that their system is probably doing, which may work well for large senders, but for small senders they just lead to absurd FPs like the ones described here. But for some unknown reason, Google doesn't want do do that. So for a small sender, it becomes more a random thing whether their mail will be accepted by Google or not. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail now deferring email which meets their published reqs
Dnia 30.12.2023 o godz. 15:57:45 Richard Rognlie via mailop pisze: > I'm not seeing deferrals but some of my users are reporting that they're > not seeing emails coming from my play by email service. I've double > checked the logs and gmail is accepting the messages. So anything > happening to user mail is under the covers on the gmail side. It's very probable that Gmail files these messages to recipients' Spam folder. It happens very often (more often than not) with my messages as well. People often tell me they can't find my messages in Spam folder, but I think it's just their inability (lack of skill?) to do so, rather than the actual lack of message in the folder, because I have myself set up a few accounts on Gmail for test purposes, and always when I sent anything to one of these accounts and the message wasn't in inbox, I was always able to find it in Spam, the message never just "disappeared". -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM validity period (anti-forgery vs. anti-spying)
Dnia 22.12.2023 o godz. 10:54:54 Randolf Richardson, Postmaster via mailop pisze: > > Tracking/spying elements in email messsages are usually intended to spy on > > the *recipient* - did the recipient read the email at all, did he clicked > > on a link in the email etc. > > ...mail server logs would be one obvious angle, but even that would > require additional effort to extract the target user's eMail activity > since mail server logs cycle through pretty quickly (at least on a > lot of busy Linux systems, anyway). Log retention is generally used > for troubleshooting, so a long-term retention usually isn't needed. > > Another method is for a malicious sender to deceptively include > tracking software in an attachment. Most security software stops > this, which includes security daemons on mail servers that can also > be combined with blacklists of IP addresses and/or domain names that > distribute malicious eMails or are otherwise-infected systems that > can be used to commit such types of SMTP abuse. The most commonly seen method of tracking is probably inclusion of specifically crafted links in the message, that refer to a tracking server run by the sender, so the sender knows if the recipient clicked on a link in the message. Also the HTML-formatted message may include images loaded from sender's server, which can also be used to track whether the recipient has opened the message at all. But all this has absolutely nothing to do with message being DKIM-signed. > > What does one have to do with the other and to the discussion about > > publishing keys (the latter - to my understanding - serves only possible > > legal purposes in case the sender needs to deny the fact that he sent the > > message, which for me is a completely made-up scenario, an absolute > > fiction). > > Some of our clients are investigators, lawyers, etc., who > occasionally need high quality (read "reliable") evidence for the > cases they're working on. DKIM, when available, makes it easier to > authenticate eMail evidence in a way that can satisfy these needs. > > While this doesn't happen very often, I'd say that, since its > inception, DKIM-based authenticity has moved from being a completely > made-up scenario to having some actual utility. I was not talking about *confirming* the authenticity of a message by means of a DKIM signature, but the opposite - what was being discussed here, ie. the possibility for the sender to *deny* that he has sent the message (despite it being DKIM signed), because of previous publication of the DKIM private key. That seems a fictional scenario for me. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM validity period
Dnia 22.12.2023 o godz. 16:22:45 Slavko via mailop pisze: > But my point was (mostly) not about courties cases, i mean usual users > tracking/spying (contacts, shoppings, opinions, etc), where signature is > checked once (at receive time), but used/stored forever. And that cannot > be solved by rotation nor by publishing nor by any cryptographic method > (which i am aware of). I'm sorry, but I don't understand how in your view the fact that message is DKIM signed is related to tracking/spying etc. Tracking/spying elements in email messsages are usually intended to spy on the *recipient* - did the recipient read the email at all, did he clicked on a link in the email etc. On the other hand, DKIM signature identifies the *sender* of the message. What does one have to do with the other and to the discussion about publishing keys (the latter - to my understanding - serves only possible legal purposes in case the sender needs to deny the fact that he sent the message, which for me is a completely made-up scenario, an absolute fiction). I cannot understand what topic you're actually discussing in this thread. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM / slippery slope gmx.de
Dnia 18.12.2023 o godz. 14:49:50 Paul Smith* via mailop pisze: > Spam filters handle reputation of things. One thing they can do is > track reputation of sender domains. When forgery is possible, then > that means that spammers can piggy-back on the good reputation of > big companies like Google, Amazon, etc. They send mail pretending to > be from someth...@amazon.com. There's no reliable way for the > recipient to know that it's not actually from Amazon, so the > recipient has to either: Do content analysis. Do content analysis. Do content analysis. Do content analysis... -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Merry Christmas from Google?
Dnia 17.12.2023 o godz. 10:45:04 Benny Pedersen via mailop pisze: > >If they use forwarders, SPF will fail in the case the envelope sender > >isn't rewritten. Check your logs for that. > > false, every forwarder changes envelope sender Definitely not. Simple forwarding, as done by default by .forward file, or /etc/aliases, does not change the enevelope sender. And this method of forwarding is still the default, so it should be always considered as reference. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft's block list?
Dnia 22.11.2023 o godz. 16:25:36 Otto J. Makela via mailop pisze: > Can someone shed light on a Microsoft/Outlook block list? Our hobby server > (on upcloud.com) seem to have been blocked for quite some time now. > > At this time, SPF and DKIM should be correct for our outgoing messages. > Is there anything to be done, apart from switching to some mail sender > company instead of ourselves attempting a direct connection? I recently had this. My hosting company told me I need myself fill appropriate forms at Microsoft to be unblocked. Of course after I did it I got a standard reply from them that "my IP does not qualify for mitigation", to which I replied by mail asking to be unblocked nevertheless - and it worked. I can now send to Microsoft. According to the information my hosting comapny gave me, I first subscribed to Microsft SNDS here: https://postmaster.live.com/snds/JMRP.aspx?wa=wsignin1.0 and then I submitted the request for my server IP to be unblocked: https://support.microsoft.com/en-us/getsupport?oaspworkflow=start_1.0.0.0=capsub=edfsmsbl3=en-us=635857671692853062 -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Reaching out to GMAIL
Dnia 21.11.2023 o godz. 12:44:20 Ralf Hildebrandt via mailop pisze: > > We're running the postfix-users ML on list.sys4.de, and all over a > sudden we're being tempfailed by GMAIL: Seems to be a quite common issue recently, many people here are reporting it. Something's wrong at Google again (was there any time that it wasn't?) -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Google rate-limiting more aggressively than usual?
Dnia 17.11.2023 o godz. 22:37:58 Philip Paeps via mailop pisze: > For the past couple of days, mx2.FreeBSD.org is queuing more mail to > Google than usual. > > This is the 421: > > 421-4.7.28 Gmail has detected an unusual rate of unsolicited mail. > To protect 421-4.7.28 our users from spam, mail has been temporarily > rate limited. Please 421-4.7.28 visit 421-4.7.28 > https://support.google.com/mail/?p=UnsolicitedRateLimitError to 421 > 4.7.28 review our Bulk Email Senders Guidelines. > m17-20020a67f71100b0045d8a438106si295017vso.199 - gsmtp (in > reply to end of DATA command) > > We're not sending out more unsolicited mail than usual. Postmaster > Tools suggests authentication, spam rates, etc etc etc all > unchanged. We do all the things in the Bulk Sender Guidelines > (except DMARC because we don't want to frustrate our users ability > to use third-party mailing lists that don't mitigate it). We add > ARC headers to all our outbound mail. > > Since about September, we're hitting the rate limiter ~70% of the > time every couple of days. Since ~15 November we're hitting the > rate limiter for almost all mail we send. > > Anyone else noticing this? Just recently someone on Postfix mailing list wrote that he ran into this. I also ran into this - without any change on my server whatsoever - about a year ago, even for SINGLE messages sent to ONE Gmail recipient! It lasted about a week and disappeared by itself (however, the semi-permanent problem that all my mails seem to be filed to Spam folder by Gmail did NOT disappear). I'd say it's just "Google doing Google things". Probably nobody even at Google knows why and how... -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail deferrals resolved by transit encryption
Dnia 17.11.2023 o godz. 14:34:19 Lukas Tribus via mailop pisze: > > Google probably wants you to enable STARTTLS, so reducing sending > limits for non STARTTLS senders can make sense from Google's POV. That thread makes me wonder, how come anybody is sending mail without STARTTLS now? When all major MTAs do it just by default? -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft lays hands on login data: Beware of the new Outlook
Dnia 13.11.2023 o godz. 19:13:50 Jaroslaw Rafa via mailop pisze: > > What if users travel abroad? > > > > IMHO, it is better to monitor login IPs using services like > > AbuseIPDB which provide an abuse score. > > Or just fail2ban :) Nevermind, I didn't notice that we're talking about a case when potential attacker already has credentials :) -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft lays hands on login data: Beware of the new Outlook
Dnia 13.11.2023 o godz. 14:04:29 Alessandro Vesely via mailop pisze: > >My boss wants to block access from abroad but that will block several > >people, I'm afraid. > > What if users travel abroad? > > IMHO, it is better to monitor login IPs using services like > AbuseIPDB which provide an abuse score. Or just fail2ban :) -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft lays hands on login data: Beware of the new Outlook
Dnia 10.11.2023 o godz. 21:09:31 Louis Laureys via mailop pisze: > You can probably tell from my wording how I feel about this. I get the battery > efficiency part. Not the part where ActiveSync has an exception to it, and > their > own battery efficient IDLE alternative is not accessible to most. Let alone > the > fact that has caused basically all third party emails to just capture your > credentials. I don't understand, why the push notifications cannot work independently of IMAP? I mean, there is a mechanism to get push notifications from any website via the browser, you just go to website and subscribe to these notifications (at least you can on Android, I don't know if it's the same on iOS). So in theory, there could be a very simple website on the mail provider's server, where you log in with your credentials and then just subscribe to push notifications. You can log out after that. Then whenever a mail message comes in, that website sends you a push notification. (Actually, I have a "poor man's" version of this implemented on my mail server for some selected important emails - when one of these emails comes in, a script on the server simply sends me a SMS notification using my phone provider's email-to-SMS gateway). And for the IMAP client, you fire it up only when you want to actually read or send mail. It doesn't need to keep any idle connections. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft CERT Report Response Marked As Spam
Dnia 9.11.2023 o godz. 12:41:57 Jarland Donnell via mailop pisze: > A score of 5.8 on SpamAssassin rules is fairly low. It would be more > advisable for you to consider adjusting your settings. SpamAssassin > is designed in such a way that it will always trigger a variety of > rules for every email, legit or otherwise. It shouldn't be too > strange to see a legit email in the range of 3-5, and I'd say 5.8 > isn't too far out from there. This particular email from you has score 0.7 on *my* SpamAssassin. I *very rarely* get more than 3 on legit emails. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] script to collect SPF addresses by domain?
Dnia 31.10.2023 o godz. 11:09:52 Stuart Henderson via mailop pisze: > > SPF syntax allows expressing policy which can't be converted to a > simple list of addresses (the policy can include further DNS > lookups based on sender localpart/domain, IP address, etc). > > So it's not possible to produce a complete list like this. May I suggest a bit different approach, not based on SPF: postgrey, the "reference" greylisting daemon for Postfix, comes with a configuration file "whitelist_clients" that lists senders that exhibit "no retry" or "random IP retry" behaviour simply by their domain name, FQDN patterns or IP ranges. Maybe just grab this file and try to make some use of it. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] How to handle hostname and PTR mismatch?
Dnia 27.10.2023 o godz. 17:03:29 Cyril - ImprovMX via mailop pisze: > > This should weight in the decision; If the hostname doesn't match the PTR, > that the SPF fails, and so on, maybe it would be time to block the incoming > email. > > Really interesting! Thank you everyone! Hm... aren't you basically re-inventing SpamAssassin? ;) -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] How to handle hostname and PTR mismatch?
Dnia 27.10.2023 o godz. 15:19:33 Cyril - ImprovMX via mailop pisze: > > It's been quite common to refuse a server connecting that doesn't have a > proper PTR, but I was wondering if there was any recommendation (either > official via RFC or standard practice) about a server connecting with a PTR > that is different from the announced hostname at the HELO/EHLO command. From my experience, it happens quite often. I once checked HELO/PTR alignment on my server, but it resulted in a LOT of false positives and rejecting legitimate mail. So I wouldn't recommend it. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Outlook misinterpreting the Sender field ?
Dnia 27.10.2023 o godz. 14:23:14 Marco M. via mailop pisze: > > You mean DMARC failure? > > > > SPF by itself checks only the envelope-From. > > If Sender: is missing, the application will most likely use From: for > envelope sender (MAIL FROM:) (normal MUAs do that). That will make SPF > fail and bounces will be send to the original sender of the message It's not MUAs job to check SPF; it's MTAs job. "Normal" SPF checking happens at the connection phase, not at data phase, and is not interested at all in any headers of the message (neither From: nor Sender:). All it takes is the domain from MAIL FROM:. It's DMARC that requires alignment of MAIL FROM: domain with header From: domain, not SPF. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Outlook misinterpreting the Sender field ?
Dnia 27.10.2023 o godz. 12:44:09 Marco M. via mailop pisze: > This will result in SPF failure if your MTA sends the message with > From: and MAIL FROM:https://list.mailop.org/listinfo/mailop
Re: [mailop] Success MiTM attack
Dnia 24.10.2023 o godz. 11:04:05 Alessandro Vesely via mailop pisze: > > Is that the way it went? Let's Encrypt certificates get renewed > automatically, so it's hard to "forget" to do it. They don't have to. You can just run a simple ACME client (like 'bacme') one time, get a certificate and install it manually. Nothing forces you to configure automatic renewal. If you are configuring a server with the only purpose of intercepting traffic, it seems quite probable to forget (or not bother at all) about configuring automatic certificate renewal. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Success MiTM attack
Dnia 23.10.2023 o godz. 11:27:09 Slavko via mailop pisze: > Dňa 23. októbra 2023 10:26:57 UTC používateľ Jaroslaw Rafa via mailop > napísal: > > >However, all this discussion is hardly related to email, as - as many have > >noted - there's hardly any certificate checking at all between MTAs. > > Do you want to tell, that MUAs communications are not part of email? > > Do our MTAs works only for self and mails ends nowhere or they > provides transport channel for end users and thus end users are > what matter? Or all your users still authentificate and sends/reads > own mails over plaintext and TLS is important only in MTA-MTA? > > As someone other pointed, MUAs doesn't do DANE, nor SCT, nor > anything extra to check certs. AFAIK support of SCRAM+ auth is > not common (if any). In other words, that XMPP incident is fully > applicable to email and it is possible to intercept your users > connections and one can only very little to do, to avoid that. So the question is: are MUAs (like browsers) able to recognize EV certificates and present them appropriately to the user? And if yes, how many mail providers are going to use EV certificates on their servers, taking into account that they are usually much more expensive than regular certificates? (BTW, my opinion is that CAs are just ripping off their customers on the price of EV certificates; the administrative overhead related to paperwork needed to actually verify the subject's identity is not as big to justify so high prices of EV certificates). -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Success MiTM attack
Dnia 22.10.2023 o godz. 12:59:18 Matt Corallo via mailop pisze: > SSL certificates do not, and have never, "protected against MiTM". > The certificate authority trust model can best be summarized as > "someone else's DNS resolver and connection", it is not a statement > of who actually owns the domain or what server is actually supposed > to be on the other end. There are various "tiers" of SSL certificates. The "regular" certificates only confirm that you are actually connecting to the domain you wanted to connect to, ie. you wanted to connect to www.example.com, and the certificate confirms that the server is actually www.example.com. But the "extended validation" certificates (which were once - when they were introduced - a big thing, and browsers even signalled a connection to a site with EV certificate with a different URL bar color than to a regular HTTPS site) require the entity requesting a certificate to provide to the CA some official documents confirming that they actually are who they claim to be. When you click on the padlock icon in browser (at least in Firefox) while connected to a site with EV certificate, it shows you an actual company name the certificate was issued for, while for "regular" certificates it shows you only "Connection secure". Of course, this still doesn't protect against "lawful interception" but does protect against a random MiTM attack, as (at least we assume so) a random attacker can not obtain an EV certificate belonging to someone else. However, all this discussion is hardly related to email, as - as many have noted - there's hardly any certificate checking at all between MTAs. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail classifying message as spam based on the sending IP
Dnia 13.10.2023 o godz. 15:43:50 Al Iverson via mailop pisze: > Submit a sample message from the affected IP here: > https://support.google.com/mail/contact/gmail_bulk_sender_escalation > They rarely respond, but they do sometimes address issues based on > submissions. Probably very rarely. In my case, I have lost count how many times did I fill up this form. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail classifying message as spam based on the sending IP
Dnia 13.10.2023 o godz. 09:21:24 Fernando MM via mailop pisze: > > I'm debugging an issue with gmail classifying a simple confirmation email > as spam. > > At my gmail account it displays "Why is this message in spam? It is similar > to messages that were identified as spam in the past.". And at a coworker's > account it's displaying the "This message seems dangerous" phishing warning. [...] > Did anyone here had similar issues in the past? Were you able to fix it > somehow? I have a similar issue since about 3 years, I think. Most of the time all emails from my address (hand-written, personal messages, NO automatically generated content at all and obviously never any spam) are classified by Gmail as spam with the same message as yours. Even after marking it on recipient's side as non-spam, following messages from me are still classified as spam. Even replies to messages I receive from Gmail users are classified as spam. Messages with other sender domains hosted on the same server (and sent from the same IP) go through properly. It's just that Google treats everything that comes from my domain as spam, no matter what. Of course SPF, DKIM, DMARC are all OK, server is not blacklisted etc. My server and domain is on DNSWL, that also doesn't help. I was never able to solve the issue successfully. Sometimes it disappears for a few weeks and my emails go to Inbox just fine, but most of the time they are marked as spam. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] outlook.com 421 try again later S77719
Dnia 12.10.2023 o godz. 11:05:04 Otto J. Makela via mailop pisze: > Microsoft had an about 16 hour period of time where their servers > only gave a "451 4.7.500 Server busy" for their hosted domains. We saw > these in the time range 2023-10-11T04:45/20:17+03:00, and in that time > we had mails queued for about 300 different domains hosted with them. That's the downside of giving someone's email into hands of a big company instead of self-hosting or hosting at a small ISP. If these 300 domains would use 200 different hosters instead of just one, and one of these 200 hosters would mess things up, the impact on email ecosystem as a whole would be much less. The Internet was meant to be distributed, not centralized! -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] IPv6 capable servers send with IPv4 to me
Dnia 6.10.2023 o godz. 13:41:06 Marco via mailop pisze: > > As does the standard mechanism used in browers for dealing with the > > same type of situation. > > Although they try IPv6 first and don't do a "protocol balancing", at > least I haven't experienced that yet. One can configure Postfix do do that. If someone doesn't configure this, probably he/she is OK with the current behavior. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] IPv6 capable servers send with IPv4 to me
Dnia 6.10.2023 o godz. 11:00:27 Bjørn Bürger via mailop pisze:
>
> Some MTAs, like postfix for example, do load balancing across ip
> protocols. I have no idea, why they think, this might be a good idea,
> though. It's quite annoying.
Here's a quite recent explanation from Postfix author, Wietse Venema, sent
to Postfix mailing list in response to someone who (similarly to you)
complained, why Postfix doesn't do IPv6-only deliveries if the target host
has an IPv6 address:
==
The purpose of Postfix is to deliver mail, not to achieve world
domination for a particular IP protocol.
If a destination has IPv4 and IPv6 addresses, then an explicit
preference for one protocol type means that ALL DELIVERIES will
suffer delays when that protocol type has an outage.
Whereas with Postfix default settings, about half of deliveries
will be slow when one of those protocols has an outage (Postfix is
smart enough to use similar numbers of IPv6 and IPv4 addressess,
to avoid huge delays when, for example, a site has many IPvX and
few IPvY addresses, and IPvX has an outage, for {X=4, Y=6} or {X=6,
Y=4}).
For me, availability matters more than protocol religion.
==
--
Regards,
Jaroslaw Rafa
r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] IPv6 capable servers send with IPv4 to me
Dnia 6.10.2023 o godz. 11:01:10 Marco via mailop pisze: > > https://www.postfix.org/postconf.5.html#smtp_address_preference > > https://www.postfix.org/postconf.5.html#smtp_balance_inet_protocols > > Does the balancing test IPv6 first or is it just randomly? > Does it use the first address that works? It depends on the config setting set by server admin. May try IPv6 first, may try IPv4 first. Yes, the first one that works is used. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Google - Messages with multiple addresses in From: header are not accepted.
Dnia 18.09.2023 o godz. 09:53:16 Scott Mutter via mailop pisze: > Headers formatted as: > > From: Name > MIME-Version: 1.0 > > Generates this multiple addresses in From header error. Because this header is equivalent to: From: Name MIME-Version: 1.0 and somehow Google interprets it as "multiple From:". -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] New Validity policy for paid FBL (ARF)
Dnia 13.09.2023 o godz. 12:35:15 Gellner, Oliver via mailop pisze: > Other than that, I'm with you and Bill Cole: If your infrastructure is not > being used to send spam, newsletters or other marketing messages, feedback > loops provide no benefit. 100% of all reports are going to be false > positives of people who either accidentally hit the wrong button or are > generally confused about the difference between the report spam button and > the delete button. But this doesn't matter, email providers know this as > well and if one out of thousands of emails is accidentally reported as > spam it doesn't change anyones reputation. Asking out of curiosity: what happens in case of small senders? If one of not thousands, but - say - five emails sent in total is mistakenly reported as spam? -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Authentication Bounces by Gmail
Dnia 13.09.2023 o godz. 13:54:01 Atro Tossavainen via mailop pisze: > > Might be convinced with this if it weren't for gmail being the source of > > ~40% of the spam we receive. > > And that's after all of the botnets and so on have been blocked > through the use of DNSBLs, I suppose? I guess Google doesn't care about the spam they send, because this doesn't give them financial losses (if someone would start suing them for spam they send, things may change). On the other hand, they are *convinced* (even if this might not be completely true), that accepting anything that *might be* spam (even if it isn't actually) may harm them financially. So they are over-filtering. By "over-filtering" I mean they are focused more on minimizing the number of errors of the first kind (mistakenly accepting a spam mail) than on minimizing the number of errors of the second kind (mistakenly rejecting, or filing to Spam folder, a non-spam mail). The two goals are a bit contrary to each other - if you try too hard to minimize one, the other goes up. But my opinion is - and always was - that for any decent spam filtering system the second goal should be more important than the first, ie. you should make sure that users miss as little non-spam mails as possible, even at the cost of slight increase on number of spams that go through. However, Google seems to think the other way - they want to filter as much spams (and probable spams) as possible, at the cost of increase in rejected non-spam mails. And probably their users are happy with losing mail anyway as they are not going away (and remember, Google is not only free Gmail, it is also paid tier that many corporations use, and that suffers the same problem...). -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Authentication Bounces by Gmail
Dnia 13.09.2023 o godz. 02:52:59 Jarland Donnell via mailop pisze: > > It's my finding that at scale, there's no silver bullet to ensure > that 100% of emails you forward are going to be accepted by Google, > or anyone really. That's why anyone who considers their inbox > mission critical needs to rely on their inbox provider, and not a > third party accepting email from their inbox provider. There's one simple solution that can be quite easily adopted by mailbox providers. If someone forwards mail to his/her account, they obviously know *from where* they forward mail. So allow your user to specify a list of IP addresses of servers from where the mail is forwarded. Email from these servers to that particular user will be exempt from SPF/DKIM/DMARC checks. (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.) -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Legit-looking mail to the wrong address with no unsubscribe
Dnia 26.08.2023 o godz. 13:58:21 Slavko via mailop pisze: > > Or people simple do not want to share own email, as it is > not related for delivery, but required by the form. Thus > they fill semi random email like string. In many cases either the correct email address OR a phone number is needed for delivery. If you buy anything and choose your order to be delivered to a parcel machine (you may not know them in the US, but in my country they are extremely popular as they are super convenient, and it's the preferred method of delivery for many people), you NEED a way to receive the code that allows you to pick up the package at the machine. The code comes via email and via a text message to the specified phone number, so you need at least one of them. Even if the delivery comes via a regular courier, providing your email when placing order is helpful, because 1) usually you get a message with a link that allows you to track your package on the delivery company's website so you know when it's about to be delivered; 2) many delivery companies send you (usually a day before planned delivery) another mail with a link that allows you to eg. redirect the package to another address if you cannot pick it up, or change the delivery date. And because of GDPR (already mentioned in the thread), I actually NEVER see here the cases when email given for transactional purposes is used to spam you, unless you actually checked the box saying that you agree to marketing email when placing your order... Yes, it did happen several years ago, but now nobody will risk fines for GDPR non-compliance. They do it a different way. They often offer a discount if you subscribe to marketing email. Especially cell phone providers and ISPs. It is now almost a "standard" that with typical contract you pay X per month if you don't agree to marketing email, and X-5 or X-10 per month if you do. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Legit-looking mail to the wrong address with no unsubscribe
Dnia 25.08.2023 o godz. 09:48:35 Chris Adams via mailop pisze: > > So even for transactional messages, there's usually an account making > the purchase, or something is being delivered to an address, or the > like. So a "this is not me" link should be able to note that (a) don't > send more mail about the current transaction to this address and (b) > don't send any mail for future transactions with the same delivery to > the same address without further input. Future orders that would have > transactional emails blocked should pop up and say "hey, this address is > flagged as NOT YOU, are you sure?". This does not solve the problem of one-time purchases WITHOUT an account (actually may be multiple "one-time" purchases, but without registering an account at the shop and logging in). YMMV, but from my experience, I purchased quite a lot of things online without creating any accounts (and still do). -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Legit-looking mail to the wrong address with no unsubscribe
Dnia 24.08.2023 o godz. 07:12:52 Chris Adams via mailop pisze: > What do you do when legitimate mail (lately, DoorDash order info and > Delta Airlines tickets) is sent to the wrong address? These types of > messages rarely have an unsubscribe method. I get a ton of crap to a > Gmail address that I really only use for Google-related stuff (not as a > general email box), so I know instantly that this is not to me. > > Why do vendors think they don't need an unsubscribe in this type of > mail? Just because their customers are dumb and don't know their own > email address doesn't mean they should continue sending personal > information about them to other people. I see no good solution to this. When these mails are sent to an address registered with an account eg. in an online shop, this is certainly an error on the side of the sender, because account creation should always involve confirmation of the email that was given by the user. But what about one-time actions, when someone is doing a purchase in an online shop *without* creating an account and just enters wrong email address? Ask yourself: as a user doing such purchase, would you really want to go through email verification process for every one-time action? To receive first an email requesting you to confirm your address, only to next receive another email from them with the actual information? That seems over-engineered... And the email verification actually doesn't fully solve the problem in that case: if the user enters the wrong email, a wrong person (like you) will still receive an unwanted message, only instead of an order confirmation or similar, it will be a message asking to confirm your email by clicking on a link. It makes any difference only in terms of data protection - ie. the data belonging to the actual customer is not revealed to a third party - but it makes no difference with regard to getting unwanted mail. I think one has to live with that. The only thing we can do is to set up an individual, per-user filter that will put all messages from services you don't use to spam. I guess most people use only a handful of online services and they know and recognize emails from them. So if you get anything you don't recognize, set up a filter to put further mails from them to spam. Of course, this needs constant updating; but for example if you never shop at Amazon, and you receive any order confirmation from them, you set up a filter that puts all further mail from Amazon to spam. Amazon shouldn't bother you anymore. Then, if you receive another mail from a service you don't even know about, you set up a filter to put all mail from them to spam. And so on... If you later happen to make a purchase at one of these services, and you are expecting an email from them, the case is simple: you don't get an email you are expecting, so you look for it in the spam folder. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [STATE of the UNION] Tails from the trenches of the spam auditing team..
Dnia 23.08.2023 o godz. 09:08:52 Michael Peddemors via mailop pisze: > > It continues to be a battle, but overall the traditional spammers > are still getting IP space, seems that even the historically 'good' > hosting companies are throwing in the towel lately, and letting any > one on board Paradoxically, I consider this to be good. It may cause the recipients to stop filtering using "reputation of the ISP" - which always looked very doubtful to me (causes false positives and harms innocent senders that happen to have servers hosted at the same ISP) - and changing to filtering using more reliable indicators of actual spam. > But the trend of phishing and malware continues to grow. Keep your > head down, remember to use IP reputation as your first line of > defense. Individual IP reputation - yes. Netblock reputation - no. Only if you know that the entire netblock belongs to a spammer, it is justified to block the entire netblock. If it is just a random netblock of some ISP that just happens to contain some spamming IPs (even a lot of them) inside - no, never block the netblock as a whole. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] hotmail.com SPF forgot IPv6
Dnia 19.08.2023 o godz. 11:49:34 Jarland Donnell via mailop pisze: > > Is "-all" not indeed a policy in SPF, directed by the domain owner? > I would argue that it is. Especially given that there are options > there, each one defining how the domain owner wishes SPF failure to > be treated. I would find it odd to say that should ignore domain > owners when they say "-all" since that's a direct and clear request > by them. To quote RFC 7208: "A "fail" result is an explicit statement that the client is not authorized to use the domain in the given identity. Disposition of SPF fail messages is a matter of local policy." So it's up to the receiver whether to reject mail that fails SPF or to accept them. RFC doesn't mandate anything. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Abuse AUTH from Microsoft outlook IP space
Dnia 14.08.2023 o godz. 10:42:53 Dan Malm via mailop pisze: > > Since Friday I'm seeing a rather extreme amount of SMTP AUTH > requeusts from the same IPv6 IP space that outlook.com uses when > sending emails on behalf of customers that have added an "external" > address to sync and send from to their outlook account. The AUTH > uses valid credentials for the accounts but just hangs up after > AUTH. The amount of connections seems to increase daily. Do you have AUTH turned on on port 25? Why? Or are they accessing the submission port? -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Any insight on whether to treat the Microsoft Consumer/Business MXes separately?
Dnia 9.08.2023 o godz. 17:13:01 Mike Hillyer via mailop pisze: > > We have a user who has noted that the two subdomains > *.olc.protection.outlook.com and *.mail.protection.outlook.com are > grouping separately and asked about them being merged so they could > maintain only one set of throttle configs. > > Before acting on that request I wanted to see if I could get context to > make sure we do the right thing. I thinks such things could be configurable anyway? Ie. if the user wants to treat them separately, or to merge them, the MTA can be configured to do either one. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] ANY OVH Contact?
Dnia 9.08.2023 o godz. 11:00:12 Otto J. Makela via mailop pisze: > > Unless the situation has dramatically changed in the last year, > OVH has no functioning abuse team. I block a majority of their nets > from sending email, don't seem to getting any false positives. Luckily you don't block the net where my server is located, otherwise you would get a false positive, if I would send mail to you... -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] authentication hacks, I Need someone from AOL and/or Yahoo to contact me
Dnia 25.07.2023 o godz. 21:44:21 John Levine via mailop pisze: > It appears that Mike Hillyer via mailop said: > >So, before allowing access to submission service, Postfix consults IMAP > >server (Dovecot in this case) to check if there is actually a > >currently existing authenticated IMAP session from that IP address. Only if > >such a session exists, connection is allowed and the client > >may proceed to authentication attempt. Otherwise, the connection is > >immediately rejected. > > This is a very old idea. See https://en.wikipedia.org/wiki/POP_before_SMTP Yes, I got the idea exactly from POP before SMTP. We may call it a modern remake of POP before SMTP :) -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] I Need someone from AOL and/or Yahoo to contact me
Dnia 24.07.2023 o godz. 19:35:28 Sebastian Nielsen via mailop pisze: > Also on the topic on mail server hacking, I would suggest to add > IP-restriction on your mail accounts. [...] I'll add here another idea that I have implemented on my server. I don't know how easy would be to do this with Exim (as I don't know Exim), but it was pretty easy to do with Postfix. From my experience, all actual email clients first establish an IMAP connection, and then - keeping the IMAP connection active - try to send mail on submission ports. And there is a lot less password-guessing attacks on IMAP services than on submission services (that's my experience, of course YMMV). So, before allowing access to submission service, Postfix consults IMAP server (Dovecot in this case) to check if there is actually a currently existing authenticated IMAP session from that IP address. Only if such a session exists, connection is allowed and the client may proceed to authentication attempt. Otherwise, the connection is immediately rejected. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] AOL/Yahoo requiring SOA record for MAIL FROM domain name?
Dnia 13.07.2023 o godz. 10:23:24 Robert L Mathews via mailop pisze: > > But anyway, if other people have this trouble, note that it can > happen whether the MAIL FROM domain name is directly at a PSL > breakpoint or not. The issue is just that there's no SOA found at > the MAIL FROM domain name level, nor at the PSL organizational > domain level (if different), so you need to make one of those exist. I wonder what can be the real scenario when PSL organizational domain has no SOA. If .tld is on PSL, then example.tld will be the organizational domain. And it definitely should have its own zone file, so it should have SOA. I can't imagine a scenario in which it doesn't. IMHO, this would be only possible if example.tld and .tld itself would be defined in the same zone file. But that contradicts the very meaning of .tld being on PSL! If domain is on PSL, it means its subdomains belong to different administrative entities than the main domain, so they obviously should have their own zone files and SOA. If anybody knows such a scenario, could you please explain it? -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Guide for setting up a mail server ?
Dnia 12.07.2023 o godz. 13:58:21 Grant Taylor via mailop pisze: > > 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 do all the work, even if it's ten times the work compared > to if I had given you the smallest amount of data." -- I try to be > a better net'itizen than that. A few people / organizations have > very specific reasons for not publishing information. I would say otherwise. A few people / organizations DO have reason to publish SPF/DKIM/DMARC. These are the ones who send transactional mail. These - when impersonated - could cause harm to recipients by eg. redirecting them to a malicious website. Eg. said delivery companies, online stores, banks etc. Most of regular consumer email users don't have any reason for this. As Bill Cole, whom I was replying to, wrote - nobody would try to impersonate you or me in a phishing campaign for financial gain, because there won't be any. If I receive mail from an unknown account on Gmail, what does the "pass" result of SPF/DKIM/DMARC check actually tell me? What benefit gives me the fact that the message actually does come from Gmail, if Gmail has millions of users, unknown (but significant) percentage of them being malicious? On the other hand, if I receive a message from someone I know, I can usually recognize if it's actually written by that person or someone is trying to impersonate him/her. The style of writing, relevance to actual events that we are both concerned about and behavioral patterns (the time when the email is sent, the correlation between topic and length of the message etc.) are factors that we all intuitively, subconsciously take into account and are able to recognize a forgery quite well. So my opinion is that consumer-oriented email services, especially the big ones, have in fact little reason to publish SPF/DKIM/DMARC. On the contrary, corporate domains that are used specifically to send transactional email have a big reason to do it. As far as I remember, that was how these characteristics were initially thought of. Only later the "email oligarchs" forced the attitude that they should be quasi-mandatory for all. And to return to the topic, my initial message was not about *not publishing* SPF/DKIM/DMARC, but about *not checking* them on *incoming* mail. I still say - I don't do it because I don't need it. I don't remember a single phishing incident that wasn't at the same time an obvious and blatant spam, easy to catch by antispam filters. And referring to your comparison to "800 lb gorilla", if my "800 lb gorilla" does the job good enough and causes no issues with potential CPU overload on my server, there is absolutely no need for me to introduce additional "monkeys" that do (partially) the same job. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Guide for setting up a mail server ?
Dnia 12.07.2023 o godz. 08:53:16 Bill Cole via mailop pisze:
> For the overwhelming majority of sending systems, the only internal
> security benefit to implementing SPF/DKIM/DMARC is to make
> impersonation of local users by outsiders for the purpose of fraud
> (so-called "BEC") much harder.
>
> For most sending domains, targeted forgery to the world at large is
> a non-problem. No one is out there impersonating you or me in email
> to random strangers for financial gain. Most businesses do not have
> widespread 'brand value' that can be stolen by random broadcast
> forgery.
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.
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: ".
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.
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).
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.
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).
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.
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.
--
Regards,
Jaroslaw Rafa
r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] Guide for setting up a mail server ?
Dnia 11.07.2023 o godz. 18:47:03 Grant Taylor via mailop pisze: > 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. Exactly, because from my experience SPF, DKIM and DMARC bring very little (if anything at all) to security. I have written above - this is only to satisfy Google's requirements. Stupid requirements, IMHO, but as you said - their server, their rules, if I want to send mail to them I need to have (outgoing) SPF, DKIM and DMARC set up. That's the *only* reason why I had set them up at all. > 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. I had (and still have) no problems whatsoever with phishing without having to check SPF, DKIM or DMARC. I simply don't need them. Phishing messages are already caught by antispam filters - I look from time to time into what my antispam filters have caught and I see a few phishing messages there. They are usually so obviously blatant that I wonder how anybody could fall victim to them - like those famous "I have recorded you masturbating to porn websites, send me money" emails. In fact, I receive more phishing via text messages on my phone than I do on my email. The SMS phishing is actually far more dangerous, because on a phone you have very little possibility to check if a message is genuine (there are no headers to look into etc.), and usually shortened links are used in the message, so you don't know where the link points to. But if you use some reasoning, those phishing SMS messages also look little probable to be authentic. Email phishing is from my point of view a practically nonexistent thing. So why bothering configuring tools that are theoretically meant to protect against it (but in my opinion are actually not helpful at all), if they wouldn't bring any benefit? Of course YMMV, as I said. I have never experienced phishing as an actual problem. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
