Modification of: RE: [spf-discuss] Re: Unified SPF Algorithm
Speaking of POBOX.COM, has anyone else experienced difficulty receiving mail
from them?
We had several users who were using POBOX.com and stopped because much of
their mail was not being delivered.
After numerous complaints from users about non-mail delivery, we checked the
POBOX.COM DNS configuration against DNSReport.com and are seeing that two of
their e-mail servers have the same IP address. This appears to be causing
problems with the delivery of e-mail for their users.
Hoe might this affect SPF?
To see the report, check:
http://www.dnsreport.com/tools/dnsreport.ch?domain=pobox.com.
Any of the more experienced members of this forum that might be able to shed
some light?
Bruce Barnes
Chicago Illinois
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Frank
Ellermann
Sent: Sunday, October 03, 2004 20:06
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: [spf-discuss] Re: Unified SPF Algorithm
Greg Connor wrote:
1. pobox.com is my forwarder. pobox.com will process my
incoming mail and forward it to my real address with
SUBMITTER=gconnor(_at_)pobox(_dot_)com
2. pobox.com also sends mail out, on behalf of its customers.
3. Cases 1. and 2. might use the same outgoing gateway.
Therefore, I want to whitelist only mail that was intended
for me and forwarded on my behalf, and other mail coming
from the same HELO (outgoing, not forwarded) doesn't
necessarily merit whitelisting.
Yes, that would be a difference if you (or your MX) uses the
WL for general purposes. If you'd only use this WL in the
case of a spf2.0/mfrom FAIL, then a spf2.0/helo PASS wouldn't
have this unexpected side-effect.
OTOH evaluating a spf2.0/mfrom policy only to ignore it if
the result is FAIL, and if a whitelisted tested spf2.0/helo
results in a PASS would be a waste of time.
In that case SUBMITTER (or a similar forwarding indicator)
is faster, your MX would then know that it only has to check
the spf2.0/helo against the IP, and its local white list.
In other words, I am paranoid, so I don't trust ALL mail
pobox.com sends, but I do trust them to only set
SUBMITTER=gconnor(_at_)pobox(_dot_)com if they are actually forwarding
for me.
It's really very theoretical, as you said. You're talking
about a pobox user, who knows your "real" address, and sends
unsolicited stuff to it using pobox as MSA. And the same
user doesn't know your pobox address, otherwise he could use
pobox as forwarder and bypass your "not on my WL" tests.
Not all forwarders will use SUBMITTER, but we could allow
them an extra method in case they want it.
Sure, but it's not a very convincing concept, so I don't see
why MTA implementors should want to implement it. And it's a
part of the complete PRA package like adding Resent-* headers.
I'm also paranoid, and my paranoia is that MTAs supporting
SUBMITTER "forget" the really important part with the local
white list. And you know who gets the bounces again in this
case (hint: it's not pobox ;-)
Bye, Frank
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta features
SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com