On Tue, 2008-07-22 at 21:31 -0400, Jeffrey Hutzelman wrote:
Kjetil Torgrim Homme <kjetilho(_at_)ifi(_dot_)uio(_dot_)no> wrote:
I think I'd prefer if this trick wasn't mentioned explicitly, but yes, I
think that would be a valid implementation. The draft says
The "Received:" fields from the triggering message MAY be
retained in the notification message [...]
and I personally would prefer it if implementations chose that route.
That seems problematic, if any of the servers mentioned in those headers
also appear on the path the notification takes and are using them to do
loop detection.
does anyone do this? such a scheme will be wrought with false positives
in the presence of forwarding or even mailing lists, unless they expose
detailed recipient information, which would conflict with privacy
concerns.
The notification, which in fact is a _new_ message, has
_not_ been received or processed by those servers.
its existence is a direct and automatic consequence of the original
message, so I don't think it is unreasonable to be able to trace it back
to the Prime Mover, as the ancient Greeks would say.
What's the point of this? Is it to drive the count of Received headers in
notifications up so high that they don't actually get through?
basically, yes :-)
seriously, the hop count limits are generally generous, so I don't think
this will be a problem in practice. e.g., your server adds one
Received, and mine adds three. Majordomo at IMC introduces 4 more hops,
which brings the total to 8. that's a lot of lee-way for additional
forwarding servers.
--
regards,
Kjetil T.