Re: [mailop] forwarding to gmail - problem

[Jaroslaw Rafa via mailop]

Dnia  8.05.2022 o godz. 16:59:29 Hans-Martin Mosner via mailop pisze:
> Am 08.05.22 um 15:27 schrieb Scott Mutter via mailop:
> >If you forward your mail to Google then Google is going to get your email.
> >
> >If you give Google your POP password to retrieve mail, then Google is
> >going to get your email.
> >
> >What more is Google going to get with your POP password versus plain
> >old forwarding email?
> 
> This is assuming that the POP password is different from the SMTP auth
> password (which for most account it isn't).

And, more important, from SSH (or any other service) password, which it
usually also isn't. One should not think of a mail account as a "mail-only"
account. There may be multiple services involved, that are protected with
the same login credentials.

And speaking of email, POP password will be usually the same and IMAP
password, and with IMAP one can get access to mail stored in other folders
in your account, not only the inbox messages you are "forwarding" to Google.
-- 
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] forwarding to gmail - problem

[Andrew C Aitchison via mailop]

On Sun, 8 May 2022, Hans-Martin Mosner via mailop wrote:


Am 08.05.22 um 15:27 schrieb Scott Mutter via mailop:

If you forward your mail to Google then Google is going to get your email.

If you give Google your POP password to retrieve mail, then Google is
going to get your email.

What more is Google going to get with your POP password versus plain
old forwarding email?


This is assuming that the POP password is different from the SMTP auth 
password (which for most account it isn't).


So if you give Google your POP password you also enable them to send mail 
through your mail account. They most likely wouldn't care and would not be 
using that option, but I would not like it anyway.


In addition, when you're using legacy mail (read UN*X) systems your mail 
account and login credentials may be the same. I know that's nowadays 
considered malpractice, but it still happens.


And Brandon just said (IIUC) that GMail POP collection doesn't (yet)
support OAUTH2, so one of the sensible ways of making them different 
is not available. If your organisation has single sign on that may

mean that google has access to your file server :-(

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Scott Mutter via mailop]

If you forward your mail to Google then Google is going to get your email.

If you give Google your POP password to retrieve mail, then Google is
going to get your email.

What more is Google going to get with your POP password versus plain
old forwarding email?

On Sun, May 8, 2022 at 6:00 AM Jaroslaw Rafa via mailop
 wrote:
>
> Dnia  6.05.2022 o godz. 14:41:49 John Levine via mailop pisze:
> >
> > Until then, I tell people who ask me to forward mail to Gmail that if
> > they actually want to get the mail, I'll put it in a local mailbox and
> > they can tell Gmail to poll it with POP.  That works quite well.
>
> As I already noted, by doing this you are giving Google the credentials to
> your mail account. This is a bad idea.
> --
> 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
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Jaroslaw Rafa via mailop]

Dnia  6.05.2022 o godz. 14:41:49 John Levine via mailop pisze:
> 
> Until then, I tell people who ask me to forward mail to Gmail that if
> they actually want to get the mail, I'll put it in a local mailbox and
> they can tell Gmail to poll it with POP.  That works quite well.

As I already noted, by doing this you are giving Google the credentials to
your mail account. This is a bad idea.
-- 
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] forwarding to gmail - problem

[Brandon Long via mailop]

On Fri, May 6, 2022 at 2:31 PM Andrew C Aitchison via mailop <
mailop@mailop.org> wrote:

>
> > On Fri, May 6, 2022 at 8:52 PM John Levine via mailop  >
> > wrote:
> >> Until then, I tell people who ask me to forward mail to Gmail that if
> >> they actually want to get the mail, I'll put it in a local mailbox and
> >> they can tell Gmail to poll it with POP.  That works quite well.
>
> Yes, if you are happy to let Google have a password on your system ...
>
> [ I'm off to look at the guarantees that Google make about what
>they will and wont do with the user's email, especially given
>the guarantees they ask if fetchmail and alpine are to be
>allowed to use XOAUTH2/OAUTHBEARER to access to gmail.  ]
>

I do wish we supported oauth2 better, it's a requirement for Gmailify, but
pop fetching
still doesn't support it.  Supposedly the discovery and registration stuff
is now available,
but I don't know if there's any movement towards supporting them.

That said, if all that password is protecting is the email, then oauth
tokens are only incrementally
safer than the password.  Users typically have a lot of other data
available with their Gmail passwords,
so the restricted scope of OAUTH is important.

As for the requirements for clients to access Google data, they are
somewhat onerous, but
that's what happens when folks abuse things.


> Francesco Gennai via mailop replied:
> > I agree with you. But then people complain about the delay in
> > getting the email.  It seems to me that there is no option in Gmail
> > to specify a POP polling interval.
>

The polling interval is adaptive, the more often it finds mail, the more
often it polls... with limits on
the interval in both directions.  I don't recall the lower limit, but it's
certainly not low enough to even come
close to mimicing forwarding.

It used to be that if you had set up mail fetching, clicking the refresh
icon on your inbox on the web would cause a new
poll, with some minimum spacing that was lower than the usual polling
interval, I have no idea if that's still true.


> Can they use IMAP with IDLE ?
>

Could we?  I mean, it's just a matter of programming... and the resources
to maintain N million open connections.
And the extra usage on everyone else.

Brandon
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Brandon Long via mailop]

On Fri, May 6, 2022 at 12:48 AM Dan Mahoney  wrote:

> Two inline thoughts.
>
> On Apr 30, 2022, at 4:48 PM, Ángel via mailop  wrote:
>
> On 2022-04-29 at 10:28 -0700, Brandon Long wrote:
>
> There have been other reports on this list of Gmail requiring
> authenticated email.
>
> We don't require authenticated email... but we vastly prefer it, and
> that preference has only increased over time.  And the dkim replay
> attacks have meant increasing the scrutiny of messages which are dkim
> authn but not spf authn, which of course can hurt forwarding.
> Forwarding is getting the short end of the stick in that
> toss up.
>
> The above rejection isn't for the dkim replay case, of course, it's
> for no authn at all.
>
>
> Yep. I completely understand it's not authenticated. The problem is,
> it's out of our reach to authenticate that third party email. It's the
> recipient who wants to receive it.
>
>
> SRS style rewriting allows the forwarder to get feedback if the
> forwarding destination address goes away, > and do bounce handling...
> and prevent bounces from going back to the original sender, exposing
> the destination address. There are good reasons to do the rewrite,
> but not as likely for the average procmail user, and having a good
> spam filter that doesn't forward is very important.
>
>
> What’s the threshold for not forwarding?  If a user is at some point used
> to receiving all mails, but with SA’s default score of 5 tagged with a
> standard *SPAM header, or an X-Spam-Status header, gmail should
> easily recognize that it’s a forwarding account.
>
> There are going to be false positives to a spam filter — and what should
> happen with those?  They get not-forwarded and put in a mailbox on the
> forwarding server that the user literally never checks?  Rejected at SMTP
> time, for fear of gmail?
>
> And then there are false negatives, which will make a forwarding server
> seem more spammy, unless *my* spam filter and *gmails* are in perfect
> harmony.
>
> To the point that when I send a new mail to a gmail user, it’s routed to
> the spam folder, because “Lots of mail from prime.gushi.org is spam”.
> Seriously.  With nothing showing in postmaster.
>

Worse is if the spam filter sticks the ***Spam*** in the subject, thereby
guaranteeing to break  the DKIM signature.

We also don't want to learn from your spam filter, and we usually find that
the spam markings third parties put on email is much worse than our own,
and lead to our users complaining about our anti-spam performance even
though it's due to their own filters. (this is in the enterprise space
where you can do this type of integration)

That said, we don't expect that your spam performance needs to match ours.
You just want to make sure that most of the mail you forward isn't spam.
99% non-spam isn't the goal you need.

There’s a couple of very standard headers that the common open source
> filters add (spamassassin, crm, dspam). Gmail could trivially recognize
> upstream spam filters (per
>
sending-host) and act on them.   They choose not to.
>

I think there is an overestimation here of how common these things are, if
you eliminate mailing lists and complicated enterprise setups (where they
do have these controls), the amount of forwarded mail is pretty small.
There are always trade-offs when prioritizing engineering effort, and
spammers are happy to game anything they can.

Anyways, yes, the previous thread years ago said "forward non-spam, let
user's pop spam and other things that fail to forward" which is not the
level of effort anyone wants to do.

Brandon
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Brandon Long via mailop]

On Fri, May 6, 2022 at 10:58 AM Andrew C Aitchison via mailop <
mailop@mailop.org> wrote:

>
> On Fri, 6 May 2022, Grant Taylor via mailop wrote:
> > On 5/6/22 9:14 AM, Luis E. Muñoz via mailop wrote:
> >> I think the response to those issues are in part the cause for the loop
> you
> >> cleverly explained before.
> >
> > Indeed.
> >
> > These are the very issues that caused me to be disinclined to stand my
> ARC
> > milter back up when it fell over after an update.
> >
> > ARC seems to be dependent on trusting the signer.  That trust is
> inherently
> > difficult to establish.
>
> Can anyone (Brandon?) tell us how Google scores the forwarder for a
> forwarded ARC-signed message compared to the same message without ARC ?
>
> I would hope that the forwarder would get some credit for making
> the details of the previous hop sufficiently reliable to score.
>
> If so, then it is useful to ARC-sign a message when forwarding, even
> when we have no data upon which to evalate incoming ARC signatures.
>

There is a chicken & egg problem with ARC signing, and partially due to
that our usage of
them is still very much a work in progress.

Brandon
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Brandon Long via mailop]

On Fri, May 6, 2022 at 2:50 PM Grant Taylor via mailop 
wrote:

> On 5/6/22 1:24 PM, Francesco Gennai via mailop wrote:
> > But the true problem is that they think that the email is an instant
> > messaging system :-(
>
> I have a knee jerk reaction of telling people that email is not instant
> messaging when they talk about it taking less than 5 minutes for a
> message to get through.  They often look at me funny and I just glare at
> them until they give up.
>
> I'll make references to /actual/ instant messaging protocols, or gasp,
> the telephone.
>

There is the existence of the implicit SLO ... otherwise known as the
status quo.

If the status quo is that email is basically as fast as instant messaging,
then eventually
that is what your users expect.

The concept you really want to get across is the difference between
synchronous and asynchronous
communication, which is an expectation on when a user will see/respond to
your message.

Of course, the medium implies what the expected communication type is, or
may even force one
over the other (a paper letter can't really be anything but
asynchronous)... but there are plenty of
mediums where both occur... modern chat apps like Slack have a whole
complicated realm of new nuances
for that, and voicemail and telemarketing definitely pushed POTS towards
async.

You can always argue with your users about their expectations, just don't
expect them to share them.

Brandon
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Grant Taylor via mailop]

On 5/6/22 1:24 PM, Francesco Gennai via mailop wrote:
But the true problem is that they think that the email is an instant 
messaging system :-(


I have a knee jerk reaction of telling people that email is not instant 
messaging when they talk about it taking less than 5 minutes for a 
message to get through.  They often look at me funny and I just glare at 
them until they give up.


I'll make references to /actual/ instant messaging protocols, or gasp, 
the telephone.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Andrew C Aitchison via mailop]

On Fri, May 6, 2022 at 8:52 PM John Levine via mailop 
wrote:

Until then, I tell people who ask me to forward mail to Gmail that if
they actually want to get the mail, I'll put it in a local mailbox and
they can tell Gmail to poll it with POP.  That works quite well.


Yes, if you are happy to let Google have a password on your system ...

[ I'm off to look at the guarantees that Google make about what
  they will and wont do with the user's email, especially given
  the guarantees they ask if fetchmail and alpine are to be
  allowed to use XOAUTH2/OAUTHBEARER to access to gmail.  ]

Francesco Gennai via mailop replied:

I agree with you. But then people complain about the delay in
getting the email.  It seems to me that there is no option in Gmail
to specify a POP polling interval.


Can they use IMAP with IDLE ?


But the true problem is that they think that the email is an instant
messaging system :-(


Agreed.

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Francesco Gennai via mailop]

On Fri, May 6, 2022 at 8:52 PM John Levine via mailop 
wrote:

> It appears that Andrew C Aitchison via mailop 
> said:
> >On Fri, 6 May 2022, Grant Taylor via mailop wrote:
> >> On 5/6/22 9:14 AM, Luis E. Muñoz via mailop wrote:
> >>> I think the response to those issues are in part the cause for the
> loop you
> >>> cleverly explained before.
> >>
> >> Indeed.
> >>
> >> These are the very issues that caused me to be disinclined to stand my
> ARC
> >> milter back up when it fell over after an update.
> >>
> >> ARC seems to be dependent on trusting the signer.  That trust is
> inherently
> >> difficult to establish.
> >
> >Can anyone (Brandon?) tell us how Google scores the forwarder for a
> >forwarded ARC-signed message compared to the same message without ARC ?
> >
> >I would hope that the forwarder would get some credit for making
> >the details of the previous hop sufficiently reliable to score.
>
> There's a reason that spam filters don't give credit for the mere presence
> of a DKIM signature -- bad guys can sign their mail, too.  ARC is in a
> sense
> worse since a bad guy can add ARC headers with 100% valid signatures and
> 100%
> bogus information.
>
> Google has a pretty good idea of who is a forwarder, viz. the comments in
> their
> DMARC reports.  I assume that at some point they'll use ARC info in mail
> from
> senders with good reputations to make DMARC exceptions.
>
> Until then, I tell people who ask me to forward mail to Gmail that if
> they actually want to get the mail, I'll put it in a local mailbox and
> they can tell Gmail to poll it with POP.  That works quite well.
>
>
I agree with you. But then people complain about the delay in getting the
email.
It seems to me that there is no option in Gmail to specify a POP polling
interval.
But the true problem is that they think that the email is an instant
messaging system :-(

/Francesco


> R's,
> John
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[John Levine via mailop]

It appears that Andrew C Aitchison via mailop  said:
>On Fri, 6 May 2022, Grant Taylor via mailop wrote:
>> On 5/6/22 9:14 AM, Luis E. Mu�oz via mailop wrote:
>>> I think the response to those issues are in part the cause for the loop you 
>>> cleverly explained before.
>>
>> Indeed.
>>
>> These are the very issues that caused me to be disinclined to stand my ARC 
>> milter back up when it fell over after an update.
>>
>> ARC seems to be dependent on trusting the signer.  That trust is inherently 
>> difficult to establish.
>
>Can anyone (Brandon?) tell us how Google scores the forwarder for a 
>forwarded ARC-signed message compared to the same message without ARC ?
>
>I would hope that the forwarder would get some credit for making
>the details of the previous hop sufficiently reliable to score.

There's a reason that spam filters don't give credit for the mere presence
of a DKIM signature -- bad guys can sign their mail, too.  ARC is in a sense
worse since a bad guy can add ARC headers with 100% valid signatures and 100%
bogus information.

Google has a pretty good idea of who is a forwarder, viz. the comments in their
DMARC reports.  I assume that at some point they'll use ARC info in mail from
senders with good reputations to make DMARC exceptions.  

Until then, I tell people who ask me to forward mail to Gmail that if
they actually want to get the mail, I'll put it in a local mailbox and
they can tell Gmail to poll it with POP.  That works quite well.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Andrew C Aitchison via mailop]

On Fri, 6 May 2022, Grant Taylor via mailop wrote:

On 5/6/22 9:14 AM, Luis E. Muñoz via mailop wrote:
I think the response to those issues are in part the cause for the loop you 
cleverly explained before.


Indeed.

These are the very issues that caused me to be disinclined to stand my ARC 
milter back up when it fell over after an update.


ARC seems to be dependent on trusting the signer.  That trust is inherently 
difficult to establish.


Can anyone (Brandon?) tell us how Google scores the forwarder for a 
forwarded ARC-signed message compared to the same message without ARC ?


I would hope that the forwarder would get some credit for making
the details of the previous hop sufficiently reliable to score.

If so, then it is useful to ARC-sign a message when forwarding, even
when we have no data upon which to evalate incoming ARC signatures.

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Dan Mahoney via mailop]

> On May 6, 2022, at 8:14 AM, Luis E. Muñoz via mailop  
> wrote:
> 
> On 6 May 2022, at 3:48, Dan Mahoney via mailop wrote:
> 
>> If you’re already doing DKIM and SPF anyway, arc is another milter in the 
>> chain that gives you that benefit. (You want it after your DKIM and DMARC 
>> validators). You can leverage your same DKIM keys to use arc (or a different 
>> one), but it’s largely the same idea. Right now nobody is validating arc, 
>> but this is largely because nobody’s signing/sealing with it…because nobody 
>> is validating it…because nobody is signing/sealing with it….someone needs to 
>> move first.
> 
> I think there's slightly more at play. Besides "trusting" the big ones, how 
> would gushi.org know that it can trust libertad.link's ARC signatures? Or 
> posed in a different way, what prevents spammer.co to make a false 
> attestation to send spam made to look like it was sent from some innocent 
> bystander?

You’re correct here.  If you’re the i=1 arc sealer, and you apply an arc-seal 
and arc-authentication-results header that says, in effect, “yup, looked good 
to me at the time”, things will still validate, unless you drill down into the 
message and look at other things that were broken in the way forwarding is 
known to.  At that point, you can no longer validate the original DKIM 
signature (because the signed headers have been modified).

Gmail has no purported cause to trust my arc-seals on my little Vultr vm that’s 
handling my personal mail, but at the end of the day if I’m applying those 
seals, and someone else isn’t, I see my stuff as less likely to be dropped than 
the guy who isn’t.  Doing the work to set up the sealing as a “best practice” 
feels reasonable(*)

What arc DOES purport to do, is makes *forwarded* (or third-party-handled) mail 
obvious.  It changes it from “unvalidateable” to having at least one mechanism, 
which at least has a traceable path.  We hope.

I happen to run a major listserv, and I’ve turned it on.  In a system with lots 
of first-mover-disadvantages, I’ve made my move.  A 2-line question from gmail 
to bind-users now has headers for days. :)

-Dan

*(I’ve seen stuff you people wouldn’t believe. Over the years, I’ve had _adsp 
records, _domainkey policy records (i.e. domainkey with no selector), SPF 
(sometimes in addition to TXT) DNS records, hashcash signatures on my mail, 
experimenting with GPG-signing all mail, hell, there was even that one site 
that made me embed a haiku in my mail headers.  I’ve set spf -all and still got 
forged mail blowback.  This is totally whack-a-mole, hilariously in a world 
where I get more b2b spam to info@dayjob *from* the big three freemails)

> 
> How do we make this scale?
> 
> I think the response to those issues are in part the cause for the loop you 
> cleverly explained before.
> 
> Best regards
> 
> -lem
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Grant Taylor via mailop]

On 5/6/22 9:14 AM, Luis E. Muñoz via mailop wrote:
I think the response to those issues are in part the cause for the 
loop you cleverly explained before.


Indeed.

These are the very issues that caused me to be disinclined to stand my 
ARC milter back up when it fell over after an update.


ARC seems to be dependent on trusting the signer.  That trust is 
inherently difficult to establish.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Luis E . Muñoz via mailop]

On 6 May 2022, at 3:48, Dan Mahoney via mailop wrote:

> If you’re already doing DKIM and SPF anyway, arc is another milter in the 
> chain that gives you that benefit. (You want it after your DKIM and DMARC 
> validators). You can leverage your same DKIM keys to use arc (or a different 
> one), but it’s largely the same idea. Right now nobody is validating arc, but 
> this is largely because nobody’s signing/sealing with it…because nobody is 
> validating it…because nobody is signing/sealing with it….someone needs to 
> move first.

I think there's slightly more at play. Besides "trusting" the big ones, how 
would gushi.org know that it can trust libertad.link's ARC signatures? Or posed 
in a different way, what prevents spammer.co to make a false attestation to 
send spam made to look like it was sent from some innocent bystander?

How do we make this scale?

I think the response to those issues are in part the cause for the loop you 
cleverly explained before.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Dan Mahoney via mailop]

Two inline thoughts.

> On Apr 30, 2022, at 4:48 PM, Ángel via mailop  wrote:
> 
> On 2022-04-29 at 10:28 -0700, Brandon Long wrote:
>> There have been other reports on this list of Gmail requiring
>> authenticated email.
>> 
>> We don't require authenticated email... but we vastly prefer it, and
>> that preference has only increased over time.  And the dkim replay
>> attacks have meant increasing the scrutiny of messages which are dkim
>> authn but not spf authn, which of course can hurt forwarding. 
>> Forwarding is getting the short end of the stick in that
>> toss up.
>> 
>> The above rejection isn't for the dkim replay case, of course, it's
>> for no authn at all.
> 
> Yep. I completely understand it's not authenticated. The problem is,
> it's out of our reach to authenticate that third party email. It's the
> recipient who wants to receive it.
> 
> 
>> SRS style rewriting allows the forwarder to get feedback if the
>> forwarding destination address goes away, > and do bounce handling...
>> and prevent bounces from going back to the original sender, exposing
>> the destination address. There are good reasons to do the rewrite,
>> but not as likely for the average procmail user, and having a good
>> spam filter that doesn't forward is very important.

What’s the threshold for not forwarding?  If a user is at some point used to 
receiving all mails, but with SA’s default score of 5 tagged with a standard 
*SPAM header, or an X-Spam-Status header, gmail should easily recognize 
that it’s a forwarding account.

There are going to be false positives to a spam filter — and what should happen 
with those?  They get not-forwarded and put in a mailbox on the forwarding 
server that the user literally never checks?  Rejected at SMTP time, for fear 
of gmail?

And then there are false negatives, which will make a forwarding server seem 
more spammy, unless *my* spam filter and *gmails* are in perfect harmony.

To the point that when I send a new mail to a gmail user, it’s routed to the 
spam folder, because “Lots of mail from prime.gushi.org  is 
spam”.  Seriously.  With nothing showing in postmaster.

There’s a couple of very standard headers that the common open source filters 
add (spamassassin, crm, dspam). Gmail could trivially recognize upstream spam 
filters (per sending-host) and act on them.   They choose not to.

[…]

>> An even better one would be ARC, it would be pretty easy to specify
>> one or more ARC ADMDs as trusted forwarders on a per-user basis (or
>> for workspace admins).
>> 
>> This suffered from a chicken/egg problem on top of the general 
>> "hard for most users to understand", and the general small usage of
>> regular forwarding...
>> the better option was to generalize the benefits of ARC to all users
>> automatically... but that work is still in progress.
> 
> ARC would indeed be a more complete solution. However, I suspect this
> may be one of those cases where perfect is the enemy of the good.
> Specially since this doesn't solve the issue of which ADMDs to trust.

If you’re already doing DKIM and SPF anyway, arc is another milter in the chain 
that gives you that benefit.  (You want it after your DKIM and DMARC 
validators).  You can leverage your same DKIM keys to use arc (or a different 
one), but it’s largely the same idea.  Right now nobody is validating arc, but 
this is largely because nobody’s signing/sealing with it…because nobody is 
validating it…because nobody is signing/sealing with it….someone needs to move 
first.

Unlike DMARC with p=reject or spf with -all, there’s no harm in adding an ARC 
signature.  There’s no DNS record that you put in ARC (other than for the 
domainkey) that says “if arc fails do this” and the ARC rfc does not extend 
DMARC to change its action.

I spent arguably an hour tweaking it and turning it on both on $dayjob’s mail 
entry points and on the sending-end of our mailman 2.x server.  If more people 
start looking at that info, we’re ready.

Right now, one of the best things gmail could do is when you say “view 
original” for a message, in addition to showing the SPF/DMARC/DKIM status at 
the top, show the arc status too, at the top of the page.  Make people more 
aware of ARC.  Gmail pushed ARC as a solution, and yet it’s not advertised to 
users as something that they should see passing.

That said, if you have a gmail account for testing, you can see the arc=pass or 
arc=fail results of mails you forward, down there in the headers.


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Byung-Hee HWANG via mailop]

Byung-Hee HWANG via mailop  writes:

> ... snip ...
> Most emails arrive at INBOX (soyeo...@gmail.com), exactly.

There is only 0.1%'s email to spam folder.
99.9%'s emails settle down INBOX without error.

Another screenshot: (2022-05-03)


Sincerely, Linux fan Byung-Hee

-- 
^고맙습니다 _布德天下_ 감사합니다_^))//
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Ángel via mailop]

On 2022-04-29 at 10:28 -0700, Brandon Long wrote:
> There have been other reports on this list of Gmail requiring
> authenticated email.
> 
> We don't require authenticated email... but we vastly prefer it, and
> that preference has only increased over time.  And the dkim replay
> attacks have meant increasing the scrutiny of messages which are dkim
> authn but not spf authn, which of course can hurt forwarding. 
> Forwarding is getting the short end of the stick in that
> toss up.
> 
> The above rejection isn't for the dkim replay case, of course, it's
> for no authn at all.

Yep. I completely understand it's not authenticated. The problem is,
it's out of our reach to authenticate that third party email. It's the
recipient who wants to receive it.


> SRS style rewriting allows the forwarder to get feedback if the
> forwarding destination address goes away, > and do bounce handling...
> and prevent bounces from going back to the original sender, exposing
> the destination address. There are good reasons to do the rewrite,
> but not as likely for the average procmail user, and having a good
> spam filter that doesn't forward is very important.

We do some hoops here, in that we provide the original envelope to the
forwarded mail server, but it if refuses to accept it, we send the
bounce to the forwarding account, not to the original sender. :)

This not only avoids leaking the information about forwarded accounts,
but also confusing the senders.


>> Gmail guidelines explicitly ask not to rewrite the envelope
sender
> 
> Yes... and gmail forwarding does ;).  Mailing lists do as well.  

Should we then do as-it-does rather than as-it-says? :)
If gmail has changed its stance, messages could be forwarded with a
different envelope sender, but I suspect it wouldn't be happy either,
as it would then show an envelope suspiciously unrelated to the
content.


> > > There's no great solution to this problem. (...) ARC is the
> > > theoretical solution to this, where it can forward auth
> > > information, but how to handle the forwarded auth information is
> > > still a work in progress.
> > 
> > There is a really simple solution for these Gmail customers getting
> > their forwarded mail rejected. But it lies on Gmail side.
> > 
> > Gmail already knows that the account of bl...@gmail.com is linked to
> > the mailbox bl...@example.com, since bl...@gmail.com is configured to
> > allow sending as bl...@example.com. It should thus detect that the
> > email received from mta.example.com with a "To: bl...@example.com" is a 
> > forward requested by the user, and not reject it at the gateway when it 
> > fails SPF.
> 
> Heuristics like this have been used in the past, but spammers often
> figured them out.

I was initially going to suggest that it was received by any server
passing SPF for the configured external account, then noticed that
perhaps that didn't work so well with those large SPF records, and
mentioned just that To: (just an example, it could e.g. be detected
through headers as well) but it really should have mentioned "from the
right server".


> > Or, in order to have a stronger command from the user and avoid
> > forward-guessing, at the cost of a new configuration setting, let the
> > user configure a list of IP addresses from which they are forwarding
> > mail to their account.
> > Then Gmail could clearly recognise what is actually happening: that the
> > connecting IP adddress belongs to a border MTA of this user, and then
> > walk Received: headers to fetch the actual IP address that delivered it
> > to bl...@example.com, which is the one that should be taken into account
> > for a proper evaluation.
> 
> Yes, this is how workspace handles this, you would just set the list of IPs 
> as 
> the inbound gateway.  Even then, there are cases like outlook.com/O365, where
> the list of possible IPs is very high... or forwarding gmail to gmail, for 
> that matter..

Allowing users to set this as well would allow users to fix this issue
where gmail would otherwise reject the mail they want forwarded. At
least for those coming from a small set of ip addresses (although large
ones probably use a forwarding pool).


> An even better one would be ARC, it would be pretty easy to specify
> one or more ARC ADMDs as trusted forwarders on a per-user basis (or
> for workspace admins).
> 
> This suffered from a chicken/egg problem on top of the general 
> "hard for most users to understand", and the general small usage of
> regular forwarding...
> the better option was to generalize the benefits of ARC to all users
> automatically... but that work is still in progress.

ARC would indeed be a more complete solution. However, I suspect this
may be one of those cases where perfect is the enemy of the good.
Specially since this doesn't solve the issue of which ADMDs to trust.

I agree about the general problem of "hard for most users to
understand" how to fill out ip addresses or ADMD identifiers, but given
the issue that 

Re: [mailop] forwarding to gmail - problem

[Brandon Long via mailop]

On Thu, Apr 28, 2022 at 5:32 PM Mark Milhollan via mailop 
wrote:

> On Thu, 28 Apr 2022, Scott Mutter wrote:
>
> >configure your Gmail account to POP mail from that POP3 mailbox.  This
> >side steps the issues of SPF failing,
>
> It does not.  As recently discussed, Gmail plays a game of trying to
> guess whether SPF should have failed on a previous hop, rather than just
> the connected peer.  If they see a hop that accepted from a source that
> SPF does not authorize and if not an RFC1918 address or an IPv6 LLA the
> result is failure -- they don't accept the common indication of SMTP
> AUTH, e.g., ESMTPSA, likely to catch when leaked credentials are
> (ab)used, but it also "catches" roaming users.
>
>  Authentication-Results: mx.google.com; ... spf=fail ...
>  Received: from passes-spf ... by mx.google.com ...
>  Received: from not-within-spf-its-a-forking-cafe ... by passes-spf
> with ESMTPSA ...
>

This is only done for SMTP for Workspace messages coming through a
specified inbound gateway, where we
know that the connecting smtp server is not the IP to check.

And ESMTPSA is not any sort of validation.


> This is also done for messages fetched via POP with the result that some
> are given the spam label while some are skipped.
>
>spam labeled (details in Gmail web MUA indicate SPF failure):
>
>  Delivered-To: m...@some.corp
>  Received: from not-within-spf-its-a-forking-cafe ... by
> mail.some.corp with ESMTPSA ...
>  From: 
>  To: 
>
>not saved, which seems the POP fetch equivalent of an SMTP reject:
>
>  Delivered-To: m...@some.corp
>  Received: from their-mta-wthin-spf ... by mail.some.corp with ESMTPS
> ...
>  Received: from not-within-spf-its-a-forking-cafe ... by
> their-mta-within-spf with ESMTPSA ...
>  From: 
>  To: 
>

Not sure what you're talking about, we don't drop messages that we POP
fetch.


>spam labeled -- more verbose:
>
> Original to be fetched:
>
>  Received: from BY5PR22MB1826.namprd22.prod.outlook.com
> (2603:10b6:a03:239::8) by BY5PR22MB2034.namprd22.prod.outlook.com with
> HTTPS; Wed, 20 Apr 2022 16:49:43 +
>  Authentication-Results: dkim=none (message not signed)
> header.d=none;dmarc=none action=none header.from=some.corp;
>  Received: from BY5PR22MB2034.namprd22.prod.outlook.com
> (2603:10b6:a03:230::13) by BY5PR22MB1826.namprd22.prod.outlook.com
> (2603:10b6:a03:239::8) with Microsoft SMTP Server (version=TLS1_2,
> cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5164.20; Wed, 20 Apr
> 2022 16:49:41 +
>  Received: from BY5PR22MB2034.namprd22.prod.outlook.com
> ([fe80::149a:1ce0:44a0:a16%6]) by BY5PR22MB2034.namprd22.prod.outlook.com
> ([fe80::149a:1ce0:44a0:a16%6]) with mapi id 15.20.5186.014; Wed, 20 Apr
> 2022 16:49:41 +
>  From: 
>  To: 
>
> As seen in Gmail web MUA (which indicates SPF failure):
>
>  Delivered-To: m...@gmail.com
>  Received: by 2002:a5d:860f:0:0:0:0:0 with SMTP id f15csp3628616iol;
> Wed, 20 Apr 2022 10:26:27 -0700 (PDT)
>  X-Google-Smtp-Source: [elided]
>  X-Received: by 2002:a05:620a:404e:b0:69e:a5db:22cb with SMTP id
> i14-20020a05620a404e00b0069ea5db22cbmr8513102qko.735.1650475587274; Wed, 20
> Apr 2022 10:26:27 -0700 (PDT)
>  Authentication-Results: mx.google.com; spf=softfail (google.com:
> domain of transitioning m...@some.corp does not designate
> 2603:10b6:a03:239::8 as permitted sender) smtp.mailfrom=m...@some.corp
>  Received-SPF: softfail (google.com: domain of transitioning
> m...@some.corp does not designate 2603:10b6:a03:239::8 as permitted sender)
> client-ip=2603:10b6:a03:239::8;
>  Received: by 2002:ac8:56fa:0:b0:2eb:a8b9:b77 with POP3 id
> 26-20020ac856fa00b002eba8b90b77mf678417qtu.2; Wed, 20 Apr 2022 10:26:27
> -0700 (PDT)
>  X-Gmail-Fetch-Info: m...@some.corp 3 outlook.office365.com 995
> m...@some.corp
>  Received: from BY5PR22MB1826.namprd22.prod.outlook.com
> (2603:10b6:a03:239::8) by BY5PR22MB2034.namprd22.prod.outlook.com with
> HTTPS; Wed, 20 Apr 2022 16:49:43 +
>  Authentication-Results: dkim=none (message not signed)
> header.d=none;dmarc=none action=none header.from=some.corp;
>  Received: from BY5PR22MB2034.namprd22.prod.outlook.com
> (2603:10b6:a03:230::13) by BY5PR22MB1826.namprd22.prod.outlook.com
> (2603:10b6:a03:239::8) with Microsoft SMTP Server (version=TLS1_2,
> cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5164.20; Wed, 20 Apr
> 2022 16:49:41 +
>  Received: from BY5PR22MB2034.namprd22.prod.outlook.com
> ([fe80::149a:1ce0:44a0:a16]) by BY5PR22MB2034.namprd22.prod.outlook.com
> ([fe80::149a:1ce0:44a0:a16%6]) with mapi id 15.20.5186.014; Wed, 20 Apr
> 2022 16:49:41 +
>  From: 
>  To: 
>

Hmm, that is unfortunate if it doesn't work with O365.  Also, wow, that a
company allows their employees to pop their email out of their corporate
account to an account the company doesn't control.


> Good thing I don't do the same silliness 

Re: [mailop] forwarding to gmail - problem

[Robert L Mathews via mailop]

On 4/28/22 8:53 PM, Ángel via mailop wrote:

Seeing it here as well. Something has recently changed in gmail again,
just like last December.


Yes, this problem has vastly increased. We're seeing complaints due to 
this several times a week now, whereas before it was maybe once a month.


Brandon Long mentioned that he didn't think this was likely to be 
particularly caused by SPF "-all", but more than 95% of the forwarded 
messages Gmail is rejecting with this error have that characteristic, 
based on our logs.


So if somebody sends a message from an SPF "-all" domain name, and 
there's either no DKIM or the DKIM is broken, and there's no DMARC 
policy, and it gets automatically forwarded to Gmail -- there's a very 
high chance Gmail will reject it with this error, even for messages that 
are fairly "obviously" not spam or bulk.


I've long subscribed to the idea that if Gmail says "avoid changing the 
envelope sender when forwarding email to Gmail", then don't do it 
(https://support.google.com/mail/answer/175365), but it's not tenable 
with this rate of rejections. SRS-style envelope rewriting, at least for 
messages that use SPF "-all" with no DKIM, seems necessary.


(It's difficult to keep explaining to paying customers that people who 
send them mail with SPF "-all" and no DKIM are doing it wrong, and 
hearing "but it works if they send directly to my Gmail address".)


--
Robert L Mathews
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Slavko via mailop]

Hi,

Dňa Fri, 29 Apr 2022 08:49:40 -0500 Scott Mutter via mailop
 napísal:

> If you survey 100
> people and 80 people would prefer SPF measures over allowing automatic
> email forwarding... sure it sucks if you're one of the 20 that voted
> the other way... but that's how majority works.

...and when you will carefully select those 100 people, they can all
prefer SPF, even when they do not know what SPF is nor how it works (or
what it breaks), enough for their opinion is to "know", that phishing is
bad. For that majority is important only one thing -- to have something,
which moves responsibility to someone other...

As i know, majority do not know how email works at all. The same
majority is able to click on any link or respond to any email, or run
any executable (especially that named with "nude"), etc, etc. Then how
useful is their opinion in that?

regards

-- 
Slavko
https://www.slavino.sk


pgpEZ0muwImzJ.pgp
Description: Digitálny podpis OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Scott Mutter via mailop]

On Fri, Apr 29, 2022 at 4:47 AM Jaroslaw Rafa via mailop
 wrote:
> I would say the opposite. Mail forwarding was there before SPF, so anybody
> who designed SPF should have taken that into account. They didn't. So SPF is
> the "bad guy" here among these two. SPF is the one that breaks forwarding,
> not forwarding the one that breaks SPF.

We'll have to agree to disagree on this one.

My opinion is that things change over time.  Innovations come about
that improve a certain situation (i.e. email) and sometimes that
encompasses certain sacrifices.

I feel like automatic email forwarders were more of a 90s technology.
People wanted to be able to check all of their mail in their Hotmail
account or in Eudora or Pegasus Mail.  Over time,
spam/phishing/spoofing (SPF is more of an anti-spoofing measure)
became more and more problematic.  Everywhere you looked people were
complaining about the spam/phishing/spoofed email messages they were
receiving.

Developers of SPF came up with the idea of authenticating email based
on the sending IP and DNS definition, BUT... this is going to break
automatic email forwarding.  So service providers that adopted SPF as
an anti-spam/phishing/spoofing measure had to decide, which was more
important:  Continuing to allow automatic forwarding or adopt a
measure that could lessen the spam/phishing/spoofed messages that
their user base receives.

I feel like automatic forwarders are used a lot less today than they
were in the 90s or 00s.  They're still used, but not as much.  Maybe
I'm wrong in that regard.  Maybe the mass of Internet and email users
need to start protesting against SPF and in favor of automatic email
forwarding because automatic email forwarding is preferred over
anti-spam/anti-phishing/anti-spoofing SPF measures.  If you survey 100
people and 80 people would prefer SPF measures over allowing automatic
email forwarding... sure it sucks if you're one of the 20 that voted
the other way... but that's how majority works.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Andrew C Aitchison via mailop]

On Fri, 29 Apr 2022, Jaroslaw Rafa via mailop wrote:


Dnia 29.04.2022 o godz. 12:08:13 Andrew C Aitchison via mailop pisze:

You wouldn't want to give anybody - be it Google or anybody else - login
credentials to your email account, would you?


In many organisations it is worse than that.
With single-sign-on it gives Google etc. access to the user's
desktop, files and compute resources.


Hm... if you use Google for single sign-on, it doesn't give Google access to
user's resources. You are only asking Google for authentication (instead of
for example your local AD domain controller), but this itself doesn't provide
Google a way to access your local resources (unless you separately configure
such a way). It works the opposite way - with Google SSO, your local apps
are able to access data kept in your Google account, but not the other way.

Of course another thing is when you keep everything "in the cloud" - as many
organizations do - and user's files are stored on Google Drive and not
locally. Then of course Google has access to them regardless whether you
use SSO or not.


I meant that if the organisation uses SSO, or at least the same password, 
for email and other institutional access, then letting a third party
use pop to collect your mail into their user-agent, you are giving them 
the keys to everything in the organisation (that the user may access).


--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Jaroslaw Rafa via mailop]

Dnia 29.04.2022 o godz. 12:08:13 Andrew C Aitchison via mailop pisze:
> >You wouldn't want to give anybody - be it Google or anybody else - login
> >credentials to your email account, would you?
> 
> In many organisations it is worse than that.
> With single-sign-on it gives Google etc. access to the user's
> desktop, files and compute resources.

Hm... if you use Google for single sign-on, it doesn't give Google access to
user's resources. You are only asking Google for authentication (instead of
for example your local AD domain controller), but this itself doesn't provide
Google a way to access your local resources (unless you separately configure
such a way). It works the opposite way - with Google SSO, your local apps
are able to access data kept in your Google account, but not the other way.

Of course another thing is when you keep everything "in the cloud" - as many
organizations do - and user's files are stored on Google Drive and not
locally. Then of course Google has access to them regardless whether you
use SSO 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] forwarding to gmail - problem

[Andrew C Aitchison via mailop]

On Fri, 29 Apr 2022, Jaroslaw Rafa via mailop wrote:


Dnia 28.04.2022 o godz. 14:14:02 Dan Mahoney via mailop pisze:

I've told any of my users to not forward to gmail instead, but rather to
just use their pop-fetcher.


You wouldn't want to give anybody - be it Google or anybody else - login
credentials to your email account, would you?


In many organisations it is worse than that.
With single-sign-on it gives Google etc. access to the user's
desktop, files and compute resources.

As the sysadmin I would be trying to figure out how to give "Google"
a seperate authentication, only valid for popping mail, without
adding an extra password and confusing everyone.
Not to mention the risks of letting "Google" see possibly
confidential emails.

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Jaroslaw Rafa via mailop]

Dnia 28.04.2022 o godz. 14:14:02 Dan Mahoney via mailop pisze:
> I've told any of my users to not forward to gmail instead, but rather to
> just use their pop-fetcher.

You wouldn't want to give anybody - be it Google or anybody else - login
credentials to your email account, would 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] forwarding to gmail - problem

[Jaroslaw Rafa via mailop]

Dnia 28.04.2022 o godz. 14:58:09 Scott Mutter via mailop pisze:
> Automatic email forwarders are generally a bad idea, at least in my
> humble opinion.
> 
> They're always going to fail SPF unless you rewrite the
> sender-envelope, which I also don't think is a good idea.

I would say the opposite. Mail forwarding was there before SPF, so anybody
who designed SPF should have taken that into account. They didn't. So SPF is
the "bad guy" here among these two. SPF is the one that breaks forwarding,
not forwarding the one that breaks 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] forwarding to gmail - problem

[Byung-Hee HWANG via mailop]

Dear Geoff,

Geoff Mulligan via mailop  writes:

> (... thanks ...)
> If so, how is someone supposed to forward messages to gmail???

This is mine:

[0] https://gitlab.com/soyeomul/Gnus/-/raw/karma/DKIM/ss/87ilrewnoo@gnus.org
[1] 
https://gitlab.com/soyeomul/Gnus/-/blob/karma/DKIM/ss/Screenshot%202022-04-12%208.32.45%20PM.png
[2] 
https://gitlab.com/soyeomul/Gnus/-/blob/karma/DKIM/ss/Screenshot%202022-04-12%208.33.38%20PM.png

Forwarding to Gmail is good with me.

Most emails arrive at INBOX (soyeo...@gmail.com), exactly.

Sincerely, Linux fan Byung-Hee

-- 
^고맙습니다 _布德天下_ 감사합니다_^))//
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Ángel via mailop]

On 2022-04-28 at 12:45 -0600, Geoff Mulligan via mailop wrote:
> I have a user on one of my servers that uses procmail to forward
> messages to their gmail account.
> 
> Every once in a while messages sent to them are "bounced" to the
> sender with the error fro gmail:
> 
> 550-5.7.26 This message does not have authentication information or
> fails to 550-5.7.26 pass
> authentication checks. To best protect our users from spam, the
> 550-5.7.26
> message has been blocked.
> 
> How can I diagnose this???

Seeing it here as well. Something has recently changed in gmail again,
just like last December.
I'm quite sure Robert L Mathews discovery of the line-wrapping issue
was caused by this as well.

(And yes, this is happening to legit messages, hand-typed for them, and
that when reviewed manually show no trace of spamminess at all)

If your senders use DKIM, those will generally pass. However, 

a) some senders do not implement DKIM, so their mails cannot benefit
from it when forwarded
b) some mails will have invalid DKIM signatures
(in which case you will have a hard time figuring out if that was
broken to begin with or if some uncommon feature on this mail moved
your MTA to "fix" it breaking the signature)


On 2022-04-28 at 12:02 -0700, Brandon Long noted:
> Are they using the suggestions on 
> https://support.google.com/mail/answer/175365 for procmail
> forwarding?
> 
> There's a double edge sword with SPF auth for forwarding.. if you re-
> write the envelope sender to the forwarding address and forward spam,
> the forwarding domain can accumulate poor reputation.  If you don't
> rewrite the envelope sender, then the messages will no longer be SPF
> authed, and that may cause spam detection issues.

Gmail guidelines explicitly ask not to rewrite the envelope sender


> There's no great solution to this problem. (...) ARC is the
> theoretical solution to this, where it can forward auth
> information, but how to handle the forwarded auth information is
> still a work in progress.

There is a really simple solution for these Gmail customers getting
their forwarded mail rejected. But it lies on Gmail side.

Gmail already knows that the account of bl...@gmail.com is linked to
the mailbox bl...@example.com, since bl...@gmail.com is configured to
allow sending as bl...@example.com. It should thus detect that the
email received from mta.example.com with a "To: bl...@example.com" is a
forward requested by the user, and not reject it at the gateway when it
fails SPF.

Or, in order to have a stronger command from the user and avoid
forward-guessing, at the cost of a new configuration setting, let the
user configure a list of IP addresses from which they are forwarding
mail to their account.
Then Gmail could clearly recognise what is actually happening: that the
connecting IP adddress belongs to a border MTA of this user, and then
walk Received: headers to fetch the actual IP address that delivered it to 
bl...@example.com, which is the one that should be taken into account
for a proper evaluation.


This is something that should be implemented by everyone. If you are
forwarding messages to somewhere else (and expecting to receive them!),
you should configure the *receiving* side to recognise it as such.
Sadly, no end-user provider seem to include this setting, so it ends up
being only an option for those running their own systems. ☹

Even on corporate systems, where they have a filtering mail server at
the border, and their postmasters should know better, it's not that
uncommon to find out it is misconfigured and the internal MTA is
treating every mail as failing SPF.

Regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Scott Mutter via mailop]

On Thu, Apr 28, 2022 at 7:20 PM Mark Milhollan via mailop
 wrote:
> It does not.  As recently discussed, Gmail plays a game of trying to
> guess whether SPF should have failed on a previous hop, rather than just
> the connected peer.

I don't really see that much of an issue with this in popping mail
into Gmail.  But I agree that it's something that really shouldn't be
done.

I was speaking more in terms of concept than Gmail's actual
implementation of collecting POP3 mails.

I'd argue that all spam scanning should be done on the server that is
initially receiving the mail (i.e the server Gmail is popping mail
from).  And then Gmail should just dump all mails from POP'd accounts
into the Inbox.  If Gmail can distinguish between content filtering
and authentication filtering, then they might apply content filtering
to these POP'd messages.  Although, I'd like to see an option in Gmail
when setting up to retrieve POP3 messages that there would be an
option to "Never flag these messages as spam" - thereby avoiding any
Gmail-based content (or authentication) filtering.  But yea, there's
no need to authenticate SPF or DKIM in POP'd messages - that's the job
that the receiving server (since presumably it obtained the messages
through an SMTP transaction) should be doing.

But just the concept:  The email service you are using as your MUA, if
it can collect mail from a POP/IMAP service - then it can't really
knock or blacklist that server since the MUA user has made a
conscientious decision to retrieve those mails.  It's a pull request
by the MUA.  Whereas forwarding or just sending mail in general to a
specific email address is a push to the MUA.  The MUA doesn't
explicitly acknowledge that they want to receive those messages, they
just get pushed on to them.

The service that is having these messages PUSHed onto them, sure they
can complain about the messages being spam and block the PUSHer if
they so deem.  And with automatic forwarding to Gmail, the server
doing the forwarding ... is PUSHing those messages to Gmail.  How is
Gmail supposed to know that the server is just PUSHing a message that
was PUSHed to them?  I suppose you could argue that Gmail can read the
headers and determine that the message was PUSHed onto the server that
is currently PUSHing it to them, but then what?  If they ignore it,
they're going to be receiving a lot of spam.  And they have no
jurisdiction to stop the message from being PUSHed to the original
collecting server.

But a PULL is different.  If the end user MUA doesn't want to receive
these messages... then stop PULLing them.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Mark Milhollan via mailop]

On Thu, 28 Apr 2022, Scott Mutter wrote:


configure your Gmail account to POP mail from that POP3 mailbox.  This
side steps the issues of SPF failing,


It does not.  As recently discussed, Gmail plays a game of trying to 
guess whether SPF should have failed on a previous hop, rather than just 
the connected peer.  If they see a hop that accepted from a source that 
SPF does not authorize and if not an RFC1918 address or an IPv6 LLA the 
result is failure -- they don't accept the common indication of SMTP 
AUTH, e.g., ESMTPSA, likely to catch when leaked credentials are 
(ab)used, but it also "catches" roaming users.


Authentication-Results: mx.google.com; ... spf=fail ...
Received: from passes-spf ... by mx.google.com ...
Received: from not-within-spf-its-a-forking-cafe ... by passes-spf with 
ESMTPSA ...


This is also done for messages fetched via POP with the result that some 
are given the spam label while some are skipped.


  spam labeled (details in Gmail web MUA indicate SPF failure):

Delivered-To: m...@some.corp
Received: from not-within-spf-its-a-forking-cafe ... by mail.some.corp with 
ESMTPSA ...
From: 
To: 

  not saved, which seems the POP fetch equivalent of an SMTP reject:

Delivered-To: m...@some.corp
Received: from their-mta-wthin-spf ... by mail.some.corp with ESMTPS ...
Received: from not-within-spf-its-a-forking-cafe ... by 
their-mta-within-spf with ESMTPSA ...
From: 
To: 

  spam labeled -- more verbose:

   Original to be fetched:

Received: from BY5PR22MB1826.namprd22.prod.outlook.com 
(2603:10b6:a03:239::8) by BY5PR22MB2034.namprd22.prod.outlook.com with HTTPS; 
Wed, 20 Apr 2022 16:49:43 +
Authentication-Results: dkim=none (message not signed) 
header.d=none;dmarc=none action=none header.from=some.corp;
Received: from BY5PR22MB2034.namprd22.prod.outlook.com 
(2603:10b6:a03:230::13) by BY5PR22MB1826.namprd22.prod.outlook.com 
(2603:10b6:a03:239::8) with Microsoft SMTP Server (version=TLS1_2, 
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5164.20; Wed, 20 Apr 
2022 16:49:41 +
Received: from BY5PR22MB2034.namprd22.prod.outlook.com 
([fe80::149a:1ce0:44a0:a16%6]) by BY5PR22MB2034.namprd22.prod.outlook.com 
([fe80::149a:1ce0:44a0:a16%6]) with mapi id 15.20.5186.014; Wed, 20 Apr 2022 
16:49:41 +
From: 
To: 

   As seen in Gmail web MUA (which indicates SPF failure):

Delivered-To: m...@gmail.com
Received: by 2002:a5d:860f:0:0:0:0:0 with SMTP id f15csp3628616iol; Wed, 20 
Apr 2022 10:26:27 -0700 (PDT)
X-Google-Smtp-Source: [elided]
X-Received: by 2002:a05:620a:404e:b0:69e:a5db:22cb with SMTP id 
i14-20020a05620a404e00b0069ea5db22cbmr8513102qko.735.1650475587274; Wed, 20 Apr 
2022 10:26:27 -0700 (PDT)
Authentication-Results: mx.google.com; spf=softfail (google.com: domain of 
transitioning m...@some.corp does not designate 2603:10b6:a03:239::8 as 
permitted sender) smtp.mailfrom=m...@some.corp
Received-SPF: softfail (google.com: domain of transitioning m...@some.corp 
does not designate 2603:10b6:a03:239::8 as permitted sender) 
client-ip=2603:10b6:a03:239::8;
Received: by 2002:ac8:56fa:0:b0:2eb:a8b9:b77 with POP3 id 
26-20020ac856fa00b002eba8b90b77mf678417qtu.2; Wed, 20 Apr 2022 10:26:27 
-0700 (PDT)
X-Gmail-Fetch-Info: m...@some.corp 3 outlook.office365.com 995 
m...@some.corp
Received: from BY5PR22MB1826.namprd22.prod.outlook.com 
(2603:10b6:a03:239::8) by BY5PR22MB2034.namprd22.prod.outlook.com with HTTPS; 
Wed, 20 Apr 2022 16:49:43 +
Authentication-Results: dkim=none (message not signed) 
header.d=none;dmarc=none action=none header.from=some.corp;
Received: from BY5PR22MB2034.namprd22.prod.outlook.com 
(2603:10b6:a03:230::13) by BY5PR22MB1826.namprd22.prod.outlook.com 
(2603:10b6:a03:239::8) with Microsoft SMTP Server (version=TLS1_2, 
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5164.20; Wed, 20 Apr 
2022 16:49:41 +
Received: from BY5PR22MB2034.namprd22.prod.outlook.com 
([fe80::149a:1ce0:44a0:a16]) by BY5PR22MB2034.namprd22.prod.outlook.com 
([fe80::149a:1ce0:44a0:a16%6]) with mapi id 15.20.5186.014; Wed, 20 Apr 2022 
16:49:41 +
From: 
To: 


Good thing I don't do the same silliness else a daily email I get from 
them would be rejected at end of DATA or dumped in my spam folder since 
"domain of u...@gmail.com does not designate 24.199.x.x as permitted 
sender" ...


Received: from mail...google.com by me with ESMTPS ...
Received: by mail...google.com with SMTP ...
Received: from smtpclient ([24.199.x.x]) by smtp.gmail.com with ESMTPSA ...


/mark
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Dan Mahoney via mailop]

I've told any of my users to not forward to gmail instead, but rather to just 
use their pop-fetcher.

Two problems I had there.

1) Not a goog issue, but Microsoft effectively discontinued this feature for 
hotmail, for some reason, so it's not universal advice.

2) Gmail started hitting MTU/ipv6 issues with my system, and the error they 
presented to the user was useless (and in fact, cut off mid-sentence in the 
Google UI).  My solution was to create a v4-only hostname and v6-only hostname, 
which required reworking all my certs.

The bigger problem here is that there's no place a regular gmail or hotmail or 
($freemail) user can reach out to for help.

-Dan

> On Apr 28, 2022, at 12:58 PM, Scott Mutter via mailop  
> wrote:
> 
> Automatic email forwarders are generally a bad idea, at least in my
> humble opinion.
> 
> They're always going to fail SPF unless you rewrite the
> sender-envelope, which I also don't think is a good idea.
> 
> Ultimately, the argument generally comes down to "well, these used to
> work" and that's part of the problem.  People expect everything to
> work just like it used to - but they also want to gain all of the
> benefits of newer anti-spam/anti-phishing components.  That's just
> simply a false narrative.
> 
> I'm not sure what specific mail system the user is using, but my
> suggestion would be to set up the address to collect into a local POP3
> mailbox on the same server that's doing the forwarding.  Then
> configure your Gmail account to POP mail from that POP3 mailbox.  This
> side steps the issues of SPF failing, while also allowing the user to
> remain exclusive to their Gmail account.
> 
> On Thu, Apr 28, 2022 at 2:02 PM Brandon Long via mailop
>  wrote:
>> 
>> Are they using the suggestions on 
>> https://support.google.com/mail/answer/175365 for procmail forwarding?
>> 
>> There's a double edge sword with SPF auth for forwarding.. if you re-write 
>> the envelope sender to the forwarding address and forward spam, the 
>> forwarding domain can accumulate poor reputation.  If you don't rewrite the 
>> envelope sender, then the messages will no longer be SPF authed, and that 
>> may cause spam detection issues.
>> 
>> There's no great solution to this problem.  Theoretically, one could try to 
>> walk the line and rewrite the sender for some messages where you think it's 
>> not spam but having no auth causes issues ... though it won't work for say 
>> domains with DMARC since there has to be alignment.
>> 
>> ARC is the theoretical solution to this, where it can forward auth 
>> information, but how to handle the forwarded auth information is still a 
>> work in progress.
>> 
>> In a long ago thread, we discussed the benefits of doing both forwarding and 
>> pop fetching, to handle the edge cases.
>> 
>> Brandon
>> 
>> On Thu, Apr 28, 2022 at 11:49 AM Geoff Mulligan via mailop 
>>  wrote:
>>> 
>>> I have a user on one of my servers that uses procmail to forward messages 
>>> to their gmail account.
>>> 
>>> Every once in a while messages sent to them are "bounced" to the sender 
>>> with the error fro gmail:
>>> 
>>> 550-5.7.26 This message does not have authentication information or fails 
>>> to 550-5.7.26 pass
>>>authentication checks. To best protect our users from spam, the 
>>> 550-5.7.26
>>>message has been blocked.
>>> 
>>> How can I diagnose this???
>>> 
>>> Is it that the message sender's domain has a DMARC setting or some such 
>>> that gmail is using and that my server (which is just forwarding the 
>>> message) is failing?
>>> 
>>> If so, how is someone supposed to forward messages to gmail???
>>> 
>>> Thanks,
>>> Geoff
>>> 
>>> ___
>>> mailop mailing list
>>> mailop@mailop.org
>>> https://list.mailop.org/listinfo/mailop
>> 
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://list.mailop.org/listinfo/mailop
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Scott Mutter via mailop]

Automatic email forwarders are generally a bad idea, at least in my
humble opinion.

They're always going to fail SPF unless you rewrite the
sender-envelope, which I also don't think is a good idea.

Ultimately, the argument generally comes down to "well, these used to
work" and that's part of the problem.  People expect everything to
work just like it used to - but they also want to gain all of the
benefits of newer anti-spam/anti-phishing components.  That's just
simply a false narrative.

I'm not sure what specific mail system the user is using, but my
suggestion would be to set up the address to collect into a local POP3
mailbox on the same server that's doing the forwarding.  Then
configure your Gmail account to POP mail from that POP3 mailbox.  This
side steps the issues of SPF failing, while also allowing the user to
remain exclusive to their Gmail account.

On Thu, Apr 28, 2022 at 2:02 PM Brandon Long via mailop
 wrote:
>
> Are they using the suggestions on 
> https://support.google.com/mail/answer/175365 for procmail forwarding?
>
> There's a double edge sword with SPF auth for forwarding.. if you re-write 
> the envelope sender to the forwarding address and forward spam, the 
> forwarding domain can accumulate poor reputation.  If you don't rewrite the 
> envelope sender, then the messages will no longer be SPF authed, and that may 
> cause spam detection issues.
>
> There's no great solution to this problem.  Theoretically, one could try to 
> walk the line and rewrite the sender for some messages where you think it's 
> not spam but having no auth causes issues ... though it won't work for say 
> domains with DMARC since there has to be alignment.
>
> ARC is the theoretical solution to this, where it can forward auth 
> information, but how to handle the forwarded auth information is still a work 
> in progress.
>
> In a long ago thread, we discussed the benefits of doing both forwarding and 
> pop fetching, to handle the edge cases.
>
> Brandon
>
> On Thu, Apr 28, 2022 at 11:49 AM Geoff Mulligan via mailop 
>  wrote:
>>
>> I have a user on one of my servers that uses procmail to forward messages to 
>> their gmail account.
>>
>> Every once in a while messages sent to them are "bounced" to the sender with 
>> the error fro gmail:
>>
>> 550-5.7.26 This message does not have authentication information or fails to 
>> 550-5.7.26 pass
>> authentication checks. To best protect our users from spam, the 
>> 550-5.7.26
>> message has been blocked.
>>
>> How can I diagnose this???
>>
>> Is it that the message sender's domain has a DMARC setting or some such that 
>> gmail is using and that my server (which is just forwarding the message) is 
>> failing?
>>
>> If so, how is someone supposed to forward messages to gmail???
>>
>> Thanks,
>>  Geoff
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://list.mailop.org/listinfo/mailop
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Brandon Long via mailop]

Are they using the suggestions on
https://support.google.com/mail/answer/175365 for procmail forwarding?

There's a double edge sword with SPF auth for forwarding.. if you re-write
the envelope sender to the forwarding address and forward spam, the
forwarding domain can accumulate poor reputation.  If you don't rewrite the
envelope sender, then the messages will no longer be SPF authed, and that
may cause spam detection issues.

There's no great solution to this problem.  Theoretically, one could try to
walk the line and rewrite the sender for some messages where you think it's
not spam but having no auth causes issues ... though it won't work for say
domains with DMARC since there has to be alignment.

ARC is the theoretical solution to this, where it can forward auth
information, but how to handle the forwarded auth information is still a
work in progress.

In a long ago thread, we discussed the benefits of doing both forwarding
and pop fetching, to handle the edge cases.

Brandon

On Thu, Apr 28, 2022 at 11:49 AM Geoff Mulligan via mailop <
mailop@mailop.org> wrote:

> I have a user on one of my servers that uses procmail to forward messages
> to their gmail account.
>
> Every once in a while messages sent to them are "bounced" to the sender
> with the error fro gmail:
>
> 550-5.7.26 This message does not have authentication information or fails to 
> 550-5.7.26 pass
> authentication checks. To best protect our users from spam, the 550-5.7.26
> message has been blocked.
>
>
> How can I diagnose this???
>
> Is it that the message sender's domain has a DMARC setting or some such
> that gmail is using and that my server (which is just forwarding the
> message) is failing?
>
> If so, how is someone supposed to forward messages to gmail???
>
> Thanks,
>  Geoff
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] forwarding to gmail - problem

[Geoff Mulligan via mailop]

I have a user on one of my servers that uses procmail to forward 
messages to their gmail account.


Every once in a while messages sent to them are "bounced" to the sender 
with the error fro gmail:


550-5.7.26 This message does not have authentication information or fails to 
550-5.7.26 pass
authentication checks. To best protect our users from spam, the 550-5.7.26
message has been blocked.

How can I diagnose this???

Is it that the message sender's domain has a DMARC setting or some such 
that gmail is using and that my server (which is just forwarding the 
message) is failing?


If so, how is someone supposed to forward messages to gmail???

Thanks,
 Geoff
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop