Note that SRS usually refers to a specific rewriting scheme, one that never
went beyond a draft
and wasn't all that useful directly. You can of course use it, but I don't
think the specific implementation
is that useful. There were people who felt that Gmail should support SRS
or that it already
Dnia 11.07.2023 o godz. 14:29:26 Bill Cole via mailop pisze:
>
> If that were anything close to grammatically correct I might understand it.
That guy is since quite a long time writing messages to this list that are
written in such a way that they couldn't be understood... :(
--
Regards,
>> Outbound MSA re-sends the
>> Inbound spam filter re-sends the message
>> Outbound compliance filter re-sends the message out to the world
Those I consider internal processing of email, which don't really count as
"forwarding" of a email.
I consider a email forwarded, when its being
On 7/11/23 2:09 PM, Sebastian Nielsen via mailop wrote:
I think sender adress should be changed.
I think that /forwarding/, as in altering the envelope recipient
address(es), probably should have the envelope sender address changed.
I say /probably/ because I'm sure there are some
there's one case where SPF +all is valid. That's when you already have DKIM
anyway, and in any event, only if mail from your domain can validly come from
anywhere.
The only time this'd be an issue is if you had MUAs sending directly, which
mostly doesn't exist anymore, much to my chagrin
>>them loathed the idea of the envelope from address being changed at one
or more hops along the way.
I think sender adress should be changed.
The reason is, you didn't compose the email, you shouldn't use the sender's
identity.
When forwarding a email, you overtake the spam responsibility for
On 7/11/23 10:08 AM, Benny Pedersen via mailop wrote:
on next hub envelope sender changes, so new spf problem when next hub
forwards mails
This behavior is not guaranteed and SHOULD NOT be relied on. If it
works, then great! But don't be surprised if it doesn't work.
I remember Sender
On 2023-07-11 at 13:49:32 UTC-0400 (Tue, 11 Jul 2023 19:49:32 +0200)
Benny Pedersen via mailop
is rumored to have said:
> Bill Cole via mailop skrev den 2023-07-11 19:01:
>> On 2023-07-11 at 11:08:23 UTC-0400 (Tue, 11 Jul 2023 17:08:23 +0200)
>> Benny Pedersen via mailop
>> is rumored to have
Bill Cole via mailop skrev den 2023-07-11 19:01:
On 2023-07-11 at 11:08:23 UTC-0400 (Tue, 11 Jul 2023 17:08:23 +0200)
Benny Pedersen via mailop
is rumored to have said:
direct to mx will have spf pass without +all, on next hub envelope
sender changes, so new spf problem when next hub forwards
Brandon Long via mailop skrev den 2023-07-11 18:50:
I assumed most people had already tuned their systems to ignore +all
or overly broad IP ranges, spammers abused that like a decade ago.
so why did gmail.com add 30+ ipv4 when it could be simple as +all ?
:)
i did not count ipv6 on
On 2023-07-11 at 11:08:23 UTC-0400 (Tue, 11 Jul 2023 17:08:23 +0200)
Benny Pedersen via mailop
is rumored to have said:
> direct to mx will have spf pass without +all, on next hub envelope sender
> changes, so new spf problem when next hub forwards mails,
You keep repeating this (and
I assumed most people had already tuned their systems to ignore +all or
overly broad IP ranges, spammers abused that like a decade ago.
I feel like we even discussed it here, including having to exempt Apple who
had their entire class A listed at one point (they no longer do).
Saying anyone can
Alessandro Vesely via mailop skrev den 2023-07-11 11:12:
You need +all if you're after dmarc=pass.
no not at all, direct to mx will have spf pass without +all, on next hub
envelope sender changes, so new spf problem when next hub forwards
mails, it does not need to be a maillist btw
if
On Sat 08/Jul/2023 11:47:41 +0200 Sebastian Nielsen via mailop wrote:
I would say +all is always harmful. The difference between having +all and not
having any at all (or ?all) is that you affirmately, by using +all, tell the
system the email is genuine. If you somehow want to treat all emails
I would say +all is always harmful. The difference between having +all and
not having any at all (or ?all) is that you affirmately, by using +all, tell
the system the email is genuine. If you somehow want to treat all emails as
unspecified or unknown, ergo dont want to reject, but you want to
Good point - thanks for highlighting this, Hans-Martin!
> Am 08.07.2023 um 09:28 schrieb Hans-Martin Mosner via mailop
> :
>
>
> Most likely none of you would consider adding +all to an SPF record a smart
> move, here's another reason why you shouldn't do it:
>
> Google cloud services are
16 matches
Mail list logo
