RE: [exim] Pobox and SPF

Please don't top-post, and please don't quote more of the original mail
than you need to.

On Wed, 2005-07-06 at 04:45 +0300, Sub Zero wrote:
> How can genuine mails sometimes allowed but sometimes they are
> disallowed?

This is the flaw in any of the proposals which attempt to tie mail from
certain addresses to coming only from certain IP addresses. Assume you
have only one mail server, so you publish a record for your domain which
lists that mail server as OK, and results in a 'fail' for any other IP
address.

You send a mail to one of the multitude of virtually-hosted domains,
where the hosting company doesn't actually provide full mail service but
just forwards mail to a real mailbox elsewhere, usually at the domain
owner's ISP. There are countless examples of this.

Now, think about what the ISP sees -- it sees a mail from you, but
coming from an IP address which isn't yours. But it's a genuine mail,
and this is the way the world has always worked.

Thus, the mail is 'disallowed'. Herb is right that if we're going to
nit-pick, it's actually the receiving ISP's local policy which may (or
may not) disallow the mail. And that's an important point because
thankfully most ISPs have enough technical clue to see the problems and
refrain from participating in such schemes.

But this is why Axel shouldn't have been at all surprised that his
policy ended up rejecting valid mail. Whether it be due to a
misconfiguration of someone's SPF record, or the fundamental brokenness
of the entire scheme, that's what one expects if using SPF.

Some are advocating that the entire world should change -- all those
hosting providers and other hosts which forward mail (including every
*nix box with .forward files) should all be changed to mangle the mail
as it passes through, so it gets a new reverse-path with a domain which
is local to the forwarder, and then bounces to that generated
reverse-path should be 'unwrapped' and sent back to the original sender
of the original mail. But there isn't even a _draft_ of an update to
RFC2821 which mandates such behaviour yet, and until it's actually
_implemented_ everywhere, the problem remains.

--
dwmw2