On 20/12/2012 13:22, Henrik Schack wrote:
Ok, I wasn't aware about this Hotmail pick and choose approach to the
SPF specification.
Well... Implementers of standards are constrained by all sorts of
things. Like many standards, SPF contains a couple of really bad ideas
("exists:" is one, another is "-all") which builders of real-world
systems find themselves having to ignore in order to build something useful.
Kinda hard to make things work if you can't trust the SPF testing
tools available on the Internet :-(
Is this documented somewhere ?
In general you can assume that email receivers will do everything they
can to keep their systems working in the face of massive abuse, despite
what specifications say (N.B.: specifications are requests for comment,
not enforced laws). Different receivers do different things and most
won't say what.
(I.e.: no.)
Guess I just got myself a puzzle, I didn't create an "exists" based
SPF record just for the fun, but because my company uses a lot of
different single mailserver ip's
Is there any known limits to the amount of nesting allowed when using
the include statement in SPF records ?
If a receiver needs more than 10 (11?) DNS queries to get at your entire
record then you can expect randomness (ignoring you completely, only
paying attention to the first 10/11 results, ...). I thought that this
was in the RFC.
You realise that you can use CIDR notation even if you don't send email
from all of the servers in the block?
e.g. If you have servers at 10.1.2.6, 10.1.2.9 and 10.1.2.13 you can
simply list 10.1.2.0/28, so long as the other addresses in that range
are either unused or are allocated to hosts that you control. (In other
words, just list your networks, rather than the individual IP addresses
that send email.)
- Roland
--
Roland Turner | Director, Labs
TrustSphere Pte Ltd | 3 Phillip Street #13-03, Singapore 048693
Mobile: +65 96700022 | Skype: roland.turner
[email protected] | http://www.trustsphere.com/
_______________________________________________
dmarc-discuss mailing list
[email protected]
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms
(http://www.dmarc.org/note_well.html)
