[ANN] Lua 5.4.0 (work1) now available

classic Classic list List threaded Threaded
164 messages Options
1 ... 6789
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (work1) now available

Albert Chan
On Mar 26, 2018, at 7:38 AM, Charles Heywood <[hidden email]> wrote:

To quote Google Inbox, "Why is this message in Spam? It has a from address that has failed yahoo.com's required tests for authentication."

Make sure that your email clients are set up to properly go through the right SMTP server?


that particular email were sent from yahoo.com !
Perhaps my email has too many spammy words ?

Gmail, this one is not spam
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (work1) now available

Jonathan Goble
In reply to this post by Grey Knight-2
(Apologies for top-posting from my phone)

This has nothing to do with Gmail and everything to do with Yahoo. Several years ago, Yahoo published a DMARC reject policy, which means that for any email with a Yahoo address in the From: header, compliant email providers must authenticate that the message came directly from Yahoo's own servers or else reject it (in practice, mark it as spam). Unfortunately, this breaks all mailing lists, because mailing lists must receive the message, modify it (at least the To: header), and resend it from its own server, resulting in a failed DMARC check.

Yahoo's recommended solution for mailing lists, the last time I checked, was for the list to remove the sender's address from the From: header and replace it with the list's own address, but IIRC there's some internet standard (maybe an RFC?) that doing so violates. So the only real solution is to not use Yahoo addresses with mailing lists. 

On Mon, Mar 26, 2018, 7:58 AM Grey Knight <[hidden email]> wrote:
Perhaps gmail has, erm, a business reason for being overly-strict with emails from this domain. :-)

--
GK


On Monday, March 26, 2018, 12:55:38 PM GMT+1, Dirk Laurie <[hidden email]> wrote:

2018-03-26 12:14 GMT+02:00 Luiz Henrique de Figueiredo <[hidden email]>:

> Messages from yahoo.com are being consistently flagged as spam by my Gmail.
> I've just found the message below in my spam folder. Check yours.
>
> On Fri, Mar 16, 2018 at 3:43 PM, Albert Dinero <[hidden email]> wrote:


If someone not also on yahoo.com replies to the message, then it does
reach my inbox. If not, then clearly the message did not attract much
attention :-)


Reply | Threaded
Open this post in threaded view
|

meta: on mail header forgery (was Re: [ANN] Lua 5.4.0 (work1) now available)

Jay Carlson
Irony: this message will likely be flagged as spam.

Here's the DMARC side, mostly focusing on DKIM. I hope I am not igniting a big flamewar; I think the two positions on this are pretty well-represented between these two messages. I think people of good faith can disagree on this (they do!) even though one of the sides is stuck in the 20th Century. ;-)

On Mar 26, 2018, at 9:19 AM, Jonathan Goble <[hidden email]> wrote:

> [...]
> Yahoo's recommended solution for mailing lists, the last time I checked, was for the list to remove the sender's address from the From: header and replace it with the list's own address, but IIRC there's some internet standard (maybe an RFC?) that doing so violates. So the only real solution is to not use Yahoo addresses with mailing lists.

Someone is using [hidden email] as a From spam address. A lot. What should I do?

The flip answer is "lol abandon your email address." [hidden email] has existed since 1995, and it's a lot more than business cards that would have to be reprinted.

Either DKIM/SPF or traditional mailing lists are broken, and I strongly believe it's the mailing lists. Would you let a mailing list sign messages with your PGP key? No, it should wrap the messages with its own key, since that's the identity of the responsible party.[1][2][3]

I think the explanation below is an unnecessary compromise, but OpenWrt's mailing lists obsequiously do a full wrap of the rfc822 message.[4] The outer message is:

> From: Noah Meyerhans via Lede-dev <[hidden email]>
>
> The sender domain has a DMARC Reject/Quarantine policy which disallows
> sending mailing list messages using the original "From" header.
>
> To mitigate this problem, the original message has been wrapped
> automatically by the mailing list software.

and it includes the original message as an inline MIME rfc822:

> From: Noah Meyerhans <[hidden email]>


At least in Apple Mail, the embedded message really is inline, and functions as a body.

The archives don't bother with the outer message, which is just there to support the "don't change the From header" doctrine. The archives are not sending mail, so it's the HTTPS certificate that would be authenticating that.

https://lists.infradead.org/pipermail/lede-dev/2018-March/011632.html

--
Jay Carlson
[hidden email]

[1]:  Why do we sign headers at all? Because the Internet is a very different, and more hostile place than it was thirty years ago. I know that people don't want to update their mailing list software, but essentially everything else about how we process email in practice has changed.

[2]: The "obvious" way to make this work is for me to delegate partial authority to the mailing list to send mail on my behalf. Thinking about the implementation and usability, I'll say "lol" again.

[3]: Before there was crypto covering the headers, mailing lists could be seen as both pure reflectors and as resenders; there were no significant practical differences. People built their personal mental models around one of the two forms, not really knowing that some people thought of them the opposite way.

Crypto forces the issue. There's no reason you can't build crypto systems that allow broad message header forgery too, to support the reflector model, but they aren't that useful. "From" is arguably the most important mail header today, and systems that don't cover it in some way don't solve many problems. Does anybody support authentication against X-Forwarded-By? Should they?

PGP doesn't cover the headers, so it's fine with both reflectors and resenders, I could live with "reject all message content 'From' [hidden email] which is not PGP- or S/MIME-signed." There's no way to declare that, as far as I know.

I'd also be OK with some kind of magic word in the body that says, "exempt this one message from DKIM". And of course I'm OK with people declaring, "lua-l will not spam me much, so do not reject DKIM-fail messages from it."

What's not acceptable is for random people to be able to wreck an email address casually, remotely, and untraceably. I think a lot of the anti-DKIM people haven't experienced this, or don't believe they'll have this problem.

[4]: Interestingly, this also resolves fights over what "Reply-To" should say. Because the mailing list is forwarding mail under its own identity and responsibility, it can make its own choice of headers on the outer message.

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (work1) now available

Gé Weijers
In reply to this post by Jonathan Goble


On Mon, Mar 26, 2018 at 6:19 AM, Jonathan Goble <[hidden email]> wrote:
(Apologies for top-posting from my phone)

This has nothing to do with Gmail and everything to do with Yahoo. Several years ago, Yahoo published a DMARC reject policy, which means that for any email with a Yahoo address in the From: header, compliant email providers must authenticate that the message came directly from Yahoo's own servers or else reject it (in practice, mark it as spam). Unfortunately, this breaks all mailing lists, because mailing lists must receive the message, modify it (at least the To: header), and resend it from its own server, resulting in a failed DMARC check.

Yahoo's recommended solution for mailing lists, the last time I checked, was for the list to remove the sender's address from the From: header and replace it with the list's own address, but IIRC there's some internet standard (maybe an RFC?) that doing so violates. So the only real solution is to not use Yahoo addresses with mailing lists. 


I added a rule in Gmail to not filter spam in this list (and a few others). I still see the warning when DKIM or DMARC checks fail, but this list does not see much in the way of spam, so it's no big loss.


--

1 ... 6789