wayne wrote on Sunday, January 14, 2007 4:51 PM -0600:
In
<MHEGIFHMACFNNIMMBACAGEFBOEAA(_dot_)sethg(_at_)goodmanassociates(_dot_)com>
"Seth
Goodman" <sethg(_at_)goodmanassociates(_dot_)com> writes:
Per-user policies aren't necessary,
Someone else made this statement. I do agree with it, though I'm
willing to be educated. For MTA's within an organization, it amounts to
asking the recipient to enforce the sending domain's submission policy,
which they cannot properly do. For a legitimate user outside the local
network, the only savings is avoiding the necessity to set up SMTP AUTH.
Though it does accomplish that, it does not prevent trivial forgery by
another user of the foreign MTA, it only limits the mailbox addresses
that can be trivially forged. I'm not saying to dump the per-user
capability, as it comes for free with exists. I would question whether
it's a good idea to suggest that SPF can give the recipient any
confidence that the local-part of an address is not forged.
I disagree. Per-user policies are very important to certain classes
of email senders.
*_IFF_* that's possible at all it should somehow
combine %l and "exists" into what's required for
SES. An "ses" mechanism replacing "exists" (?)
Since %l is only used with exists, combining them makes at least
some sense. To make it worthwhile, the end result would have to be
simpler or easier to understand than the current exists mechanism.
(wayne(_at_)footbone) $ host -t txt pobox.com
pobox.com TXT "v=spf1 mx mx:fallback-relay.%{d}
a:webmail.%{d} a:smtp.%{d} a:outgoing.smtp.%{d}
a:discard-reports.%{d} a:discards.%{d} mx:stor" "e.discard.%{d}
a:emerald.%{d} redirect=%{l1r+}._at_.%{o}._spf.%{d}"
I suspect that certain strong supporters of SPF would object to having
%{l} removed from everything except exists:. I seem to recall seeing
it used in include: also.
Thanks for the correction on uses of %l other than in exists. I agree
there is little gain in removing _any_ existing macros. There would be
reasonable objections unless future parsers had to accept them, which
means no gain at all. My point was that it only makes sense to propose
dropping an existing macro if it actually makes things simpler. While I
don't think it would turn out that way, I was giving the OP an
opportunity to make a case.
--
Seth Goodman
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735