On Fri, Oct 11, 2024 at 04:56:16PM -0400, Mark E. Mallett via mailop wrote:
> That was my initial reaction(*) too, about "trivial to implement."
"Implement" can mean "deploy" or it can mean "write code to process"
(more or less). At the start of this thread I assumed the latter, but it
appears it
On 10/14/2024 7:12 AM, Matus UHLAR - fantomas via mailop wrote:
"can be trivial"
For technology, (and most other contexts) "can be" is a code phrase for
"isn't". Especially when already deployed.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
_
I mean that I just proved your point Oliver, finding names in these email
threads can be hard when you're not paying attention haha. sorry for the
confusion.
Groetjes,
Louis
Op maandag 14 oktober 2024 om 17:50, schreef Louis :
> Ha, I guess you proved Gellners point of (me) not actually knowi
Ha, I guess you proved Gellners point of (me) not actually knowing anything
without looking at the RFC in detail. Guess it is harder to implement than it
seems on the surface, then.
Groetjes,
Louis
Op zondag 13 oktober 2024 om 11:47, schreef Gellner, Oliver via mailop
:
> > On 12.10.2024 at 1
Matus UHLAR - fantomas via mailop skrev den 2024-10-14 16:12:
"v=spf1 mx -all"
together with
"v=DMARC1; p=reject"
are both trivial and can work.
Yes, they can be made more complicated. Yes, mail can't be forwarded,
we need DKIM for that.
and dmarc needs dkim in some cases
spf would work if
On 13.10.24 14:20, Dave Crocker via mailop wrote:
I wonder whether anyone has noticed that a thread like this
demonstrates that SPF is far from trivial?
Prehaps I should've said "can be trivial" or "basis SPF record" or something
alike; a SPF record of:
"v=spf1 mx -all"
together with
"v=DMA
I wonder whether anyone has noticed that a thread like this demonstrates
that SPF is far from trivial?
d/
On 10/13/2024 2:47 AM, Gellner, Oliver via mailop wrote:
which denies everything as the redirect will never be reached.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocke
On 12.10.2024 at 18:06 Louis via mailop wrote:
host -t txt example.com
"v=spf1 redirect=_spf.example.com -all"
host -t _spf.example.com
"v=spf1 +all"
Redirect makes it a replacement for the record, so +all
redirect has the lowest precedence in SPF records, so the statement is
evaluated as
On Sat, 2024-10-12 at 15:59 +, Louis via mailop wrote:
> > host -t txt example.com
> > "v=spf1 redirect=_spf.example.com -all"
> > host -t _spf.example.com
> > "v=spf1 +all"
> Redirect makes it a replacement for the record, so +all
>
Not according to RFC 7208. Section 6.1 ends:
===
Any "redi
> host -t txt example.com
> "v=spf1 redirect=_spf.example.com -all"
> host -t _spf.example.com
> "v=spf1 +all"
Redirect makes it a replacement for the record, so +all
> host -t txt example.net
> "v=spf1 -include=_spf.example.net +all"
> host -t _spf.example.net
> "v=spf1 ~all"
-include is not a
> On 11.10.2024 at 23:02 Mark E. Mallett via mailop wrote:
>
> On Fri, Oct 11, 2024 at 04:20:23PM +, Dave Crocker via mailop wrote:
>>> On 10/11/2024 12:49 AM, Matus UHLAR - fantomas via mailop wrote:
>>> Yes, SPF has drawbacks. But it is still trivial to implement and makes
>>> DMARC easie
macros and the nesting/indirection, especially.
d/
On 10/11/2024 1:56 PM, Mark E. Mallett via mailop wrote:
The
macro handling, f
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mail
On Fri, Oct 11, 2024 at 04:20:23PM +, Dave Crocker via mailop wrote:
> On 10/11/2024 12:49 AM, Matus UHLAR - fantomas via mailop wrote:
> > Yes, SPF has drawbacks. But it is still trivial to implement and makes
> > DMARC easier to implement as well.
>
>
> Actually it isn't.
That was my init
On 10/11/2024 12:49 AM, Matus UHLAR - fantomas via mailop wrote:
Yes, SPF has drawbacks. But it is still trivial to implement and
makes DMARC easier to implement as well.
Actually it isn't. And, really, it doesn't.
* It is trivial for a sender to generate an SPF record.
* It is also triv
On Fri, 11 Oct 2024, Scott Q. wrote:
if you don't mind me asking, when you say:
which makes it easy for any of their customers to SPF spoof any
other customer.
you mean the header or the envelope from ? Afaik, the envelope from is
(should be!) tied to the authenticated user
Indeed it should
On 2024-10-11 at 01:59:04 UTC-0400 (Fri, 11 Oct 2024 01:59:04 -0400)
Scott Q. via mailop
is rumored to have said:
Hi John,
if you don't mind me asking, when you say:
which makes it easy for any of their customers to SPF spoof any
other customer.
you mean the header or the envelope from ? A
> On 11.10.2024 at 08:11 Scott Q. via mailop wrote:
>
> Hi John,
>
> if you don't mind me asking, when you say:
>
> > which makes it easy for any of their customers to SPF spoof any other
> > customer.
>
> you mean the header or the envelope from ? Afaik, the envelope from is
> (should be!) t
On 10/9/2024 11:57 PM, Matus UHLAR - fantomas via mailop wrote:
checking SPF is a fallback mechanism.
On 10.10.24 12:36, Dave Crocker via mailop wrote:
SPF is a fairly complex, fragile tool and it makes DMARC.. It's
inclusion in DMARC is always justified with language such as you used,
but I'
Hi John,
if you don't mind me asking, when you say:
> which makes it easy for any of their customers to SPF spoof any
other customer.
you mean the header or the envelope from ? Afaik, the envelope from is
(should be!) tied to the authenticated user
Scott
On Friday, 11/10/2024 at 00:21 John Lev
It appears that Dave Crocker via mailop said:
>
>On 10/9/2024 11:57 PM, Matus UHLAR - fantomas via mailop wrote:
>> checking SPF is a fallback mechanism.
>
>SPF is a fairly complex, fragile tool and it makes DMARC.. It's
>inclusion in DMARC is always justified with language such as you used,
>b
On 10/9/2024 11:32 PM, Thomas Walter via mailop wrote:
On 09.10.24 21:59, Dave Crocker via mailop wrote:
Since the primary function of the SMTP Mail From command is to specify
an address for receiving email handling problem notices, alignment with
the rfc5322.From field domain would seem to be s
On 10/9/2024 11:57 PM, Matus UHLAR - fantomas via mailop wrote:
checking SPF is a fallback mechanism.
SPF is a fairly complex, fragile tool and it makes DMARC.. It's
inclusion in DMARC is always justified with language such as you used,
but I've never seen any data offered about just how us
On 09.10.24 21:59, Dave Crocker via mailop wrote:
Since the primary function of the SMTP Mail From command is to specify
an address for receiving email handling problem notices, alignment with
the rfc5322.From field domain would seem to be secondary, at best.
On 10.10.24 08:32, Thomas Walter vi
Hey,
On 09.10.24 21:59, Dave Crocker via mailop wrote:
> Since the primary function of the SMTP Mail From command is to specify
> an address for receiving email handling problem notices, alignment with
> the rfc5322.From field domain would seem to be secondary, at best.
Isn't this kind of alignme
On 10/9/2024 12:49 PM, Al Iverson via mailop wrote:
this is a limitation
Al,
Perhaps I'm missing something basic. but...
Since the primary function of the SMTP Mail From command is to specify
an address for receiving email handling problem notices, alignment with
the rfc5322.From field dom
It happens to me as well on any aliases I have on workspace. It will use
the primary address of the account for the RFC5321.mailfrom rather than
the responding alias. Vexing, but it's covered by DKIM, so... meh.
- Mark Alley
On 10/9/2024 2:49 PM, Al Iverson via mailop wrote:
Hey all,
After
nthony Mitchell
wrote:
>
> To my knowledge, it is not possible
>
>
> From: mailop on behalf of Al Iverson via mailop
>
> Sent: Wednesday, October 9, 2024 8:55:05 pm
> To: mailop
> Subject: [mailop] SPF alignment when sending from G Sui
To my knowledge, it is not possible From: mailop on behalf of Al Iverson via mailop Sent: Wednesday, October 9, 2024 8:55:05 pmTo: mailop Subject: [mailop] SPF alignment when sending from G SuiteHey all,After configuring email alias domains on Google Workspace/G Suite, andthen when sending from an
Hey all,
After configuring email alias domains on Google Workspace/G Suite, and
then when sending from an alias domain, I note that while DKIM
authentication works and is aligned to the from domain, that SPF
authentication does not align; Google always uses the primary domain
in the return-path, l
29 matches
Mail list logo
