Re: [mailop] Is forwarding to Gmail basically dead?
On 2/12/2024 7:13 PM, Mark Milhollan via mailop wrote: On Mon, 12 Feb 2024, Dave Crocker wrote: Certificates are not magic symbols of safety. I never said they were. I said, paraphrasing though I see I should have been explicit, that Google could increase the number of people using S/MIME though not any additional MUAs since theirs already has S/MIME support though different. Right. Except almost certainly wrong. Just making certs easier to get will increase S/MIME use. This ignores a collection of other usability and management issues that represent significant barriers to adoption and use. And that's just with S/MIME itself, nevermind the integration of its use into a helpful reception management function. My point is that serious efforts at achieving real efficacy that is better than what we get now will require considerably wider and deeper design thinking that just making certs easier. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
On 2/12/2024 7:16 PM, John Levine via mailop wrote: Right now if you get a message from Gmail or Yahoo with a valid DKIM signature, you can be quite confident that it came from whichever Gmail or Yahoo user is in the From header. By way of using this as an example of the need for larger systems thinking, the assessment that it came from such a user is not in the actual DKIM specification. DKIM's semantic is dramatically less ambitious than that. It only says that the signer had 'some' responsibility for (handling) the message. Very modest semantic, indeed. However operational practice makes it a reasonable assessment, at least for mail signed by some platforms. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
It appears that Mark Milhollan via mailop said: >On Mon, 12 Feb 2024, Dave Crocker wrote: > >> 1. S/MIME has been around for 25 years. While it has gained >>respectable amounts of implementation in MUAs, it has achieved use >>only in specialized environments. > >Google could greatly accelerate its uptake by automatically providing >every freemail account with a certificate (DV cert style, i.e., without >a fullname) and adding it and a signature to every message, and an >indicator on messages received. ... I'm with Dave, I don't see what difference it would make. Right now if you get a message from Gmail or Yahoo with a valid DKIM signature, you can be quite confident that it came from whichever Gmail or Yahoo user is in the From header. There is plenty of signed spam, and S/MIME signatures wouldn't make it any less spammy. R's, John ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
On Mon, 12 Feb 2024, Dave Crocker wrote: On 2/12/2024 4:37 PM, Mark Milhollan via mailop wrote: On Mon, 12 Feb 2024, Dave Crocker wrote: 1. S/MIME has been around for 25 years. While it has gained respectable amounts of implementation in MUAs, it has achieved use only in specialized environments. Google could greatly accelerate its uptake by automatically providing every freemail account with a certificate (DV cert style, i.e., without a fullname) and adding it and a signature to every message, and an indicator on messages received. Certificates are not magic symbols of safety. I never said they were. I said, paraphrasing though I see I should have been explicit, that Google could increase the number of people using S/MIME though not any additional MUAs since theirs already has S/MIME support though different. If only Gmail did it for their freemail that could be called just 1 more specialized environment but it might drive others to implement it breaking a barrier. Haven't they done similar for TLS transport since otherwise messages get a "bad" indicator, or did their effort really do nothing to help increase transport security? Of all of email's problem's, the most intractable is the widespread and continuing insistence that its problems can be solved simply. I only said it might simply increase the level of use, perhaps dramatically, not that it solved anything. /mark ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
On 2/12/2024 4:37 PM, Mark Milhollan via mailop wrote: On Mon, 12 Feb 2024, Dave Crocker wrote: 1. S/MIME has been around for 25 years. While it has gained respectable amounts of implementation in MUAs, it has achieved use only in specialized environments. Google could greatly accelerate its uptake by automatically providing every freemail account with a certificate (DV cert style, i.e., without a fullname) and adding it and a signature to every message, and an indicator on messages received. Certificates are not magic symbols of safety. Please think through the maintenance and use issues, end-to-end, including how to handle new, legitimate folk you've never met before but -- it will turn out -- you don't mind getting an unsolicited message from. Of all of email's problem's, the most intractable is the widespread and continuing insistence that its problems can be solved simply. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
On Mon, 12 Feb 2024, Dave Crocker wrote: 1. S/MIME has been around for 25 years. While it has gained respectable amounts of implementation in MUAs, it has achieved use only in specialized environments. Google could greatly accelerate its uptake by automatically providing every freemail account with a certificate (DV cert style, i.e., without a fullname) and adding it and a signature to every message, and an indicator on messages received. Automatic, no muss, no fuss. If they did that a goodly fraction of global email could be signed within a year. They could go further, collecting certificates and encrypting when writing to those contacts so that user-to-user encrypted email could become globally significant -- yes there are tedious details involved. Most likely Apple, Microsoft, and Yahoo could as well accelerating things further. Sadly I doubt any of them will, and for smaller operators it is too cost prohibitive to consider as yet. Or for that matter Google might do similar with OpenPGP, as well or instead of S/MIME. Smaller providers could do this, but alas I doubt enough would. Of course not everyone wants signed or encrypted email, so probably it would need to be opt-in. And many mailing lists would still have issues since they want to alter the message body. /mark ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: Is forwarding to Gmail basically dead?
On Mon, Feb 12, 2024 at 2:48 PM Damon via mailop wrote: > > I do believe attaching anti-spam/anti-phish benefits to the promotion > of BIMI was a poor choice. > Wait. Somebody managed to combine two dumpster fire topics into one? Forwarding and BIMI? Well done... -- Marcel ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Why is mail forwarding such a mess?
On 12.02.24 21:21, Bill Cole via mailop wrote: The mail server providing the redirection may not be doing what the original address owner OR the owner of the address to which they are redirecting actually wants. Redirection could allow malicious server operators to direct 3rd parties to send unwanted mail to an unrelated victim or to send wanted mail which should be private to those from which it is meant to be kept secret. There is no standard way to record such a redirection in a Received header or any other header which would document why a message was routed in a particular way and no way for the sending system to validate that the redirection is benign. As a sender I do have to trust all servers in the chain to the recipient anyway? Any of those could be run by a malicous server operator. Even without redirection anything you describe could be done to those mails already. A Received line might look like: Received: from server.it.tried.to.send.to by redirecting.server (Postfix) with ESMTPS id 12345 for ; Mon, 12 Feb 2024 21:33:50 +0100 (CET) Ah well, it's a theoretical discussion anyway. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
> BIMI is a marketing protocol, for promoting brand logos. What anti-abuse > benefit do you believe accrues with its use, and how exactly do you believe > it will achieve that? > > d/ But Dave - It only costs $1300USD per domain and $500USD for each additional domain for the cert, not including all the other costs for the aforementioned anti-abuse benefits. What a deal!.. or do I mean steal. I do believe attaching anti-spam/anti-phish benefits to the promotion of BIMI was a poor choice. It's pure marketing imho. As an email receiver, programmatically I can't verify the mark, so this is left to the human reader to attempt to do so. I don't have any issues with it being used as an extension of branding. -Damon ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
On 2/9/2024 1:16 AM, Taavi Eomäe via mailop wrote: My hope is that at some point we would be able to do "BIMI" with just S/MIME signed mail at some point. Seems like a good combination. 1. S/MIME has been around for 25 years. While it has gained respectable amounts of implementation in MUAs, it has achieved use only in specialized environments. Any technology with a record that poor should be treated extremely skeptically, when considering future use. 2. BIMI is a marketing protocol, for promoting brand logos. What anti-abuse benefit do you believe accrues with its use, and how exactly do you believe it will achieve that? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] RSA-SHA1 DKIM signatures still in use?
SHA-1 was SHOULD NOT for a decade, but still in too wide of use, so we chartered DCRUP at the IETF to deprecate it (and keys < 1024 bits) and also to separately add ed25519. Here's the RFC deprecating SHA-1: https://datatracker.ietf.org/doc/rfc8301/ Chances are both your examples are using the same platform to send mail, that still hasn't gotten the message. If you can shed some light on the actual sending services (privately is probably best, vs to the whole list), M3AAWG is next week and a discussion can probably be had... Seth On Mon, Feb 12, 2024 at 3:12 PM Scott Mutter via mailop wrote: > How is everyone handling senders that sign their emails with RSA-SHA1 DKIM > keys? > > I'm a bit surprised to see eBay and Match.com sending out messages using > SHA-1. > > I'm seeing a lot of signatures coming in that use SHA-1 but most of the > domains are questionable at best. But eBay and Match.com caught my eye as > being larger companies that I would expect to know better. > > To be clear, eBay is sending out some messages with SHA-256 hash, but they > are also sending out some with a SHA-1 hash. It appears to be the dkim1k > selector that is SHA-1. > > The Match.com (d=connect.match.com) is using the 102022s2048 selector > with SHA-1. > > Just wondering what everyone else is doing with these? I thought SHA-1 > was deprecated a long time ago. > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > -- *Seth Blank * | Chief Technology Officer *e:* s...@valimail.com *p:* This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Why is mail forwarding such a mess?
On 2024-02-12 at 14:23:39 UTC-0500 (Mon, 12 Feb 2024 20:23:39 +0100) Thomas Walter via mailop is rumored to have said: > Hey Bill, > > On 12.02.24 17:31, Bill Cole via mailop wrote: >> On 2024-02-12 at 07:13:13 UTC-0500 (Mon, 12 Feb 2024 13:13:13 +0100) >> Thomas Walter via mailop >> is rumored to have said: >> >>> There are other issues with this though. For example you are exposing >>> information you might not want to. >> >> Beyond that, it would enable both malicious reflection attacks and improper >> diversion of mail with very little visibility. > > > I am not sure I understand your concerns, how would those work? The mail server providing the redirection may not be doing what the original address owner OR the owner of the address to which they are redirecting actually wants. Redirection could allow malicious server operators to direct 3rd parties to send unwanted mail to an unrelated victim or to send wanted mail which should be private to those from which it is meant to be kept secret. There is no standard way to record such a redirection in a Received header or any other header which would document why a message was routed in a particular way and no way for the sending system to validate that the redirection is benign. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
On 2/9/2024 6:50 AM, Scott Mutter via mailop wrote: I think the issue with SPF and DKIM is that it's becoming trivial for ALL email to have SPF and DKIM that pass muster. At which point, you're right back where you started. At the start, we had no way to assess email streams. Good mixed with bad in ways that made it almost impossible to distinguish them. With SPF and DKIM, receivers have relatively 'noise free' message flows. A flow that has an authenticated identifier associated with it is highly likely to actually be email associated with the owner of that identifier. This permits relatively noise-free analysis of their behavior, without concern that some other factor -- like someone else using the identifier -- is injecting email into that flow. In fact, it is /good/ that bad actors also use these technologies, since it makes it much easier to identify their crappy email. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] [ADMIN] Why is mail forwarding such a mess?
Note: not specifically in response to the message I'm replying to! Having just read the last 30 or so messages in this thread, I'm afraid it's all starting to feel very very circular. 1. Forwarding is a basic feature of MUAs and mail systems, whether by user choice, rules, or "forward all" regardless of platform or mechanism. That's been reality since (arbitrary year) 1997. 2. It can cause both technical and user-side problems due to authentication chains being broken. 3. SPF, DKIM, DMARC & ARC all exist. 4. None of them - or even all of them together! - aren't the singular answer to 2. 5. See 1. I'm pretty sure we could all add a couple of extra dimensions (or even additional cryptographic DNS signing/non-refutation/non-repudiation protocols) for extra clarity, but points 1 and 5 are fixed and fairly indisputable. Unless there's anything that's really clearly new and helpful to the discussion, let's just agree: Forwarding is problematic, and it isn't 1997 any more. (Also: the corporate/institutional risks of automatic forwarding and data breaches aren't as well understood by end users as we may wish them to be) Cheers! Graeme [PS up to two miles on foot now before my leg muscles cry STOP!] ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] RSA-SHA1 DKIM signatures still in use?
How is everyone handling senders that sign their emails with RSA-SHA1 DKIM keys? I'm a bit surprised to see eBay and Match.com sending out messages using SHA-1. I'm seeing a lot of signatures coming in that use SHA-1 but most of the domains are questionable at best. But eBay and Match.com caught my eye as being larger companies that I would expect to know better. To be clear, eBay is sending out some messages with SHA-256 hash, but they are also sending out some with a SHA-1 hash. It appears to be the dkim1k selector that is SHA-1. The Match.com (d=connect.match.com) is using the 102022s2048 selector with SHA-1. Just wondering what everyone else is doing with these? I thought SHA-1 was deprecated a long time ago. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] mail wrapping, Is forwarding to Gmail basically dead?
It appears that Laura Atkins via mailop said: >-=-=-=-=-=- >-=-=-=-=-=- > >The problem with encapsulating like that is it basically makes it impossible >to respond to the original email sender. It destroys >functionality that has been around since the early stages of email. If we’re >going to break email for people, then we should at >least give them some good reason to break it. > >So what is the tangible win here? When I was trying to figure out how the IETF should mitigate DMARC list damage, I did a bunch of experiments. Those included wrapping messages in various ways, including the one suggested here. The wrapping worked fine, but few mail programs and no webmail displayed them in usable ways. Perhaps ironically, the older the mail program, the better it worked. Alpine was fine, easy to see the internal message and reply to it. Roundcube web mail is also OK, but it went steeply downhill from there. So we did the author rewrite and forward hack instead. R's, John ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Why is mail forwarding such a mess?
Hey Bill, On 12.02.24 17:31, Bill Cole via mailop wrote: On 2024-02-12 at 07:13:13 UTC-0500 (Mon, 12 Feb 2024 13:13:13 +0100) Thomas Walter via mailop is rumored to have said: There are other issues with this though. For example you are exposing information you might not want to. Beyond that, it would enable both malicious reflection attacks and improper diversion of mail with very little visibility. I am not sure I understand your concerns, how would those work? Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ 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've encountered more problems with Microsoft's systems than with GMail's, although I do agree that GMail is far from perfect. I don't recall any delivery problems to Yahoo's systems for any of our users. > 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. Some eMail systems accept-and-delete [at least some] messages instead of rejecting with a 5yz code, which tends to result in users incorrectly blaming the sender, especially (it seems) when the receiving system that they're relying on doesn't provide any technical support (e.g., because it's a free service). > But sadly it's not a common attitude nowadays. I agree, and I suspect a major part of the problem is that many users have come to expect unreliability from their Operating Systems, and so that attitude ends up extending (quite unfairly in many cases) to other technologies ... such as eMail. Users get comfortable with other things too, such as accepting an endless barrage of security warnings just because there are so many of them in some environments. Most users are non-technical, so there's a tendancy to develop coping habits instead of considering warnings with a critical eye, and I find it hard to blame users for this because they just want/need to be productive without having to decipher warnings filled with computer-industry jargon and require a lot of extra work on their part to parse-and-understand. -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, Beautiful British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
It appears that Sebastian Nielsen via mailop said: >-=-=-=-=-=- >-=-=-=-=-=- >You just regard all email which passes DMARC as trusted, as if the mail was >S/MIME signed by the sender personally.The sender has >chosen to trust that shared provider. Its not "your problem" as a receiver if >that mail is fraudulent.If you act on a fraudulent >email, sent by a fraudster via a shared host which does not employ user >separation, you simply act as the email was genuine, and >charge the claimed sender of any mishaps that arise out of the email.After >all, sender is in a position to choose a provider that >does employ user separation, but did not, eiter intentionally or by negligect. >Sender bears ALL responsibility.Best regards Um, nothing personal, but I am glad I am not one of your mail users. R's, John ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Why is mail forwarding such a mess?
On 2024-02-12 at 07:13:13 UTC-0500 (Mon, 12 Feb 2024 13:13:13 +0100) Thomas Walter via mailop is rumored to have said: > There are other issues with this though. For example you are exposing > information you might not want to. Beyond that, it would enable both malicious reflection attacks and improper diversion of mail with very little visibility. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire signature.asc Description: OpenPGP digital signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
> On 12 Feb 2024, at 14:33, Sebastian Nielsen via mailop > wrote: > > >>Do they also allow you to search for the original sender? > No not via sender search, as the encapsulated email is part of the BODY of > the container email. > So usually you have to search via body search. So you are still changing the fundamental way email works. > > >>And, again, what is the overall benefit to the end user from this scheme? > Benefit is that email can be verified in a more streamlined way, which > minimizes phishing and spam, if no servers are authorized to use any other’s > email address, even if forwarding an email. > It benefits users in the long run, as less and less people will be scammed by > bank phishing and similar schemes, making email a more secure communication > medium, by using already established systems like SPF, DMARC and DKIM to > verify email’s legitimacy. Is this actually the case, though? I’ve heard a lot of folks claim that, somehow, SPF, DMARC and DKIM verify an email’s legitimacy. But we’ve seen how bad actors are currently sending malicious mail that pass SPF and DMARC or DKIM and DMARC. I mean, someone created a PayPal account and sent PayPal phish that passed DMARC. Other folks have used SPF escalation attacks to send DMARC passing phishing mail. These attacks are happening so how does breaking forwarding help the end user? What is to stop the bad actors from setting up systems where they are simply forwarders who create a fake email with SPF / DKIM and DMARC and then encapsulate it and forward it on to the end user? Additionally, most actual research shows that trust indicators simply don’t work for end users. I’ve seen studies related to email trust / brand indicators in the inbox not changing user behavior and there are lots of studies that show that’s the case with the web and the lock or the green bar or whatever type of SSL there is. So we have a situation where a) trust indicators can’t be trusted because they are already being exploited by bad actors to send SPF / DKIM / DMARC passing email and b) wrapping up an email and forwarding it through an untrusted source means authentication can be trivially forged, and c) trust indicators don’t actually work. In the face of those facts, what value does this bring to email? laura -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Hi, On Mon, Feb 12, 2024 at 02:44:43PM +0100, Sebastian Nielsen via mailop wrote: > >> it basically makes it impossible to respond to the original email sender > > Nope, you just open the encapsulated email (open the .EML attachment), and > respond to that. Going back to my anecdote that last month a poster to the North American Network Operators Group mailing list complained about the changing of subject lines "messing up" message grouping in gmail, as if Gmail's UI was the optimal/only way for email threads to be presented: also in the last couple of months someone on the UK Network Operators Forum mailing list complained that "DMARC messes up the format of list email". What I eventually established was that they were referring to this Mailman DMARC mitigation setting of encapsulating a post inside a post from the list server, when the sender has a DMARC policy of reject etc. I do not recall which of the major mailbox providers they were using for it to look "messed up" but again the issue here is that even some of the most technically adept users on the Internet today are not using email software that copes well with that. There is a big gap in the user experience and user training that I'm not sure any entity has the will and ability to plug. Myself, I appreciate the encapsulation option for the reasons you state. I understand what's going on and my mail software copes with it¹. But I don't find it usable in general at this time. Thanks, Andy ¹ Though I do use "notmuch" quite extensively and haven't yet found a good way to have it index such emails: from notmuch's point of view it only records the header keywords of the outer email container, with the inner [arts only being matchable by body text search. In simple words: $ notmuch search 'from:joe.blo...@example.com' will not match list mail from joe.blo...@example.com that's been encapsulated in such a fashion. -- https://bitfolk.com/ -- No-nonsense VPS hosting ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
>>Do they also allow you to search for the original sender? No not via sender search, as the encapsulated email is part of the BODY of the container email. So usually you have to search via body search. >>And, again, what is the overall benefit to the end user from this scheme? Benefit is that email can be verified in a more streamlined way, which minimizes phishing and spam, if no servers are authorized to use any other’s email address, even if forwarding an email. It benefits users in the long run, as less and less people will be scammed by bank phishing and similar schemes, making email a more secure communication medium, by using already established systems like SPF, DMARC and DKIM to verify email’s legitimacy. Best regards, Sebastian Nielsen ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Am 09.02.2024 um 13:59:57 Uhr schrieb Andy Smith via mailop: > When these people are your paying customers, or you are being paid > to get email to these people, there is limited up side in berating > people about their choice of mail service. A fact which of course is > used and abused by the huge mailbox providers for their commercial > benefit. I don't see any way to fulfill that without the disadvantages it has. -- Gruß Marco Spam und Werbung bitte an ichschickerekl...@cartoonies.org ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Am 09.02.2024 um 22:06:05 Uhr schrieb Sebastian Nielsen via mailop: > Or people could stop forwarding emails in idiotic ways, because when > you forward an email, you are actually forging the original sender. > > > Ergo, if you forward a email from genuineu...@genuineserver.com to > myacco...@gmail.com via an account called exam...@example.org .. > Technically, you encapsulate the email in a new message/rfc822 object > and add "Fwd: " in the subject header. If you forward spam (automatic forwarding), you will be listed as the spammer because even DKIM is valid. Filters on the sender won't work anymore at the destination the forwards points to. S/MIME will be applied to the forwarded messages and people will assume everything is fine even when the original message is forged. -- Gruß Marco Spam und Werbung bitte an ichschickerekl...@cartoonies.org ___ 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?
Am 10.02.2024 um 15:52:22 Uhr schrieb Andre van Eyssen: > On Fri, 9 Feb 2024, Marco Moock via mailop wrote: > > > Outlook supports that and knowing about it is a question of > > training. > > I'd like to suggest that understanding of email is declining in the > general population. "Training" is a big ask when the grasp of the > basics is mostly missing. I agree with that, but security is nasty for those people at any time, but necessary if you want to avoid certain attacks. -- Gruß Marco Spam und Werbung bitte an ichschickerekl...@cartoonies.org ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
> On 12 Feb 2024, at 13:44, Sebastian Nielsen via mailop > wrote: > > >> it basically makes it impossible to respond to the original email sender > Nope, you just open the encapsulated email (open the .EML attachment), and > respond to that. > > Some mail clients show the encapsulated email in a “frame” which has its own > reply buttons. Do they also allow you to search for the original sender? Or is this another way we’re hiding the sender of a message (much like rewriting mailing lists do)? And, again, what is the overall benefit to the end user from this scheme? laura -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ 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] Is forwarding to Gmail basically dead?
>> An "anonymous" proxy, configured specifically to hide the original poster No, all proxies are per definition anonymous unless they specifically add the header X-Forwaded-For. Otherwise, the IP becomes “automatically” hidden, if it passes communication unmodified. That’s why they have become responsible in many cases. People who don’t understand proxies, just set up one, without configuring it properly, and then it starts forwarding traffic anonymously without adding any identification headers. >> Like the telecom operator job is to pass any traffic and not to block >> anything. It’s a entirely different thing, when traffic is passed at a lower layer than layer 7. When you pass traffic at a lower layer than layer 7, then you are just a mere conduit and the “ISP” exception of responsibility apply. Same applies if you forward traffic internally in a organization, as you are just passing the ethernet packets to its final destination. 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. Think like this: A mail is destined from sen...@sender.com to forwardacco...@forwardoperator.org forwardacco...@forwardoperator.org then forwards the email to someu...@anotheraccount.com When the first mail is sent, then forwardoperator.org is the defacto recipient of the message. They receive the message. But due to a configuration in their server, that message is now sent (as a new message) to someu...@anotheraccount.com Do you understand why the forward operator (and the proxy operator) receives responsibility now? So its nothing wrong that people who configure a email forward, becomes responsible for the messages they forward. It is as it should be. If you want to do forwarding on a lower level than layer 7, then you simply "aim" the domain's MX records to the final SMTP, and then configure that SMTP to accept mails for another domain, and LOCALLY forward that email into a specific account. That may require a paid account at some email operators. The local forward will ensure any validations doesn't fail, because then its already inside that mail operator's file system, and thus all signatures and similar are already verified. Best regards, Sebastian Nielsen ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
>> it basically makes it impossible to respond to the original email sender Nope, you just open the encapsulated email (open the .EML attachment), and respond to that. Some mail clients show the encapsulated email in a “frame” which has its own reply buttons. Best regards, Sebastian Nielsen ___ 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] Is forwarding to Gmail basically dead?
The problem with encapsulating like that is it basically makes it impossible to respond to the original email sender. It destroys functionality that has been around since the early stages of email. If we’re going to break email for people, then we should at least give them some good reason to break it. So what is the tangible win here? laura > On 12 Feb 2024, at 11:15, Sebastian Nielsen via mailop > wrote: > >>> Many antispam filters will right away classify such an email as spam. > > No, that’s not true, UNLESS the antispam filter resides as a local software > in the client's software as a plugin to the email client, which would of > course detect the "attached file" even its not technically an attached file. > > Remember that it’s the end user client who renders the encapsulated email as > an attachment. > Technically it is not an attachment, and will not get detected as an > attachment in mail filters. > Its technically an email encapsulated in an outer email. > NDR also is technically the original email encapsulated in an outer email. > > Technically, an encapsulated email looks like this: > > From: exam...@example.org > To: exam...@example.com > Subject: Fwd: Hi! > Content-Type: message/rfc822 > > From: exam...@example.org > To: exam...@example.com > Subject: Hi! > Content-Type: text/plain > > Content text. > > Spam filters react on 'Content-Disposition: attachment; filename="test.txt"' > and similar things. > >>> Conceptually, it's more like a HTTP proxy server. > > No, because in the proxy case, it’s the "sender" who asks the proxy server to > "fetch" something from "receiver"s location. It’s the opposite way, the > "sender" trust the proxy, and know that the "content" is genuine if he trust > the proxy, thus the proxy bears no responsibility for the content from a > location he asked the proxy to fetch content from. > > 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). > > -- > You could see it more like a reverse proxy. > > A reverse proxy is a proxy, which is configured to show a domain (let's say > example.org) and show another web page (let's say letsencrypt.org) inside. > The reverse proxy of course bears ALL responsibility for the content its > "hosting" via its proxy function, meaning if letsencrypt.org would > accidentially host something illegal, the proxy owner will take the blow for > the content visible via "his website". > > Best regards, Sebastian Nielsen > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Why is mail forwarding such a mess?
On 12.02.24 11:59, Jaroslaw Rafa via mailop wrote: 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 . I do think that was the idea. If they don't, at least the user would be informed, but no user reads those error messages... There are other issues with this though. For example you are exposing information you might not want to. But then, so would bounces in case of currently used forwarding methods (plus backscatter...) Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Jaroslaw Rafa via mailop skrev den 2024-02-12 11:34: 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. gives less problems, not more problems to solve ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
>>Many antispam filters will right away classify such an email as spam. No, that’s not true, UNLESS the antispam filter resides as a local software in the client's software as a plugin to the email client, which would of course detect the "attached file" even its not technically an attached file. Remember that it’s the end user client who renders the encapsulated email as an attachment. Technically it is not an attachment, and will not get detected as an attachment in mail filters. Its technically an email encapsulated in an outer email. NDR also is technically the original email encapsulated in an outer email. Technically, an encapsulated email looks like this: From: exam...@example.org To: exam...@example.com Subject: Fwd: Hi! Content-Type: message/rfc822 From: exam...@example.org To: exam...@example.com Subject: Hi! Content-Type: text/plain Content text. Spam filters react on 'Content-Disposition: attachment; filename="test.txt"' and similar things. >>Conceptually, it's more like a HTTP proxy server. No, because in the proxy case, it’s the "sender" who asks the proxy server to "fetch" something from "receiver"s location. It’s the opposite way, the "sender" trust the proxy, and know that the "content" is genuine if he trust the proxy, thus the proxy bears no responsibility for the content from a location he asked the proxy to fetch content from. 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). -- You could see it more like a reverse proxy. A reverse proxy is a proxy, which is configured to show a domain (let's say example.org) and show another web page (let's say letsencrypt.org) inside. The reverse proxy of course bears ALL responsibility for the content its "hosting" via its proxy function, meaning if letsencrypt.org would accidentially host something illegal, the proxy owner will take the blow for the content visible via "his website". Best regards, Sebastian Nielsen ___ 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?
You just regard all email which passes DMARC as trusted, as if the mail was S/MIME signed by the sender personally.The sender has chosen to trust that shared provider. Its not "your problem" as a receiver if that mail is fraudulent.If you act on a fraudulent email, sent by a fraudster via a shared host which does not employ user separation, you simply act as the email was genuine, and charge the claimed sender of any mishaps that arise out of the email.After all, sender is in a position to choose a provider that does employ user separation, but did not, eiter intentionally or by negligect. Sender bears ALL responsibility.Best regards Sebastian Nielsen Originalmeddelande Från: Slavko via mailop Datum: 2024-02-11 22:19 (GMT+01:00) Till: 'Mailing List' Ämne: Re: [mailop] Is forwarding to Gmail basically dead? Dňa 11. februára 2024 19:06:31 UTC používateľ Sebastian Nielsen via mailop napísal:>>>On my site, users can use only own address/aliases, but i can use any (including any domain)...>>Of course since you are administrator. Nothing strange with that.It was not meant as self-presentation, but as particular examplethat one site can have multiple different rules.>It all about trust. Choose providers you trust.But i asked as receiver how to verify, not as domain owner. Asreceiver i cannot choose from which provider message arrives,but i have to decide if i will accept it or not. The DMARC (etc)is tool to help me to choose properly/better, but in case ofshared site its success can be as useful as dice roll...Anyway, what is trusted for domain owner not necessarymust be trusted for receiver too and vice versa...regards-- Slavkohttps://www.slavino.sk/___mailop mailing listmailop@mailop.orghttps://list.mailop.org/listinfo/mailop___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
