-----Original Message-----
From: Meng Weng Wong [mailto:mengwong(_at_)dumbo(_dot_)pobox(_dot_)com]
[snip]
SENDER REWRITING
Excuse me for being naive, there was probably a long discussion before I came
onto this
list.
From what I understand, when forwarding is set, the forwarding server
maintains the
original envelope MAIL FROM:, but rewrites the recipient to the new recipient
of the
message. When a bounce occurs, the destination servers uses the original sender
to deliver the bounce, unless it's the famous <> in which case no bounce is
delivered
to the sender.
If the MAIL FROM: is rewritten again to reflect the forwarding account, 99% of
the
cases would be taken care of, because 99% of the forwarded mail will not bounce
(although I never ran a forwarding service so I can't be sure of the numbers).
MUAs
will use message header information in a 'reply-to' case, the only place the
MAIL
FROM: is going is into the Return-Path: header.
The other 1% are bounces. Bounces would reach the rewritten address instead
of the original one, which breaks RFC2821. But it's the rare case when there is
a
bounce. In the case of a forwarding service, it might amount to some traffic,
but the
run-of-the-mill ISP rarely has forwarding at all, making it 1% of nearly
nothing.
I'm not saying these cases should not be covered, but warping the MAIL FROM:
out of shape might not be for everyone. My guess would be some organizations
would be content with mail bounces disappearing, although I hold such behaviour
non-ethical at best. On my system however bounce copies are sent to the
postmaster (me!) so it's not that bad. Many setups do that.
Having the information regarding the original envelope sender in the headers may
be a good solution for the rest, in spite of the increased cost of handling,
because
it happens in a small precentage of the messages anyway.
My 2 cents.
-- Arik
**********************************************************************
This email and attachments have been scanned for
potential proprietary or sensitive information leakage.
PortAuthority(TM) Server
Keeping Information Inside
Vidius, Inc.
www.vidius.com
**********************************************************************
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)½§Åv¼ð¦¾Øß´ë ù1Ií-»Fqx(_dot_)com