Re: [Exim] Fixing SPF Forward Problem by Reply-to: Hack?

Page principale
Supprimer ce message
Répondre à ce message
Auteur: David Woodhouse
Date:  
À: J Yunke
CC: Suresh Ramasubramanian, exim-users
Sujet: Re: [Exim] Fixing SPF Forward Problem by Reply-to: Hack?
On Sun, 2004-03-21 at 20:29 -0600, J Yunke wrote:
> > AOL publishing spf records means that we know where aol mail will
> > actually originate from, and can check for that as well without keeping
> > track of their IP space and / or rDNS patterns.
>
> So, playing devil's advocate, why wouldn't a company or organization that
> does business with the general public, NOT want to use a mechanism like
> SPF?


One reason you might not want to publish SPF records is because if you
do that, some people might actually check them, and then discard or
reject _valid_ mail which you sent to potential customers who just
happen to commit the 'crime' (in the New World) of having their mail
forwarded from a virtual domain to their real account somewhere.

So by publishing SPF records (other than the no-operation '?all' one)
you cause some of your own valid outgoing mail to get rejected, and you
lose sales. That's why you wouldn't want to do it.

OTOH if you implement SPF to reject incoming mail, you run the risk of
rejecting valid mail from potential customers. That does only happen if
mail is forwarded to you though -- if there are no valid reasons for
mail to be forwarded to your domain, then you can get away with checking
SPF. Of course you need to declare to your local users that addresses at
your domain shall not be used as a forwarding target -- that kind of
thing only tends to happen when employees forward a private address to
their work address.

> Another case in point -- I received many bounces back from servers that
> rejected a virus sent from my @productivity.org account.
> <...>
> If the receipient servers implemented SPF, they'd know it didn't
> likely come from the servers of my domain. This could potentially
> reduce, in the least case, annoyance, and in the worst case, potential
> legal action from a technologically ignorant yet resourceful
> organization.


If the recipient servers were run with even a modicum of clue, they'd
have rejected the offending mail in the first place, rather than
accepting it and subsequently generating a bounce. We don't need to
upgrade the world to SMTPv2 to fix that.

--
dwmw2