Re: [Mailman-Developers] Re: way to minimize IO load with MTA supported VERP
On Sat, 2001-12-08 at 03:16, John W Baxter wrote: Exim's delayed delivery warnings are orderly enough that it would be quite easy to ignore them in bounce processing. In several ways, they don't look like failure messages. The other thing is that there is a condition on the generation of delay warning messages. The default configuration for this condition for a few years now has been that mailing list mail (identified by the Precedence: header) does not have delay warnings generated for it. See http://www.exim.org/exim-html-3.30/doc/html/spec_11.html#SEC206 If an admin is running an exim old enough that this conditional is not available or is not defaulted, then take a baseball bat to them until they see the error of their ways. If an admin has changed the condition such that it now sends delay warnings in response to mailing list mail, then add some nails to your baseball bat and wield it appropriately on said admin. Nigel. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Re: way to minimize IO load with MTA supported VERP
Barry A. Warsaw wrote: JCL == J C Lawrence [EMAIL PROTECTED] writes: JCL Mailman is going to end up with a set of MTA-specific and JCL internally configurable VERP configurations to chose from. I actually don't think that MTA-directed VERPing helps us out much. Sure, it can give us an envelope sender that we can use for better bounce detection[*], ...which is clearly all it's good for. I have a significant percentage of users whose bounces are useless without VERP, and it's tiring dealing with the uncaught bounces. If I can get VERP with little extra load (because it's done in the MTA) then I'm happy. (Been running for the last 8-10 hours with Postfix doing the VERPing, with a small hack to SMTPDirect.py, and some logging in BounceRunner.py, and it looks really nice so far.) but I think that the much more interesting personalization is content personalization. I.e. inserting into the message body, footers, headers, RFC 2822 headers, etc. information specific to the recipient. Only Mailman knows that data and how to interpolate it into the message body. AFAIK, there's no way to coordinate this with the MTA, so content personalization is always going to be performed by Mailman. Sure. But that's *expensive*. It's stunning how much more time that all uses up. Granted, I haven't done the various spool vs. syslog optimizations etc., but the point is I don't have to until we get to one-MLM-to-MTA-transaction-per-user. That's when it gets brutal. Anyway, the VERP-in-the-MTA thing seems like a useful featurelet, even if it has limited benefit. Hopefully more MTAs will follow. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Re: way to minimize IO load with MTA supported VERP
Speaking of Exim.. one thing that really bothers me about Exim is the message(s) it sends when it has to wait to deliver the message... these would be interpreted as bounces, although they really are not. I've seen a few such messages, only to have the message delivered normally. That would trigger some bounce logic to at least pick up on what really isn't (yet) a bounce. Bob ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Re: way to minimize IO load with MTA supported VERP
At 14:18 -0500 12/7/2001, Bob Puff@NLE wrote: Speaking of Exim.. one thing that really bothers me about Exim is the message(s) it sends when it has to wait to deliver the message... these would be interpreted as bounces, although they really are not. I've seen a few such messages, only to have the message delivered normally. That would trigger some bounce logic to at least pick up on what really isn't (yet) a bounce. Exim's delayed delivery warnings are orderly enough that it would be quite easy to ignore them in bounce processing. In several ways, they don't look like failure messages. Meanwhile, they let a user who has mistyped an address know about it sooner than without the messages. For an Exim running in support of live users. Assuming, of course, that the Exim administrator has resisted the temptation to improve the delayed delivery message. If she's done that, users are likely to fall off lists. One hopes that the Exim admin and the Mailman admin are speaking to each other. If the Exim is running just to handle Mailman, the warning message can be done away with entirely (and the retry intervals can be adjusted, and several other such adjustments made). Trivially. But of course, you can't configure away messages generated by remote sites you don't control. --John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Re: way to minimize IO load with MTA supported VERP
On Thu, Dec 06, 2001 at 04:59:50PM -0500, [EMAIL PROTECTED] wrote: If one was willing to extend SMTP again, it would be theoretically possible to send one copy of a message to aol.com for 100 recipients with a form of VERP, using an extended syntax like MAIL FROM:[EMAIL PROTECTED] 250 [EMAIL PROTECTED] Sender ok RCPT TO:[EMAIL PROTECTED] EPFX:johnsmith-aol.com- 250 [EMAIL PROTECTED] Recipient ok and the receiving MTA would prepend the EPFX value to the envelope sender for each recipient. I like the basic idea a lot, but that doesn't look very backwards compatible, though. Why not something like MAIL FROM: [EMAIL PROTECTED] 250 [EMAIL PROTECTED] Sender ok RCPT TO: [EMAIL PROTECTED] 250 [EMAIL PROTECTED] Recipient ok OVRD MAIL FROM: [EMAIL PROTECTED] 250 per-recipient override of MAIL ok DATA i.e., a new SMTP command, not a change in existing rules. The sending MTA, if it got an error in response to OVRD, could flag that SMTP connection as being OVRD-incompatible, issue a NOOP, and procede to either give on message efficiently w/o VERP, or several messsages with VERP using the old-style, bandwidth-hogging (current) technique. The NOOP-backout technique appears to be fully compatible with the SMTP RFC. Issuing a NOOP means the sender would not have to be concerened with whether the recipient MTA does not like messages sent with unrecognized control commands. 100% backwards compatible. If VERP is the only real case where per-recipient overrides make sense, then it might make more sense to make a simple VERP command, e.g. VERP [EMAIL PROTECTED] -Peter -- I am what I am 'cause I ain't what I used to be. - S Bruton J Fleming ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: Re: [Mailman-Developers] Re: way to minimize IO load with MTA supported VERP
[*] VERP helps with knowing exactly which address on which list is bouncing, but I don't think it helps much with knowing the severity of the bounce. It doesn't. I'm strongly tempted to treat all bounces as hard, unless we can cheaply _and_ conclusively determine that they are soft. I don't think it would be easily done, and I would venture to say it's not worth the time investment trying to code. I think time is the key to separating hard vs soft. Bounces don't seem to take up much resources, so what's the big deal if we tolerate them over a little longer period of time? Bob
Re: [Mailman-Developers] Re: way to minimize IO load with MTA supported VERP
On Fri, 7 Dec 2001 00:18:57 -0500 (EST) bob [EMAIL PROTECTED] wrote: [*] VERP helps with knowing exactly which address on which list is bouncing, but I don't think it helps much with knowing the severity of the bounce. It doesn't. I'm strongly tempted to treat all bounces as hard, unless we can cheaply _and_ conclusively determine that they are soft. I don't think it would be easily done, and I would venture to say it's not worth the time investment trying to code. I'm not going to argue either way with the man who writes the patch. His choice. His call. I think time is the key to separating hard vs soft. I'd tend to cutting on the line of RFC compliance. If its an RFC compliant bounce, and its soft... Bounces don't seem to take up much resources, so what's the big deal if we tolerate them over a little longer period of time? This depends on the churn rate on your list, and the posting/bounce-detection rate. Larger lists tend to have (numerically larger churn rates, and can become brutally painful quickly. At one point I had a 140K list with ~35% bad addresses (single opt-in silliness I inherited). It was *NOT* fun for a while. -- J C Lawrence -(*)Satan, oscillate my metallic sonatas. [EMAIL PROTECTED] He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
