[Top] [All Lists]

Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt

2008-07-23 04:07:52

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

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.
Kjetil T.