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
<mailop@mailop.org>:
> > On 12.10.2024 at 18:06 Louis via mailop <mailop@mailop.org
> > [mailop@mailop.org]> 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
> -all
> redirect=_spf.example.com
>
>
> which denies everything as the redirect will never be reached.
>
>
>
> > > host -t txt example.net
> > > "v=spf1 -include=_spf.example.net +all"
> > > host -t _spf.example.net
> > > "v=spf1 ~all"
> >
> > -include is not a thing. So it would be an invalid record. Even if -include
> > was a thing, ~all would not be taken into account for an include.
>
> Qualifiers can also be used with include. Lets assume Example corp owns the IP
> space 203.0.113.0/25. For simplicitys sake they authorize their complete
> network to send emails with their domain (we actually did this):
> > host -t txt example.com
> > "v=spf1 ip4:203.0.113.0/25 -all"
>
>
> However there are some systems that are not supposed to ever send any emails,
> so they create a deny list with their IP addresses and include this in all
> their SPF records:
> > host -t txt example.com
> > "v=spf1 ip4:203.0.113.0/25 -include:_denyhosts.example.com -all"
>
>
> > host -t txt _denyhosts.example.com
> > "v=spf1 ip4:203.0.113.5 ip4:203.0.113.6 -all"
>
>
> This will grant everything within 203.0.113.0/25 a pass except 203.0.113.5 and
> 203.0.113.6.
>
> > I do think that of all the things, SPF is pretty easy to implement. If you
> > even need to implement it, that is. Seeing how old it is now and how it's
> > already implemented everywhere.
>
>
> I agree that there are more complex specifications than SPF. However SPF is
> not that simple as that everyone or even developers of SPF tools are able to
> understand it within lunch break, as they might think.
> Fir example there are or have been SPF implementations which claim the
> following SPF record is invalid because it exceeds the maximum DNS lookup
> limit:
>
>
> > host -t txt example.com
> > "v=spf1 a mx mx:dep1.example.com mx:dep2.example.com -all"
> with each domain having 5 MX entries.
>
>
> —
> BR Oliver
>
> --------------------------------------------------------------------------------
>
> dmTECH GmbH
> Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
> Telefon 0721 5592-2500 Telefax 0721 5592-2777
> dmt...@dm.de [dmt...@dm.de] * www.dmTECH.de [http://www.dmtech.de/]
> GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
> Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher
>
>
> --------------------------------------------------------------------------------
>
> Datenschutzrechtliche Informationen
> Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser
> ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in
> Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder
> sich bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen
> unter anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren
> Rechten sowie die Kontaktdaten unserer Datenschutzbeauftragten finden Sie hier
> [https://www.dm.de/datenschutzerklaerung-kommunikation-mit-externen-493832].
>
> _______________________________________________
> mailop mailing list
> mailop@mailop.org [mailop@mailop.org]
> https://list.mailop.org/listinfo/mailop
> [https://list.mailop.org/listinfo/mailop]
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
