Hi, * Rob 'Feztaa' Park [02-07-16 03:34:04 +0200] wrote: > Alas! Derrick 'dman' Hudson spake thus:
> > It's a crude, but effective, loop detection mechanism > > (mentioned in RFC 821 as well). When the MTA sees what > > it thinks is an excessive number of Received: headers it > > figures a mail loop has occured and bounces the message > > instead. > Wouldn't it be more effective to check the Received headers to see if > it's gone through the same server twice, and /then/ bounce the mail? RfC 2821 suggests using dump counting. > It's not a mail loop if it just has a lot of servers to go through. After reading a little in RfC 2821 it made me sick, escpecially section 6.2. ,----[ rfc2821.txt ]- | | 6.2 Loop Detection | | Simple counting of the number of "Received:" headers in a | message has proven to be an effective, although rarely | optimal, method of detecting loops in mail systems. SMTP | servers using this technique SHOULD use a large rejection | threshold, normally at least 100 Received entries. Whatever | mechanisms are used, servers MUST contain provisions for | detecting and stopping trivial loops. `- (esp. ``SHOULD use a large...'', this has to read: ``MUST use at least 100...'') ...whatever the authors consider a mechanism to detect a trivial loop to be. If I had to write software detecting loops I would only check Received: headers. It needs some more than just this: virtual domains, Received: headers can be faked, etc. But by simply counting the number of hops the mail went through is not really clever allthough it's unlikely that there're 100 relays within a mail route. But the number of hops is not necessarily low, content filters (like virus scanners: 10 hops with 3 filters each make already 30 hops). bye, Rocco
