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,
Jaro
>> 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 received
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 situations
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 (afaik
>>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 Rewr
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 sa
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 gmail
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 equivalent
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 s
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 dma
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 a
where example.com is your domain, so its clear,
from someone that receives a email from said domain, that they SHOULD NOT
trust it for anything.
Från: Hans-Martin Mosner via mailop
Skickat: den 8 juli 2023 09:27
Till: mailop@mailop.org
Ämne: [mailop] SPF +all considered harmful
Most
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 be
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 being used to spam (ongoing for a long time,
Google doesn't seem to care). What I noticed today is that the spammer is
using domains with S
17 matches
Mail list logo
