Re: virtualdomains vs. VERP and Delivered-To
John R. Levine: It's true, qmail doesn't work the way you might first have guessed it does. That doesn't mean it's wrong. Well, qmail-send does rewrite the envelope recipient for local deliveries. That's not a very good thing. /filip
Re: A real bouncesaying
On Thu, Mar 29, 2001 at 07:30:38PM +0200, Filip Salomonsson wrote:
[snip]
Qmail isn't handling virtual domains correctly, as far as I can tell.
Peter van Dijk:
Wut?
Greetz, Peter.
From the dot-qmail man page:
When qmail-local forwards a message as instructed in
.qmail-ext (or .qmail-default), it checks whether
.qmail-ext-owner exists.If so, it uses local-
owner@domain as the envelope sender for the forwarded mes--
sage. Otherwise it retains the envelope sender of the
original message.
Oh, great. here's a line from my virtualdomains file:
netdesign.se:salo
in ~salo/.qmail-filip:
./Maildir/
[EMAIL PROTECTED]
in ~salo/.qmail-filip-owner:
[EMAIL PROTECTED]
A message is recieved for [EMAIL PROTECTED], delivered locally to
salo-filip, which puts the message in my maildir and forwards a copy to
[EMAIL PROTECTED] The envelope sender for the forwarded message is set to
[EMAIL PROTECTED], just as the docs say ("local" is salo-filip).
But it makes no sense. If the delivery fails, the bounce message will be
sent to [EMAIL PROTECTED], and the delivery instructions will be
sought for in ~salo/.qmail-salo-filip-owner, which doesn't exist. Good job.
The -owner files render themselves completely useless.
Also, any message sent to [EMAIL PROTECTED] will have "Delivered-To:
[EMAIL PROTECTED]" in the header, which is confusing.
[EMAIL PROTECTED] would be "correct". As would
[EMAIL PROTECTED] (the "me" control file says
kepler.netdesign.se).
In short -- qmail handles deliveries to virtual domains/users exactly the
way the docs say (as far as I can tell). But what the docs say is just plain
stupid.
/filip
Re: A real bouncesaying
Filip Salomonsson: The -owner files render themselves completely useless. Dave Sill: So create ~salo/.qmail-salo-filip-owner or ~salo/.qmail-salo-default. Well, that's what I've done. Works like a charm. But what if there was a salo@ address(and/or salo-filip@ with a corresponding -owner file)? Many problems can be worked around, but that's rarely a good permanent solution. You're certainly entitled to your opinion, but calling the current, documented behavior incorrect is misleading. So is the current, documented behavior. /filip
Re: A real bouncesaying
Filip Salomonsson: Also, any message sent to [EMAIL PROTECTED] will have "Delivered-To: [EMAIL PROTECTED]" in the header, which is confusing. [EMAIL PROTECTED] would be "correct". As would [EMAIL PROTECTED] (the "me" control file says kepler.netdesign.se). Peter van Dijk: Delivered-To is there primarily for loopdetection. Sure. But while it's there, why not make it as useful as possible? I'm not saying that there's anything wrong with the way Delivered-To lines are written today. I'm only suggesting something that I think would be a better solution. It also happens to be useful for multidrop pop3, and serialmail. Strip off the prefix and you know the address. Sure, I can do that. But only if I already know that I'm dealing with a virtual domain. /filip
Re: A real bouncesaying
Johan Almqvist: With a few pointers from Frank Tegtmeyer, I've now made what I wanted myself. Maybe someone else finds this useful... Peter van Dijk: Without testing it, a short glance over the code reveals one quirk and one change I'd like: - You are using a predictable filename in /tmp without any security whatsover. This allows a malicious users to overwrite files that you own, perhaps gaining access to your account this way. - It says 'this is the qmail-send program'. It is not. 'qmail-send' is not a fixed string in the QSBMF, so why not change it? Also, why not use the $SENDER variable that qmail provides? Not to mention that the address mentioned in the bounce message won't match the original recipient when using virtualdomains. That might be trickier to fix, though. Qmail isn't handling virtual domains correctly, as far as I can tell. /filip
scaling for temporary high loads
Once a month, I send a newsletter to approx. 350k subscribers. The newsletters are 15-20 kb each. I've had some not-so-convenient approaches to this earlier, but I'd like to start using our Sun Ultra5 (Solaris 7) with qmail (patched with big-todo and big-concurrency) and ezmlm for this job. As long as I can get most of the messages delivered within 24 hrs, I'll be a happy little camper. I thought I'd raise conf-split and the outbound concurrency limit, set the appropriate resource limits (open files, max user processes -- any others?) and then let ezmlm and qmail do their job. Am I missing something? Should this setup be alright? /filip
Re: Anybody heard from Michael Samuel?
Magnus Bodin: Now everyone sits around with their own little qmail-page. If all these were at least archivable together the qmail-world would have been a safer place. Good thinking, Magnus. Patches, additions and related documentation, all physically stored in one (with mirrors, of course) place in a somewhat unified manner would be A Nice Thing Indeed. Searchable? Sure. Categorized? Why not. Useful? Very. Johan Almqvist: As always, I totally agree with Magnus ;- I'd be willing to contribute with time and (maybe) bandwidth. I'm in. Come to think of it, I registered a domain name for something like this a while back. Enterprising as I am. Never got any further than that, though. ;-) /filip
Moving the qmail directory
I'm running short on space on my /var partition, which limits the size of my qmail queue in a rather unpleasant manner. This is a Bad Thing, obviously, and I thought I'd solve the problem temporarily by moving the qmail directory. If I move /var/qmail to /export/qmail, and replace it with a symbolic link pointing to the new location, is there anything that might cause things to explode into my face? /filip -- filip(salomonsson)@netdesign.se
