Sender Policy Framework

Community/TempLoaclpartMacroWarn

if a site suitably restricts the local parts, then it will be able to use `%{l}` for actual DNS queries?

uno specialista SEO specialist consulente di Terni

Sure, however the necessary restrictions are not obvious:

Restriction for using local part in DNS
	ASCII	Unicode
1	`%{l}` can expand into a <dot-atom-text> (2822upd term), that's one or more dot-separated <Atom>s. As long as each <Atom> has length 1..63 SPF has no problem with it.	For EAI `%{l}` can also expand into dot-separated <uAtom>s, with the same length restriction for SPF. However now we are talking about octets: A single UTF-8 character consists of 1..4 octets.
2	Simplified DNS treats ASCII letters as case insensitive, therefore you can have only one policy with an <Atom> `xyz`. If the variants `xyZ, xYz, Xyz, XYz, XyZ, xYZ, XYZ` are treated as different users (mailboxes) DNS and SPF cannot handle this.	DNS does not support case-insensitive <UTF8-non-ascii>: `äöü, äöÜ, ..., ÄÖÜ` are eight different UTF-8 <uAtom>s as far as DNS + SPF are concerned. There are actually far more more variants of the `äöü`-strings if you can't guarantee NFC[1]. Sites supporting EAI hopefully limit this `äöü`-zoo to one `äöü`-mailbox. A piece of software doing this will affect UTF8SMTP and final delivery, but it won't do anything for DNS + SPF queries. DNS and UTF8SMTP can be different departments, nobody is going to "canonicalize" incoming SPF queries.
3	There are various issues if `%{l}` is a <Quoted-string>. It begins with removing quotes and the backslashes of quoted pairs, leading to an embedded dot erratum and a bunch of missing test cases.	EAI has no effect on 3a, neither better nor worse. BTW, nobody supported to get rid of the moronic concept of a quoted pair for <UTF8-non-ascii>. It doesn't affect SPF-EAI, though.
4	I think the above also affect `%{L}` if used in a <domain-spec>. Ditto `%{s}` and `%{S}` containing the local part. Maybe that's another missing test case: For `%{s}` in a <domain-spec> SPF implementations get an "@" within a label of <target-name> and have to treat this as is.

Note that there is no MUST NOT in the RFC, publishers can try it, but they are in trouble if they do. And spammers could intentionally try say "do..ts" as local part, if they find receivers where this helps them to avoid a FAIL.

So what's the bottom line about using those macros?

Radical summaries would be like so

For implementors: get U2A magic for the RHS, but you MUST NOT not touch the LHS, have fun.
For publishers: stay away from local part and sender macros in <domain-spec>, or read and understand the fine print.
For UTF8SMTP MSA operators: maybe transform the RHS to A-labels, that should work as is with SPF everywhere.
For Sender ID fans: the summary is always the same DON'T CHECK PRA, IT DOES NOT WORK AS EXPECTED, ESPECIALLY NOT WITH v=spf1.

telefono erotico ok

cartomanzia telefonica cartomanziaok.it

Unless noted otherwise, all content on this website is dual-licensed under the GNU GPL v2 and the Creative Commons CC BY-SA 2.5.
The openspf.org domain name was donated by James Couzens, and related domain names by John Pinkerton. Thanks!

Sender Policy Framework

Community/TempLoaclpartMacroWarn

if a site suitably restricts the local parts, then it will be able to use %{l} for actual DNS queries?

Restriction for using local part in DNS

So what's the bottom line about using those macros?

The SPF Project

Documentation

Support

if a site suitably restricts the local parts, then it will be able to use `%{l}` for actual DNS queries?