If the mail is forwarded at the user's request (e.g. college alumni
forwarding-only addresses), then the server to report it to is the one
that received it from outside the user's forwarding chain.
The concept of _server responsible for accepting a message_ is what we
should use here. There may be multiple ones. How to validate them,
etcetera, may be defined afterwards (that's the stance of RFC 5451.)
The web mail systems haven't solved that problem, so I don't think we
need to, either. Any forwarder of any size has FBLs set up, so it will
get reports about forwarded mail via the target system. That works OK
for me.
Not all forwarding targets provide for a FBL. Web mail and FBLs are
local arrangements that can hardly be standardized so that they scale
well to any mail system. I don't see many European FBLs, for example...
Short of a mythical global reputation system, I don't see how one could
divert reports to forwarders without also diverting them to spammers who
pretend to be forwarders.
I thought such _mythical global reputation system_ is what we are
researching right now. IMHO there is a necessary relationship between
abuse reports and MGRSs: V can meaningfully vouch for X only if V can
monitor _all_ ARs originating from mail emitted by X. (see "A Vouch By
Feedback proposal"
http://www.ietf.org/mail-archive/web/asrg/current/msg15679.html)
Even a user-trusted authserv-id validated against Received lines can
be used to divert ARs: for example Alice may configure X as a trusted
server, but mail to Alice(_at_)Y with forged Authentication-Results and
Received header fields may still fool her MUA. While this may not be a
problem now, as Steve said, it feels safer to be able to avoid it,
just in case it will.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg