To avoid triggering spam filters due to failed signature validation, many
mailing lists mangle the From header to change the From address to be the
address of the list, typically where the sender's domain has a strict DMARC
policy enabled.
In this case, we should try to unmangle the From header.
Stephen Finucane writes:
> On Sun, 2019-09-08 at 23:31 +0100, Stephen Finucane wrote:
>> Hopefully self-explanatory. This closes another gap with the web UI and
>> REST API.
>
> Assuming no one disagrees, I'm going to merge this series before the
> end of the week. It has tests and
On Tue Oct 15, 2019 at 7:44 PM Laurent Pinchart wrote:
> I'm not very confident that perfect transparent e-mail bridges could be
> developed, and the culprit here it e-mail. From forge to e-mail there's
> no real issue, we have structure data, and we write it out in text form.
> The other way
On Tue, 15 Oct 2019 19:37:04 +0300
Laurent Pinchart wrote:
> But how far could we push this reasoning ? I've worked for a company
> whose corporate policy was that all source code had to be stored in SVN,
> not exception. I didn't reach the community to move kernel development
> away from git.
On Tue, Oct 15, 2019 at 06:41:03AM +0200, Dmitry Vyukov wrote:
> On Mon, Oct 14, 2019 at 5:17 PM Greg KH wrote:
> > > As one data point, I cannot send emails with git send-email anymore.
> > > It used to work, then broke and I don't know how to fix it. Now it says:
> > >
> > > 5.7.8 Username and
By default, the events API orders events by date in descending order
(newest first). However, it's useful to be able to order the events by
oldest events first. For example, when a client is polling the events
API for new events since a given date and wishes to process them in
chronological order.
On Tue, Oct 15, 2019 at 07:32:41PM +0300, Laurent Pinchart wrote:
Well, this is largely what GitGitGadget does
(https://gitgitgadget.github.io), and we could go that route, sure. I'm
reluctant only because, quoth:
GitGitGadget itself is a GitHub App that is backed by an Azure
Function
Hi Drew,
On Tue, Oct 15, 2019 at 12:34:57PM -0400, Drew DeVault wrote:
> On Tue Oct 15, 2019 at 7:32 PM Laurent Pinchart wrote:
> > I certainly wouldn't recommend a solution based on a proprietary
> > closed-source stack :-) But as we're talking about performing new
> > development for patchwork,
Hi Steven,
On Tue, Oct 15, 2019 at 08:37:41AM -0400, Steven Rostedt wrote:
> On Mon, 14 Oct 2019 16:56:58 -0400 "Theodore Y. Ts'o" wrote:
>
> > So it's an extreme case, and is an example of corp e-mail insanity.
> > The good news is that for companies that are really serious about
> > working
Hi Konstantin,
On Tue, Oct 15, 2019 at 11:40:10AM -0400, Konstantin Ryabitsev wrote:
> On Mon, Oct 14, 2019 at 06:33:33PM +0300, Laurent Pinchart wrote:
> > If the goal is to work around SMTP-related technical issues, is a web UI
> > really the best way to go ? Wouldn't it be better to do the
Hi Dmitry,
On Tue, Oct 15, 2019 at 06:49:27AM +0200, Dmitry Vyukov wrote:
> On Mon, Oct 14, 2019 at 5:12 PM Laurent Pinchart wrote:
> > On Mon, Oct 14, 2019 at 04:58:17PM +0200, Dmitry Vyukov wrote:
> >> On Fri, Oct 11, 2019 at 7:20 PM Shuah Khan wrote:
> >>> On 10/11/19 2:57 AM, Greg KH wrote:
>
On Tue, Oct 15, 2019 at 11:11:57AM +0200, Dmitry Vyukov wrote:
> On Tue, Oct 15, 2019 at 10:57 AM Eric Wong wrote:
> > Dmitry Vyukov wrote:
> >> As one data point, I cannot send emails with git send-email anymore.
> >> It used to work, then broke and I don't know how to fix it. Now it says:
> >>
>
On Sat, Oct 12, 2019 at 09:19:11AM +0200, Greg KH wrote:
This is basically why SMTP sucks in my view -- and it's worthless
trying to
pick fights with IT departments, because they are told to do so by lawyers.
So, I want to take SMTP out of the equation:
1. provide a way for someone to submit a
On Tue, Oct 15, 2019 at 09:35:27AM -0400, Theodore Y. Ts'o wrote:
On Tue, Oct 15, 2019 at 08:37:41AM -0400, Steven Rostedt wrote:
Now, if we had a way to send and receive upstream patches via a web
site, that would actually make things easier.
Alas, for those corporations who choose to enable
On Tue, Oct 15, 2019 at 08:37:41AM -0400, Steven Rostedt wrote:
> Now, if we had a way to send and receive upstream patches via a web
> site, that would actually make things easier.
Alas, for those corporations who choose to enable DMARC in hard-fail
mode (which includes google.com BTW, although
On Mon, 14 Oct 2019 16:56:58 -0400
"Theodore Y. Ts'o" wrote:
> So it's an extreme case, and is an example of corp e-mail insanity.
> The good news is that for companies that are really serious about
> working with upstream, they will roll out solutions for their own
> customers. For example,
Dmitry Vyukov wrote:
> As one data point, I cannot send emails with git send-email anymore.
> It used to work, then broke and I don't know how to fix it. Now it says:
>
> 5.7.8 Username and Password not accepted. Learn more at
> 5.7.8 https://support.google.com/mail/?p=BadCredentials
>
On Sun, 2019-09-08 at 23:31 +0100, Stephen Finucane wrote:
> Hopefully self-explanatory. This closes another gap with the web UI and
> REST API.
Assuming no one disagrees, I'm going to merge this series before the
end of the week. It has tests and documentation, suggesting it's low
enough risk,
18 matches
Mail list logo
