--On Montag, August 23, 2004 10:07:44 +0800 AccuSpam <support(_at_)accuspam(_dot_)com>
wrote:
[...]
However, I think the scenario below (where the above setting applies) is
so important, and that some (perhaps many) verifiers may not implement
the macro language (AccuSpam does not yet), why not make it easier to
specify and parse this case?
It might be easier to use libspf, libspf2 or Mail::SPF::Query instead of
reinventing the wheel (although I can understand the urge). Taking
shortcuts may look attractive, but will complicate any _full_ implemen-
tation of the SPF spec unnecessary. While you may need a simple scheme
with only the localpart inserted other users also need the IP address
because their ISP dynamically enables them after logging in (e.g. via
RADIUS) only for a certain IP address.
[...]
(1) In scenario I described, the owner of the domain chooses *NOT* want
to set "-all" for his legitimate addresses, because owner is not ready
to follow the requirements for sending email when "-all" is set.
(2) Yet spammers keep forging addresses (of *(_at_)domain) which are *NOT*
the legitimate addresses (of *(_at_)domain), and owner wants to set "-all"
on *ALL* addresses (of *(_at_)domain) which are *NOT* the legitimate
addresses (of *(_at_)domain).
Ok, so he wants "+" for all legitimate addresses, while he still needs
"-" for everything else. See the problem? You can usually enumerate the
legitimate addresses, but enumerating the illegitimate addresses is
hardly possible. So you will still have to list all legitimate addresses
and publish "-all" to catch the remaining ones - which are illegitimate.
In other words, owner of domains want to maintain status quo with his
legitimate address, but blacklist sending from addresses which owner of
domain does not ever use.
Hmm, that would mean "?" for the legitimate addresses (thus subjecting
them to the usual filtering at the recipients site) instead of "+".
| example.net IN SOA ...
| IN TXT "v=spf1 ?exists:%{l}.lp._spf.%{d2} -all"
| user1.lp._spf IN A 127.0.0.1
| user2.lp._spf IN A 127.0.0.1
| user3.lp._spf IN A 127.0.0.1
| user4.lp._spf IN A 127.0.0.1
Here user1, user2, user3 and user4 are the only legitimate addresses in
domain example.net, causing SPF tests to terminate with "neutral" result
(to be handled as if the SPF data had not been published). All other
addresses will result in SPF failure, leading to rejection of that mail.
Ralf Döblitz