"Malcolm Weir" <[EMAIL PROTECTED]> writes: >> -----Original Message----- >> From: Lloyd Zusman >> Sent: Thursday, February 12, 2004 4:15 AM > > [ Snip ] > >> And as for this patch itself, remember that it consists >> solely of putting a unique "id" field into the "Received" >> header. This is a minor change, and it mirrors what some >> other MTA's already do. Even if we don't end up using this >> to facilitate the methodology that I outlined in my Modest >> Proposal, it still is a useful feature in and of itself. > > I think overall I agree with Lloyd here that this proposal is both low cost > and generally beneficial, which is more than one can say about the other > schemes discussed! > > And if the unique ID is kept simple (I've received Lloyd's patch, but > haven't yet had a chance to look at the code, so I don't know how simple it > is) it seems to me that, say, adding the ID to the maillog would have some > nice consequences for admins. > > With only a little thought, it seems to me that a 12 byte ID (encoded > base64, naturally, for a 16 character string) would do the trick: IP and > socket from which the thing arrived, 32 bit time-in-seconds, and a 16 bit > iterating counter (to disambiguate messages received through the same socket > during the same second; 64K messages/sec should be fine). Spoofing can be > prevented by positioning: only the first (or last, whichever is easier) ID > header would count, just as only the last "Received-From:" can be trusted.
This is always the topmost "Received" header. "submit" writes that header on top of the message before calling the global filter. I use the following for my unique ID, encoded into base 64: 32-bit IP address 32-bit PID of "submit" (some systems use more than 16 bits for this) 64-bit time from gettimeofday() [down to microseconds] 32-bit incrementing counter I don't know that it's possible to find out the original socket ID from within the "submit" program (which is the sole program I patched) ... "submit" is the program which adds the "Received" header, and it always reads the message from stdin. Hmm ... I now realize that I don't need the incrementing counter, since there will be only one message processed per call to "submit". I will remove it from my code and repost another patch once I test it. > This approach (having Courier add an ID) seems to have the virtue that > those who don't care about rewriting (i.e. those for whom the current > globalfilter/locafilter scheme works sufficiently well) aren't > penalized much by the new header, while those that want/need > sophisticated globalfiltering pay whatever price is necessary for > their requirements. Yes. Those are my main design goals. -- Lloyd Zusman [EMAIL PROTECTED] ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
