-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tony Finch wrote:
On Wed, 6 Jul 2005, Daniel Taylor wrote:
The "forwarding problem" is _only_ an issue for entities that support
SPF at either end. It is only a problem for the forwarder if they care
about it.
My systems don't publish or check SPF, but SPF causes problems for me
because it breaks my users' email, and I have to deal with the complaints.
Configure your mailserver to reinject instead of re-using the original
MAIL FROM and the complaints will go away. With libSRS you can even
reverse route bounces.
2. Have your forwarder reinject.
This doesn't work. (a) It requires changes to the forwarding site, which
is what you are trying to avoid. (b) Where do bounces from forwarding
failures go?
a. As a user, use procmail instead of a raw redirect to forward your
mail.
b. As a site administrator, use reinjection and reverse route bounces.
As a user you have no control over this.
Better still for the administrator, delay acceptance until the remote
accepts the message. You lose a pair of sockets for the duration of
the transfer, but the results are unambiguous.
3. Whitelist your forwarders.
How do you tell which incoming email is forwarded and which is not?
If you can't tell this as a user, SPF is the least of your problems.
- From the admin's perspective, use trusted-forwarders.org and
whitelist other forwarders based on user input.
What happens when the forwarding IP addresses change?
Ideally you can whitelist by RHS so this won't be a problem. Otherwise
you deal with it when/if it happens.
- --
Daniel Taylor VP Operations Vocal Laboratories, Inc.
dtaylor(_at_)vocalabs(_dot_)com http://www.vocalabs.com/
(952)941-6580x203
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCy+6a8/QSptFdBtURAtd7AJ9Wf159DRtYLSch4lsqaYhTCMS6VACdGRkE
PhOHP/Nv9mL6HnqDVbwFaAA=
=iK5y
-----END PGP SIGNATURE-----