K.J. Petrie (Instabook) wrote:
We're simply not in a position to negotiate special arrangements
on our accounts to create a "private policy". Does that explain
my concerns?
Yes. In quite a lot of cases it's possible to replace "forward"
(push) by an automatical "collect from POP3" (pull). If that's
possible and good enough for your 'remote' mailboxes you can forget
SPF - "POP3 collectors" (there's probably a better name for this,
but I know only German terms) won't check SPF against IPs on the
side of the receiver.
That's one of many ways to arrange things on the side of receivers
with more than one service provider. Your idea of some DNS-based
"receiver policy" is IMO overkill. You're somewhere behind the MX
of provider A. You want this MX to accept mails forwarded from
provider B to your mailbox at A. From a network perspective that
is a local problem of A, nobody else including B cares about it.
Of course you could in theory use DNS anyway for your communication
with the MX at A, but it's overkill. SPF uses DNS, because this MX
might wish to know what unknown strangers (the senders) think about
mail claiming to come from their domain. But you as receiver are
no unknown stranger, you're a (probably paying) customer of A.
It's not unusual that customers can configure their IMAP account
and spam filtering. They don't use DNS for this, they use IMAP or
simple Web forms. Adding a field "accept stuff from B for me" on
a Web form is no rocket science.
From a "protocol" perspective the only interesting point in this
scenario is "from B", how can the MX at A know that it's really
talking with B and not some spammer claiming to be B.
B (the forwarder) could publish a "HELO policy" for its sending
mailers, and the MX of A could check this - we're assuming that
the MX of A checks SPF, otherwise there's no problem (at least not
with SPF). It starts to get ugly if B has no "HELO policy". And
even if it has one you might need to specify those names in your
local configuration for A. If somebody would ask me which HELO
names all mailouts of de.clara.net use I'd be forced to pass.
That might be difficult, for a given forwarder B, how can a
receiver like you talk about "all mailers of B are okay for me"
in a configuration at A. As it happens claranet.de has an SPF
policy covering all their mailouts, and that's good enough.
If SPF does not allow us to control our forwarding without such
access, we will tend to see it as a threat rather than a help.
As the name says SPF is for senders, it's designed to be a threat
for forged reverse paths. From my POV some mail claiming to be
"from me" cannot be sent by an IP of B. If your POV as receiver
using B as forwarder is different it's your job to arrange this
somehow. You need either the help of B, or of A, or both. Or
you use another method (not forwarding) to move your mails from
B to A. Assuming that A checks SPF, otherwise it's all theory.
is "RCPT TO:" preserved in forwarding?
Not directly, we're talking about a case where RCPT TO:<you(_at_)B>
is replaced by RCPT TP:<you(_at_)A>. There should be a "for you(_at_)B"
note in the timestamp line (Received header field) added at B.
In order to have "another round of verification", though, don't
we need the DATA portion to be completed
No, the MX at A sees RCPT TO:<you(_at_)A> before DATA, it could decide
that you want it without SPF MAIL FROM check at this time. It
cannot do a MAIL FROM reject earlier if it wants to honour your
wishes. There could be other RCPT TO (not only you) who don't
want to get spam (their POV) forwarded from B.
So what the MX at A does is something like this:
EHLO B -> verify that B is really B and no random zombie
MAIL FROM me -> note SPF FAIL (I don't permit B's IPs)
RCPT TO x -> reject somehow (x wants no forged MAIL FROM)
RCPT TO you -> continue (you want it, IYO it's not forged)
RCPT TO z -> etc.
DATA -> accept mail for you, but not for x, etc.
That could be optimized, don't check "MAIL FROM me" if all
RCPT TO like you want the mail forwarded by B anyway.
Frank
-------
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