Meng Weng Wong wrote:
The whole world waits in anticipation.
Unlike the message of Ted Hardie in MARID I've understood this
one immediately. But IANAL and more interested in technical
issues, e.g. semantical differences between classic SPF and
the current drafts:
At the moment I use From:<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> not only
in conjunction with MAIL FROM:<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> and
the IPs permitted by `nslookup -q=txt xyzzy.claranet.de` BUT...
...also in conjunction with MAIL FROM:<else(_at_)where(_dot_)example> and
_no_ explicit Sender:<else(_at_)where(_dot_)example>
Is this still okay under the current drafts ? There's no
sender policy for else(_at_)where(_dot_)example(_dot_) Mark used an example in
MARID (proposed by Margaret Olson):
<C3DB19A6-D810-11D8-896F-000393A56BB6(_at_)glyphic(_dot_)com>
<http://article.gmane.org//gmane.ietf.mxcomp:2911>
In this example mybikeshop.com was forced to chage its policy,
and I still don't understand what's going there:
IN TXT "v=spf1 +a:mx.bigisp.com +a:mx.bulkmailer.com -all"
If I'd replace bulkmailer.com by my where.example, then the
sender policy for xyzzy.claranet.de won't be good enough to use
the MSA of where.example with any "PRA" xyzzy.claranet.de
As far as "PRA" is the same as MAIL FROM no problem, because I
use - enforced by the MSA - MAIL FROM:<else(_at_)where(_dot_)example>
But I'm not exactly sure how "PRA" is defined, apparently it
can be the From: header (core-02.txt, 4 step 4), and then I'm
screwed, because my nobody(_at_)xyzzy doesn't match any IP of the
mailouts behind the MSA of where.example
"My" (= my ISP) sender policy does _not_ cover From: addresses.
And my MUA won't insert a Sender (core-02.txt, 4 step 3). At
the moment when I edit a message my MUA doesn't know which
"profile" (= MSA) I'll use to send the message.
In fact I don't know which MSA I'll use, it depends on the time
of the day and other factors. I'm sure that I always use the
same From: address and a MAIL FROM matching the MSA, but these
addresses are not necessarily identical.
Second problem:
MAIL FROM:<spam(_at_)xyzzy(_dot_)claranet(_dot_)de> SUBMITTER=liar(_at_)example
Who gets the bounce of this spam ? Does this depend on the
software of the recipient ? What's the idea of this construct,
why not simply use MAIL FROM:<liar(_at_)example> ? I'm sure that I
didn't send it, the spam(_at_)xyzzy it's forged, as stated in "my"
sender policy.
I'd be very pleased if MARID drops [Sender-Id] and [Submitter]
a.s.a.p., and returns to the working classic model. In the
last two days I got 3000 useless bounces, I'm not interested in
workarounds like SUBMITTER= where this might continue. And the
"PRA" stuff does't fly with my existing MUA resp. with the MSA
of my 2nd ISP (where.example). Of course my 1st ISP won't add
something to its wildcard sender policy of xyzzy.claranet.de
(it's only a vanity host). The "Sender-Id" concept is FUBAR,
please return to plain classic SPF.
Bye, Frank