John Peacock wrote:
Keith Ivey wrote:
Qmail also pays attention to the Delivered-To header.
Correct, there are two places that qmail checks for loops:
qmail-local.c: strerr_die1x(100,"This message is looping: it already has my Delivered-To line. (#5.4.6)");
qmail-smtpd.c: if (hops) { out("554 too many hops, this message is looping (#5.4.6)\r\n"); return; }
But, I don't think that the qmail-local test is correct for qpsmtpd to deal with, though, since that is part of the LDA portion (and qpsmtpd always hands that task off to some other code). That test is there in qmail-local to prevent stupid .qmail tricks...
Ideally qpsmtpd should never let anything through that qmail isn't going to accept.
I agree completely, with the caveat that there are areas outside of qpsmtpd's baliwick (like the local delivery mentioned above). Remember that qpsmtpd is *only* acting as replacement for qmail-smtpd (or its moral equivalent if you are using some other MDA behind it).
John
John's math approach would work. Probably you could strip off the last eight bits, sub-net the ip's you're counting. If multi-homing led to different subnets for mta's, still you'd only double the count, and come in under qmail's "100"(perl beating C).
It would have to be in the domain of a locally developed plugin to figure out if the delivery was local. It might be good to go as far as knowing everything qmail knows, but that's as far as qpsmtpd core could go. The trouble there is qpsmtpd can only see the qmail control files on one machine. Dead-end.
I can't think of how to fuzzy-associate the multiple Delivered-To: without every false-pos, but counting IP subnet iterations seems like the basis for a decision, definitely.
-Bob
