qmail Digest 20 Jan 1999 11:00:16 -0000 Issue 526
Topics (messages 20654 through 20701):
Three solutions for spam
20654 by: [EMAIL PROTECTED]
20674 by: "Racer X" <[EMAIL PROTECTED]>
20676 by: "Racer X" <[EMAIL PROTECTED]>
20692 by: Russ Allbery <[EMAIL PROTECTED]>
20693 by: Russ Allbery <[EMAIL PROTECTED]>
20695 by: "Racer X" <[EMAIL PROTECTED]>
20696 by: "Racer X" <[EMAIL PROTECTED]>
20700 by: Pavel Kankovsky <[EMAIL PROTECTED]>
20701 by: [EMAIL PROTECTED]
Possible Anti-spam solution (was Re: Example of the anti-fax effect)
20655 by: Pavel Kankovsky <[EMAIL PROTECTED]>
20679 by: Mark Delany <[EMAIL PROTECTED]>
Mailbox altered by pine?
20656 by: Stanley Horwitz <[EMAIL PROTECTED]>
20657 by: Sam <[EMAIL PROTECTED]>
20658 by: Vince Vielhaber <[EMAIL PROTECTED]>
5,000 dial-up users.
20659 by: "Andy Cowles" <[EMAIL PROTECTED]>
How do I filter outgoing mail based on Sender ?
20660 by: [EMAIL PROTECTED]
20675 by: "Luca Olivetti" <[EMAIL PROTECTED]>
remember this?
20661 by: Steve Vertigan <[EMAIL PROTECTED]>
[[EMAIL PROTECTED]: failure notice]
20662 by: Peter van Dijk <[EMAIL PROTECTED]>
20671 by: Mario Lorenz <[EMAIL PROTECTED]>
20678 by: "D. J. Bernstein" <[EMAIL PROTECTED]>
Newsgroups w/qmail
20663 by: "Brock Eastman" <[EMAIL PROTECTED]>
20664 by: Lars Balker Rasmussen <[EMAIL PROTECTED]>
Emacs MUA's and sendmail errors
20665 by: Dave Sill <[EMAIL PROTECTED]>
pipelining
20666 by: Dave Sill <[EMAIL PROTECTED]>
Some Progress...
20667 by: Craig Burley <[EMAIL PROTECTED]>
20669 by: Sam <[EMAIL PROTECTED]>
unresolvable relay
20668 by: [EMAIL PROTECTED]
20670 by: Sam <[EMAIL PROTECTED]>
20672 by: Michael Bracker <[EMAIL PROTECTED]>
relays and VERP
20673 by: Pavel Kankovsky <[EMAIL PROTECTED]>
20680 by: Mark Delany <[EMAIL PROTECTED]>
20685 by: Pavel Kankovsky <[EMAIL PROTECTED]>
VERB
20677 by: Russell Nelson <[EMAIL PROTECTED]>
20682 by: Matthias Pigulla <[EMAIL PROTECTED]>
20683 by: Keith Burdis <[EMAIL PROTECTED]>
20684 by: Sam <[EMAIL PROTECTED]>
20686 by: [EMAIL PROTECTED]
20687 by: Russell Nelson <[EMAIL PROTECTED]>
20688 by: Matthias Pigulla <[EMAIL PROTECTED]>
20689 by: Pavel Kankovsky <[EMAIL PROTECTED]>
20690 by: Matthias Pigulla <[EMAIL PROTECTED]>
RFC qmail optimizations [Was: relays and VERP]
20681 by: Matthias Pigulla <[EMAIL PROTECTED]>
Fwd: Fwd: Re: Unsubscribe info
20691 by: Keith Burdis <[EMAIL PROTECTED]>
qmail error loggin
20694 by: Matthias Pigulla <[EMAIL PROTECTED]>
HELP ! qmail-pop3d not timing out.
20697 by: R Aldridge <[EMAIL PROTECTED]>
Solaris 7 intel and Qmail install
20698 by: Bert Beaudin <[EMAIL PROTECTED]>
20699 by: "Adam D. McKenna" <[EMAIL PROTECTED]>
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
On Mon, 18 Jan 1999, Edward S. Marshall wrote:
> On Mon, 18 Jan 1999 [EMAIL PROTECTED] wrote:
> > > Invalid assumption; you do not have the "right" to send me mail. You -may-
> > > be able to send me mail if you pass my "arbitrary criteria".
> >
> > Do you warn your customers, that they may never receive legitimate mail?
>
> Of course. Anything else would be a disservice to them, and a legal
> liability to me.
Really? Well the good news are, u show some wisdowm, the bad news i would
never use your services. :-) I prefer to get some spam (which in fact i
do, i don't count it, but's something like 3-4 messages a day) than to
lose legitimate mail.
--
Tiago Pascoal ([EMAIL PROTECTED]) FAX : +351-1-7273394
Politicamente incorrecto, e membro (nao muito) proeminente da geracao rasca.
>Of course there is. Blocking port 25 for all their dialup lines is a
>simple router configuration. Re-enabling it on a customer-by-customer
>basis on dynamic dialups requires software to interact with the terminal
>authentication server that they'd probably have to write themselves.
Wrong. It simply requires you to use Radius and network equipment that
allows you to send back filters in your Radius authentication. Neither
of these are esoteric or hard to do, and are the rule, not the exception,
at any ISP with more than a handful of users.
>Lots of people scream loudly at an overworked ISP about spam from their
>dialups. ISP could (a) improve their tracking and reporting measures
and
>their abuse staff and cancel spammer accounts faster,
What exactly did you have in mind to "improve tracking and reporting
measures?" Tracking and reporting is not the problem. Tracking is
trivial for anyone who keeps dialup logs; rest assured that people who
get spammed will report it to you. The point is not to cancel spam
accounts "faster;" the point is to keep the crap from going out in the
first place.
>(b) spend lots of
>time implementing a scheme where they can give their good customers the
>same service as they had before,
You've lost me here.
>or (c) just do something fast and quick
>that reduces service for everyone in a way that 95% of their customers
>won't care about and that will get the anti-spam folks off their backs.
Over 99% of typical dialup customers have no need to use anything but
the ISP's mail server. I'm basing this number on my 4 years of
experience doing contract and full-time work for 5 ISP's in 3 major
metropolitan areas. I'm willing to admit that the number might be lower
for other areas or other ISP's but I think 99% is a safe bet.
The 1% that do care can either be provided with the service they need or
(usually) talked out of it by simply explaining the nature of the service
they're looking for. Some people have concerns for privacy but fail to
realize that merely avoiding our mail server wouldn't keep us from
snooping anyway. Others run Linux or something with sendmail and just
don't know how to set up their machine properly. It's worth an hour of
my time to keep a customer happy and educate them on how to better run
their system.
The notion that ISP's implement these policies as a way to "screw" the
customer is foolish. These policies help the ISP become a better net
citizen, provide a higher level of service to their customers and thus
increase the value of the service.
shag
>> * It takes a lot less time and effort to figure out when someone is
>> spamming and who they are, since everything is occurring on your mail
>> server.
>
>This is not a benefit to the customer.
False. It saves time (read: money) on the admin side of things, allowing
you to do other things with the customer's money than try to figure out
when people are spamming.
>> * It allows the ISP to take a pro-active role in spam prevention.
It's
>> fairly simple to write a shell script that checks the mail queue every
>> few minutes, or sees how many connections occurred, and send an alert
>> based on that.
>
>This is not a benefit to the customer.
False. See above.
>> All of these measures benefit the customers as much as the admins, in
>> terms of the savings in time and resources needed to deal with spam.
>
>No, they don't. They benefit the admins in the amount of time and
energy
>they have to spend dealing with outgoing spam, something that in a
>well-run ISP the legitimate customers of the ISP should never notice.
Huh? Time and energy == money. If the ISP is spending all its time and
money watching out for spam, they don't have any left to add new features
that customers want.
>Don't fool yourself. The benefit to the customer in blocking port 25
>outbound is basically nonexistent; it's entirely about administrative
>resources devoted to keeping one's site from abusing the Internet. It
may
>be necessary, but you can't sell it as a feature.
Methinks you've never actually worked in this business. Perhaps you
can't "sell" the feature, no. But it makes the business more efficient
and competitive by taking better advantage of scarce resources (and yes,
resources are quite scarce in this industry). This is a Good Thing for
everyone involved.
As for the "nonexistent" benefits, I think I'll be the judge of that.
shag
Racer X <[EMAIL PROTECTED]> writes:
>> Of course there is. Blocking port 25 for all their dialup lines is a
>> simple router configuration. Re-enabling it on a customer-by-customer
>> basis on dynamic dialups requires software to interact with the
>> terminal authentication server that they'd probably have to write
>> themselves.
> Wrong. It simply requires you to use Radius and network equipment that
> allows you to send back filters in your Radius authentication.
Good, I'm glad to hear that it's improved. (It certainly used to be the
case that this was hard.) So how many ISPs are going to be willing to do
this? The cost that I was talking about is not only programming effort
(thankfully apparently not an issue) but also administrative overhead.
(See below.)
>> Lots of people scream loudly at an overworked ISP about spam from their
>> dialups. ISP could (a) improve their tracking and reporting measures
>> and their abuse staff and cancel spammer accounts faster,
> What exactly did you have in mind to "improve tracking and reporting
> measures?" Tracking and reporting is not the problem. Tracking is
> trivial for anyone who keeps dialup logs; rest assured that people who
> get spammed will report it to you. The point is not to cancel spam
> accounts "faster;" the point is to keep the crap from going out in the
> first place.
No, I disagree, because any measure that you use to prevent the crap from
going out in the first place *will* result in loss of legitimate mail.
This is the inherent problem with spam filtering, and is something that
Dan's been rightfully pointing out on this list for a while. I *do* do
spam filtering, but solely because there's currently no better
alternative.
The only *real* solution is to provide sufficient economic or legal
disincentive (because that's the only thing people actually listen to) to
stop spamming in the first place. Cleanup charges, laws that allow people
to collect damages... that's what's going to make it go away. But in a
world where ISPs routinely give out free trial accounts and certain large
ISPs refuse as a matter of policy to even check credit card numbers to see
if they belong to people who were previously kicked off for spamming,
trying to do anything *real* about spam is almost a lost cause.
Filters and the like is an arms race. You develop better stuff, the
spammers develop better stuff to get around it. Doomed, at least without
putting everyone behind an interface that would make AOL look flexible.
>> (b) spend lots of time implementing a scheme where they can give their
>> good customers the same service as they had before,
> You've lost me here.
If you want to turn on port 25 for certain customers on a customer-by-
customer basis, you have to implement some sort of tracking for those
people, and a procedure for them to get approved, and....
>> or (c) just do something fast and quick that reduces service for
>> everyone in a way that 95% of their customers won't care about and that
>> will get the anti-spam folks off their backs.
> Over 99% of typical dialup customers have no need to use anything but
> the ISP's mail server. I'm basing this number on my 4 years of
> experience doing contract and full-time work for 5 ISP's in 3 major
> metropolitan areas. I'm willing to admit that the number might be lower
> for other areas or other ISP's but I think 99% is a safe bet.
Like I said.
> The 1% that do care can either be provided with the service they need or
> (usually) talked out of it by simply explaining the nature of the
> service they're looking for. Some people have concerns for privacy but
> fail to realize that merely avoiding our mail server wouldn't keep us
> from snooping anyway. Others run Linux or something with sendmail and
> just don't know how to set up their machine properly. It's worth an
> hour of my time to keep a customer happy and educate them on how to
> better run their system.
Like I said. And there are a few people who just want to be in control of
their own mail. I know I would. I know lots of other people feel the
same way. You may be a great, well-run, reliable outfit, but the fact
remains that computers fail and things go wrong, often at the *remote*
side, and unless you're running your own outgoing mail, finding out about
it is a crap shoot.
> The notion that ISP's implement these policies as a way to "screw" the
> customer is foolish.
That isn't what I said.
> These policies help the ISP become a better net citizen,
Yes, definitely true.
> provide a higher level of service to their customers
I'm sorry, but this is simply not true. Less is not more. You're
providing less service. There's no way to get around that. I'd be a lot
friendlier towards people who feel that the realities of spam are forcing
them into doing port blocking if they'd quit trying to misrepresent it as
a "feature."
--
Russ Allbery ([EMAIL PROTECTED]) <URL:http://www.eyrie.org/~eagle/>
Racer X <[EMAIL PROTECTED]> writes:
>> Don't fool yourself. The benefit to the customer in blocking port 25
>> outbound is basically nonexistent; it's entirely about administrative
>> resources devoted to keeping one's site from abusing the Internet. It
>> may be necessary, but you can't sell it as a feature.
> Methinks you've never actually worked in this business. Perhaps you
> can't "sell" the feature, no. But it makes the business more efficient
> and competitive by taking better advantage of scarce resources (and yes,
> resources are quite scarce in this industry). This is a Good Thing for
> everyone involved.
But blocking 25 is still not a feature. Nor is it a benefit to the
customer. You're arguing that it allows you to spend time providing other
benefits to your customer. Fine. *Those* are the benefits to your
customers, not the port blocking. And the hard reality of the situation
is that that is neither your customer's problem nor *should* it be your
customer's problem. The network *they* see is less available due to port
blocking, and no matter how many other nice features you can then provide,
it's still a reduction in service.
If it's a trade-off, fine. Present it as a trade-off. Not a feature.
It's a net reduction in service that you have to do because you don't have
enough time and people to do something better.
I'm not *arguing* with that, for heaven's sake. Don't you think I know
the sort of shoestring budgets, particularly in terms of staff time, that
ISPs run on? Read my messages. You'll find that I have not *once* said
that ISPs should not be doing this. I've been saying that it's a damn
shame and that there are better solutions that for one reason or another
aren't feasible for most ISPs. I *know* why they're not feasible. I'm
not claiming you're all lazy bastards or something. You literally don't
have enough money or time or legal support to Fix things and this is the
next best thing. It's a nice stretch of bathwater to throw out.
What makes me mad is when people try to claim that a reduction in service
that prevents people from doing things they want to do is a "feature" and
that they shouldn't be trying to do those things in the first place. This
is just newspeak, and I don't have a lot of patience for it.
--
Russ Allbery ([EMAIL PROTECTED]) <URL:http://www.eyrie.org/~eagle/>
>> Wrong. It simply requires you to use Radius and network equipment
that
>> allows you to send back filters in your Radius authentication.
>
>Good, I'm glad to hear that it's improved. (It certainly used to be the
>case that this was hard.) So how many ISPs are going to be willing to
do
>this? The cost that I was talking about is not only programming effort
>(thankfully apparently not an issue) but also administrative overhead.
>(See below.)
FYI, it's fairly straight-forward if you use a halfway-decent Radius
server (that is, not stock Livingston or Ascend) and a backend database
for accounting. We use Radiator, a Radius server written in Perl, and
Microsoft SQL 6.5.
"Administrative overhead" is not a valid point. Any ISP with more than a
handful of accounts will have different types of accounts they sell.
Static IP, ISDN, POP only, hourly rates vs. fixed rates... Adding a rate
class for "relay permitted" is no more bother than any of these other
accounts.
>No, I disagree, because any measure that you use to prevent the crap
from
>going out in the first place *will* result in loss of legitimate mail.
>This is the inherent problem with spam filtering, and is something that
>Dan's been rightfully pointing out on this list for a while. I *do* do
>spam filtering, but solely because there's currently no better
>alternative.
Spam filtering may well result in the loss of legitimate email. Blocking
outbound SMTP connections will not, as the mail will never be sent in the
first place. The sender is clearly aware of the fact that his mail did
not go out. This is very different from seeing mail acknowledged by the
remote server and then having it mysteriously disappear due to a spam
filter.
Let's keep these two techniques distinct. I am pretty opposed to doing
any kind of filtering after a message is received, but I'm not so opposed
to refusing connections or sending back an error code to mailservers I
don't like.
>The only *real* solution is to provide sufficient economic or legal
>disincentive (because that's the only thing people actually listen to)
to
>stop spamming in the first place. Cleanup charges, laws that allow
people
>to collect damages... that's what's going to make it go away. But in a
>world where ISPs routinely give out free trial accounts and certain
large
>ISPs refuse as a matter of policy to even check credit card numbers to
see
>if they belong to people who were previously kicked off for spamming,
>trying to do anything *real* about spam is almost a lost cause.
ISP's don't give out free accounts as a matter of policy; they do it
because customers demand it. To be competitive in our marketplace, we
HAVE to let customers give our basic service a trial before they commit
to it. This is something that a large portion of our customers have
demanded before purchasing from us. If we refuse a free trial they will
go to someone who will give them one.
>If you want to turn on port 25 for certain customers on a customer-by-
>customer basis, you have to implement some sort of tracking for those
>people, and a procedure for them to get approved, and....
See above. This is not a major consideration assuming you already have a
generic billing/accounting/tracking procedure for other types of
accounts.
>Like I said. And there are a few people who just want to be in control
of
>their own mail. I know I would. I know lots of other people feel the
>same way. You may be a great, well-run, reliable outfit, but the fact
>remains that computers fail and things go wrong, often at the *remote*
>side, and unless you're running your own outgoing mail, finding out
about
>it is a crap shoot.
If you're purchasing service from us, that's an implicit assumption that
we provide some sort of reliable service. Perhaps it's not guaranteed or
insured, but you can assume that either your message will go through or
that it will be returned to you with some sort of error code.
If you DON'T trust us to handle mail correctly, then how do you trust us
to handle your network connectivity correctly? I realize the two things
are different, but if you trust us to give you an IP address when you
want it then it seems you should trust us to send your mail for you.
If this isn't the case, you can lease a line from a backbone provider and
do whatever you want. We make no bones about the fact that we are not a
backbone.
>I'm sorry, but this is simply not true. Less is not more. You're
>providing less service. There's no way to get around that. I'd be a
lot
>friendlier towards people who feel that the realities of spam are
forcing
>them into doing port blocking if they'd quit trying to misrepresent it
as
>a "feature."
"Less service" to whom? Because of the time we saved tracking down spam,
we were able to bring up a chat server, which our research showed was
much more in demand than being able to send outgoing email directly.
It's a trade-off, sure, but we've made more of our customers happy with
the trade-off. I don't see how an ISP can operate any other way, and I
don't see how it's providing less service.
shag
>But blocking 25 is still not a feature. Nor is it a benefit to the
>customer. You're arguing that it allows you to spend time providing
other
>benefits to your customer. Fine. *Those* are the benefits to your
>customers, not the port blocking. And the hard reality of the situation
>is that that is neither your customer's problem nor *should* it be your
>customer's problem. The network *they* see is less available due to
port
>blocking, and no matter how many other nice features you can then
provide,
>it's still a reduction in service.
As I mentioned before, it's not a problem for over 99% of our customers
because it's not a need. You are implying that we are providing less
service, merely because we only offer what people need as opposing to
offering everything we possibly can.
>If it's a trade-off, fine. Present it as a trade-off. Not a feature.
>It's a net reduction in service that you have to do because you don't
have
>enough time and people to do something better.
It is not a "net" reduction in service, because we've taken the time
savings and put them back into either bringing up some other service or
making some other service better. It is therefore a "net" increase in
the level of service provided.
>I'm not *arguing* with that, for heaven's sake. Don't you think I know
>the sort of shoestring budgets, particularly in terms of staff time,
that
>ISPs run on? Read my messages. You'll find that I have not *once* said
>that ISPs should not be doing this. I've been saying that it's a damn
>shame and that there are better solutions that for one reason or another
>aren't feasible for most ISPs. I *know* why they're not feasible. I'm
>not claiming you're all lazy bastards or something. You literally don't
>have enough money or time or legal support to Fix things and this is the
>next best thing. It's a nice stretch of bathwater to throw out.
Okay, well, we all KNOW that it's a shame to have to do this. It's a
shame that we need passwords, and session limits, and idle timers, and...
But the fact of the matter is that we NEED a lot of this stuff, and that
the reasons WHY they suck really aren't relevant when compared to the
reasons why we need them.
We know why we do the things we do. We don't have to like them, and
we're always looking for better mousetraps, but for now, we do have to
take certain measures. As such, I don't see your point in complaining if
you aren't going to offer some other possible solution. Whether or not
the solutions are feasible depends on the ISP evaluating them, so don't
assume that your proposed solutions are invalid or unworkable.
>What makes me mad is when people try to claim that a reduction in
service
>that prevents people from doing things they want to do is a "feature"
and
>that they shouldn't be trying to do those things in the first place.
This
>is just newspeak, and I don't have a lot of patience for it.
This is a trade-off, one that has benefitted us enormously while costing
us relatively little. It is something we can pass on to our customers in
the form of cost savings or additional services. If you can't call this
a "feature," at least don't call it a "reduction in service."
shag
On 19 Jan 1999, Russ Allbery wrote:
> But in a world where ISPs routinely give out free trial accounts and
> certain large ISPs refuse as a matter of policy to even check credit
> card numbers to see if they belong to people who were previously
> kicked off for spamming, trying to do anything *real* about spam is
> almost a lost cause.
Complain loudly about EVERY SINGLE piece of spam you receive.
They will change their mind. Sooner or later. :)
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"NSA GCHQ KGB CIA nuclear conspiration war weapon spy agent... Hi Echelon!"
On Tue, 19 Jan 1999, Racer X wrote:
> >Don't fool yourself. The benefit to the customer in blocking port 25
> >outbound is basically nonexistent; it's entirely about administrative
> >resources devoted to keeping one's site from abusing the Internet. It
> may
> >be necessary, but you can't sell it as a feature.
>
> Methinks you've never actually worked in this business. Perhaps you
> can't "sell" the feature, no. But it makes the business more efficient
> and competitive by taking better advantage of scarce resources (and yes,
> resources are quite scarce in this industry). This is a Good Thing for
> everyone involved.
Who are u to decide what's best for others? U may certainly know what's
best for you, but please don't decide what is best for others. It seems u
have the "i know best" attitude. As your client, i would simply go away,
and turn to people who let other people decide what's best for them.
--
Tiago Pascoal ([EMAIL PROTECTED]) FAX : +351-1-7273394
Politicamente incorrecto, e membro (nao muito) proeminente da geracao rasca.
On Tue, 19 Jan 1999, Mark Delany wrote:
> Then what will you match on? The content? How much code does it take to
> randomize the content?
You (as a spammer) can't randomize the contents beyond the point where an
average reader would stop being able to understand it.
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"NSA GCHQ KGB CIA nuclear conspiration war weapon spy agent... Hi Echelon!"
At 02:05 PM 1/19/99 +0100, Pavel Kankovsky wrote:
>On Tue, 19 Jan 1999, Mark Delany wrote:
>
>> Then what will you match on? The content? How much code does it take to
>> randomize the content?
>
>You (as a spammer) can't randomize the contents beyond the point where an
>average reader would stop being able to understand it.
Of course, but what a human can understand and what a pattern matcher can
recognize are not particularly related in any way.
Regards.
On Mon, 18 Jan 1999, Sam wrote:
> That's some Pine 4 gibberish. You can get rid of it by going into setup,
> and checking off "quell-folder-internal-msg".
>
> This message will actually stay there, but, if something gets rid of it,
> it won't come back.
Would you happen to know how to make that setting global so that all
users get it by default?
On Tue, 19 Jan 1999, Stanley Horwitz wrote:
> On Mon, 18 Jan 1999, Sam wrote:
> > That's some Pine 4 gibberish. You can get rid of it by going into setup,
> > and checking off "quell-folder-internal-msg".
> >
> > This message will actually stay there, but, if something gets rid of it,
> > it won't come back.
>
> Would you happen to know how to make that setting global so that all
> users get it by default?
Figure out where your global pine.conf is. It can be /etc/pine.conf,
/usr/lib/pine.conf, or /usr/local/lib/pine.conf. Find it. Then, enable
this feature for your Pine account, look into your .pinerc to figure out
how it's set there, then copy the relevant setting to the global pine.conf
file.
On Tue, 19 Jan 1999, Stanley Horwitz wrote:
> On Mon, 18 Jan 1999, Sam wrote:
> > That's some Pine 4 gibberish. You can get rid of it by going into setup,
> > and checking off "quell-folder-internal-msg".
> >
> > This message will actually stay there, but, if something gets rid of it,
> > it won't come back.
>
> Would you happen to know how to make that setting global so that all
> users get it by default?
Make sure this:
no-quell-folder-internal-msg
isn't in the global pine.conf. The location of pine.conf varies on the
OS. FreeBSD puts it in /usr/local/etc. Strangely, it's assumed by pine
that this 'feature' would be normally off, so to turn it on you have to
tell it not to not do it.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: [EMAIL PROTECTED] flame-mail: /dev/null
# include <std/disclaimers.h> TEAM-OS2
Online Searchable Campground Listings http://www.camping-usa.com
"There is no outfit less entitled to lecture me about bloat
than the federal government" -- Tony Snow
==========================================================================
Hi Guys (and Gals),
I could really do with some help at the moment. I am trying to configure
email for 5,000 users using Linux on Intel systems.
I don't know how well qmail (or the equipment) will scale so any
reccommendations for optimal performance will be appreciated.
Should I be using a seperate machine for POP3 and outgoing SMTP?
Should I use a db for usernames and passwords rather than looking them up in
a 5,000 lines long /etc/passwd file?
How much disk space is it advisable to make available to 5,000 users? What
steps can I take to enforce this? How should the disks/partitions be best
arranged?
Any advice on mail operation at these levels would be greatly appreciated?
Have a Good '99.
Andy
[EMAIL PROTECTED]
On Tue, 19 Jan 1999, Thomas Andrews wrote:
> Russell Nelson wrote:
> >
> > Sounds like somebody is trying to parse the RFC822 headers again (but
> > not clear who that is). This is not right. Once you've got an
> > envelope address, you preserve it forever. Is fetchmail parsing the
> > message? How are you getting the recipient information when the mail
> > is pulled from your POP server?
> >
>
> All I want to do is find out if the originator of the message is local.
You might find my fromdomain perl script useful, though this wasn't what I
wrote it for. It is called by condredirect like:
|condredirect some-other@address ./bin/fromdomain this.domain \
that.domain 123.234.
(all on one line; remove the "\" and join)
That particular invocation will look through the Received headers and will
trigger condredirect if-and-only-if *all* the Received headers say the
message was received by and from one of: this.domain, that.domain or IP
addresses in the network 123.234.0.0.
see http://silverlock.dgim.crc.ca/~terskine/qmail/fromdomain for the
script.
[snip]
--
"Life is much too important to be taken seriously."
Thomas Erskine <[EMAIL PROTECTED]> (613) 998-2836
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> The problem comes when an email is addressed to _two_ or more people.
> One of those people is local, but more often than not the other(s) are
> not. Qmail delivers a copy to the local address, and another copy into
> the outgoing ppp maildir for each non-local addressee ....
This seems to be a problem with your fetchmail configuration. Are you using
the "envelope" option or are you just letting fetchmail parse the various
"to:" and "delivered" fields?
Even in this last case you shouldn't see this behavior (fetchmail should match
the name *and* the domain to build a list of local recipients) but you are
going to miss messages if the original recipient was hidden (either in the
"bcc" or through a mailing list).
If your provider is using qmail you should use "envelope Delivered-To" and
everything will work reliably (even with multiple recipients since each one
will have a copy with the correct "Delivered-To" header).
Check also the "qvirtual" option.
- --
Luca Olivetti | Tarifa Plana ya! http://tarifaplana.home.ml.org/
http://www.luca.ddns.org/ | FAQ http://www.luca.ddns.org/ptp-faq.html
- ----------------------------------------------------------------------------
UNETE A LA ASOCIACION DE INTERNAUTAS: HTTP://WWW.INTERNAUTAS.ORG
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE2pML9CQPXTRx9NmQRAhqEAKDYDQuj5ns3qlFDkQGLFCv9EG0FuACfUF8g
CIanFoBu1pKGz9PewqhIW34=
=HMOB
-----END PGP SIGNATURE-----
Peter van Dijk wrote:
> Well, make sure a posting from [EMAIL PROTECTED] (me) then gets approved
> automatically since [EMAIL PROTECTED] is on the list. I know that
> a few subscribers use this method to filter out mail. Can be done automatically
> I guess.
Yes it's easily done in ezmlm (of course!), however I think Vern was proposing he
(or whoever) would only not approve blatant spam, other stuff would go through..
I'd like to second the motion, however it's DJB's list and I think he's more
interested suing the bastards rather than jumping through hoops trying to delete
their mail.
Regards,
--Steve
VERY weird.. why do I get this bounce?
----- Forwarded message from [EMAIL PROTECTED] -----
Return-Path: <>
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 2778 invoked from network); 19 Jan 1999 17:46:12 -0000
Received: from zopie.attic.vuurwerk.nl ([EMAIL PROTECTED])
by koek.attic.vuurwerk.nl with QMTP; 19 Jan 1999 17:46:12 -0000
Received: (qmail 16451 invoked by uid 501); 19 Jan 1999 17:45:18 -0000
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 16448 invoked from network); 19 Jan 1999 17:45:14 -0000
Received: from h226.p060.iij4u.or.jp (HELO rr.iij4u.or.jp) (210.130.60.226)
by zolder.cx with SMTP; 19 Jan 1999 17:45:14 -0000
Received: (qmail 38530 invoked for bounce); 20 Jan 1999 02:44:44 +0900
Date: 20 Jan 1999 02:44:44 +0900
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: failure notice
Hi. This is the qmail-send program at rr.iij4u.or.jp.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<sada@localhost>:
Sorry, I couldn't find any host named localhost. (#5.1.2)
--- Below this line is a copy of the message.
Return-Path: <[EMAIL PROTECTED]>
Received: (qmail 38528 invoked from network); 20 Jan 1999 02:44:40 +0900
Received: from localhost (127.0.0.1)
by localhost with SMTP; 20 Jan 1999 02:44:40 +0900
Received: from rr.iij4u.or.jp
by localhost with POP3 (fetchmail-4.7.0)
for sada@localhost (single-drop); Tue, 19 Jan 1999 17:44:40 +0000 (UTC)
Received: from mfi01.iij.ad.jp ([EMAIL PROTECTED] [202.232.2.116])
by rr.iij4u.or.jp (8.8.8+2.2IIJ/4U1.1) with ESMTP id XAA15723
for <[EMAIL PROTECTED]>; Fri, 15 Jan 1999 23:19:31 +0900 (JST)
Received: from twn002.e-mail.ne.jp (twn002.e-mail.ne.jp [210.155.38.2])
by mfi01.iij.ad.jp (8.8.8/MFI1.2) with SMTP id XAA26307
for <[EMAIL PROTECTED]>; Fri, 15 Jan 1999 23:19:30 +0900 (JST)
Received: (qmail 1473 invoked from network); 15 Jan 1999 23:17:15 +0900
Received: from twn020.e-mail.ne.jp (210.155.38.20)
by twn002.e-mail.ne.jp with SMTP; 15 Jan 1999 23:17:15 +0900
Received: from twn002.e-mail.ne.jp ([210.155.38.2]) by twn020.e-mail.ne.jp
(post.office MTA v2.0 0813 ID# 0100057-17656) with SMTP id AAA200
for <[EMAIL PROTECTED]>; Fri, 15 Jan 1999 23:19:43 +0900
Received: (qmail 1470 invoked from network); 15 Jan 1999 23:17:13 +0900
Received: from qmail.jp.qmail.org (131.112.32.189)
by twn002.e-mail.ne.jp with SMTP; 15 Jan 1999 23:17:13 +0900
Received: (qmail 23627 invoked by alias); 15 Jan 1999 14:19:28 -0000
Delivered-To: mailing list [EMAIL PROTECTED]
Received: (qmail 23621 invoked from network); 15 Jan 1999 14:19:27 -0000
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
Delivered-To: mailing list [EMAIL PROTECTED]
Date: Fri, 15 Jan 1999 15:18:55 +0100
From: Peter van Dijk <[EMAIL PROTECTED]>
To: "djb's qmail list" <[EMAIL PROTECTED]>
Subject: Re: qmtp
Message-ID: <[EMAIL PROTECTED]>
Mail-Followup-To: djb's qmail list <[EMAIL PROTECTED]>
References: <076b01be4033$580c8d80$1d01a8c0@fishtank>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95i
In-Reply-To: <076b01be4033$580c8d80$1d01a8c0@fishtank>; from Adam D. McKenna on Thu,
Jan 14, 1999 at 10:01:26PM -0500
X-UIDL: 733cc8b5b382c777dce9a135ba08324c
On Thu, Jan 14, 1999 at 10:01:26PM -0500, Adam D. McKenna wrote:
> er, why not just make a new command? screw the rfc's!!! :)
>
> 220 flounder.net ESMTP
> qmtp
> 250 qmtp mode enabled
> [etc..]
I have a weird feeling by now you've already wasted a lot of latency. Connect,
wait for 220 [not necessary], say qmtp, wait for 250, do qmtp. Unless the 250
doesn't come, in which case you'll start to talk SMTP.
Latency is created. Time is wasted. Strangers will laugh at you.
Greetz, Peter.
--
<squeezer> AND I AM GONNA KILL MIKE | Peter van Dijk
<squeezer> hardbeat, als je nog nuchter bent: | [EMAIL PROTECTED]
<squeezer> @date = localtime(time); | realtime security d00d
<squeezer> $date[5] += 2000 if ($date[5] < 37); |
<squeezer> $date[5] += 1900 if ($date[5] < 99); | * blah *
----- End forwarded message -----
Greetz, Peter.
--
<squeezer> AND I AM GONNA KILL MIKE | Peter van Dijk
<squeezer> hardbeat, als je nog nuchter bent: | [EMAIL PROTECTED]
<squeezer> @date = localtime(time); | realtime security d00d
<squeezer> $date[5] += 2000 if ($date[5] < 37); |
<squeezer> $date[5] += 1900 if ($date[5] < 99); | * blah *
Am 19. Jan 1999, um 18:48:11 schrieb Peter van Dijk:
> VERY weird.. why do I get this bounce?
>
[...]
> Return-Path: <[EMAIL PROTECTED]>
> Received: (qmail 38528 invoked from network); 20 Jan 1999 02:44:40 +0900
> Received: from localhost (127.0.0.1)
> by localhost with SMTP; 20 Jan 1999 02:44:40 +0900
> Received: from rr.iij4u.or.jp
> by localhost with POP3 (fetchmail-4.7.0)
> for sada@localhost (single-drop); Tue, 19 Jan 1999 17:44:40 +0000 (UTC)
[...]
sada obviously uses fetchmail get his mail from a pop account, which then
injects it into the local QMail system (using SMTP), to sada@localhost.
Unfortunately (due to a configuration error), localhost is not in his locals
file, and also localhost is usually not set up in the DNS system. QMail
doesnt consult /etc/hosts - hence theres a configuration error and the mail
is returned.
That you get the bounce... Hm.. During the POP fetch process, the envelope
address usually get lost, I assume.. It could be argued what fetchmail should
insert as envelope-from when it delivers the mail locally, but it seems like
its doing a guess...
Mario
--
Mario Lorenz Internet: <[EMAIL PROTECTED]>
Ham Radio: DL5MLO@OK0PKL.#BOH.CZE.EU
"I hear that if you play the NT 4.0 CD backwards, you get a Satanic message!"
"That's nothing. If you play it forward, it installs NT 4.0!"
Peter van Dijk writes:
> VERY weird.. why do I get this bounce?
You're seeing the combination of two problems: an RFC 1123 violation in
sendmail and a shortsighted design decision in fetchmail.
Background: If an MTA can't deliver a message, it sends a bounce back to
the message's return path. Mailing lists set the return path to a
mailing list manager who can deal with subscriber delivery failures.
sendmail can be, and often is, configured to throw away the return path
when it stores a message in a mailbox. This violates RFC 1123, section
5.2.8. Correcting this behavior means changing one flag in the Mlocal
line in sendmail.cf.
fetchmail retrieves messages from a mailbox. It incorrectly copies the
>From line to the return path. The result is exactly what you're seeing:
subsequent bounces of mailing-list messages are sent to the wrong place.
We'll be stuck with this problem for a long time.
fetchmail _should have_ required a return path from sendmail. But then
Eric Raymond would have had to deal with complaints from users whose
ISPs don't provide the return path. ``Why don't you just copy the From
line? I'm not going to bounce things anyway!''
Probably Eric Raymond considers this to be a good tradeoff. He's saved
time and gained users. Why should he care if you suffer?
---Dan
Hi
Does anyone know how to configure news on a red hat 5.1 server? Is this a
qmail thing or something separate. Please let me know.
For all of you who are beginning with qmail, check out my help pages that
this mailing list has helped me with. http://qmail.n2-2000.com
Brock Eastman
"Brock Eastman" <[EMAIL PROTECTED]> writes:
> Does anyone know how to configure news on a red hat 5.1 server? Is this a
> qmail thing or something separate. Please let me know.
*Quite* seperate. Read the INN documentation.
--
Lars Balker Rasmussen, Software Engineer, Mjolner Informatics ApS
[EMAIL PROTECTED]
"D. J. Bernstein" <[EMAIL PROTECTED]> wrote:
>Dave Sill writes:
>> sendmail-send-it looks for a list of undeliverable recipients in the
>> combined stdout/stderr from sendmail.
>
>That will catch most errors, with either sendmail or qmail, but it's not
>reliable. Many current operating systems will silently kill processes
>under various circumstances. The only sure bet is the exit code.
Good point. I hadn't thought of that. Luckily, at least the XEmacs
version is (soon to be) truly fixed:
http://www.xemacs.org/list-archives/xemacs-patches/9811/msg00000.html
-Dave
Discussion of pipelining on the Postfix list got me thinking. I know
qmail supports pipelining on the SMTP server side because qmail-smtpd
says so in response to HELO/EHLO. But does it support it on the client
side? I don't see any reference to pipelining in qmail-remote.c.
-Dave
D. J. Bernstein writes:
>Craig Burley writes:
>> That is, I'd like outgoing email to be from `[EMAIL PROTECTED]', or
>> `[EMAIL PROTECTED]', or whatever (jcb-sc.com being my domain name).
>
>ftp://koobera.math.uic.edu/www/qmail/faq/appearance.html#user-masquerading
That's helped some. I've made the specified changes (defining MAILHOST and
QMAILINJECT, but not MAILUSER, since I want to leave that be) to the
/etc/profile on my system. It causes the newly sent "From:" addresses
to be "[EMAIL PROTECTED]".
However, maildirsmtp still reports "451 Domain must resolve" errors
on new messages, so my ISP is still rejecting them.
I've hand-edited a pending (rejected by maildirsmtp) email so that
the "Return-Path:" address is "[EMAIL PROTECTED]" instead of
"[EMAIL PROTECTED]".
That makes the problem go away. (The edited file is successfully
uploaded by maildirsmtp, and deleted; the backup file, named with
a postfix `~' by Emacs, is unsuccessfully uploaded just as before.
I hand-deleted it.)
I can't see, offhand, a way to get these "Return-Path:" addresses
to read "[EMAIL PROTECTED]". I'm not even sure it's the right
thing to do. (I tried QMAILINJECT=sf, no go, and I'm not really
sure enough about what VERPs are all about to try QMAILINJECT=rf,
which I've seen recommended somewhere but can't recall where.)
Should I contact my ISP and ask them to somehow improve their checking
of incoming SMTP connections so they permit "Return-Path:" to contain
addresses like "[EMAIL PROTECTED]" when they have already allowed
"MAIL FROM: whatever@domain", or something like that?
Any other suggestions?
>Presumably your ISP makes *@jcb-sc.com available to you through POP; you
>can download it using fetchmail.
Yes, I believe so, and I've just downloaded fetchmail and its FAQ. I'll
start wrestling with it after I get outgoing email working (automatically,
that is, without my hand-editing the "Return-Path:" headers).
Another question:
Assuming I get through all this and successfully configure my email
for my LAN+ISP setup, I'd be willing to document what I've done, and
the reasoning behind it, for future newbie users (like myself). Is
there interest in such documentation, e.g. to be included with
future qmail packages (and documentation)? If so, what format would be
best for the documentation (I'm pretty comfortable with texinfo
these days)?
tq vm, (burley)
On Tue, 19 Jan 1999, Craig Burley wrote:
> That's helped some. I've made the specified changes (defining MAILHOST and
> QMAILINJECT, but not MAILUSER, since I want to leave that be) to the
> /etc/profile on my system. It causes the newly sent "From:" addresses
> to be "[EMAIL PROTECTED]".
>
> However, maildirsmtp still reports "451 Domain must resolve" errors
> on new messages, so my ISP is still rejecting them.
Now, set QMAILSHOST to fix that. Errr... I think it's QMAILSHOST.
Why don't you read the manual page for qmail-inject, and look at all the
environment variables that are used for rewriting addresses.
host name
Hello qmail world !
This is the message i'am getting sending mail from our server :
"Hi. This is the qmail-send program at alphainter.net.
I'm afraid I wasn't able to deliver your message to the following
addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<[EMAIL PROTECTED]>:
Connected to 212.244.81.20 but sender was rejected.
Remote host said: 451 <[EMAIL PROTECTED]>... unresolvable relay
host name [209.167.138.195]; check your reverse-IP configuration.
I'm not going to try again; this message has been in the queue too long.
same message send from another domain is going through ...
Any ideas why is so nasty ?
regards and thanks in advance
On 19 Jan 1999 [EMAIL PROTECTED] wrote:
> <[EMAIL PROTECTED]>:
> Connected to 212.244.81.20 but sender was rejected.
> Remote host said: 451 <[EMAIL PROTECTED]>... unresolvable relay
> host name [209.167.138.195]; check your reverse-IP configuration.
> I'm not going to try again; this message has been in the queue too long.
>
>
> same message send from another domain is going through ...
>
> Any ideas why is so nasty ?
Because your reverse DNS is broken. The error message seems pretty clear
to me, what exactly don't you understand? The IP address of your mail
server, 209.167.138.195, does not have a valid PTR record in DNS.
A lot of folks, including myself, refuse mail from hosts unless the IP
address can be resolved backwards and forwards. There's a definite
correlation between sites with mismanaged DNS, and mismanaged mail relays
(open, anonymous, etc...) Although mail from well-administered sites also
occasionally gets blocked, the overall benefit-to-false-positive ratio is
quite good.
hi,
[EMAIL PROTECTED] schrieb:
> Remote host said: 451 <[EMAIL PROTECTED]>... unresolvable relay
> host name [209.167.138.195]; check your reverse-IP configuration.
> I'm not going to try again; this message has been in the queue too long.
Your reverse-lookup is not installed:
mehl:/var/qmail # dig @141.1.1.1 MX alphainter.net
;; ANSWER SECTION:
alphainter.net. 12H IN MX 20 mail.uunet.ca.
alphainter.net. 12H IN MX 10 mail.alphainter.net.
;; ADDITIONAL SECTION:
mail.alphainter.net. 12H IN A 209.167.138.195
mehl:/var/qmail # nslookup 209.167.138.195 141.1.1.1
Server: ecrc.de
Address: 141.1.1.1
*** ecrc.de can't find 209.167.138.195: Non-existent host/domain
I'm sure there is somewhere a RFC. The qmailprogramme on the other site
doesn't only look at the Name-IP of our site and verify's it - it looks at
Name-IP, too. You (or your Provider) didn't install the reverse.lookup.
This is a good method of stopping other people to spoof IP's.
I want to install that somewhen, too :-)
by,
--
sincerely,
Michael Bracker eMail: [EMAIL PROTECTED]
0xF07576AF * 4BCE DB9C BD6D 6D91 3C14 1D7E 757A 9055
SMTP conversation:
----------
> MAIL FROM:<verptest-@host1-@[]>
> 250 ok
< RCPT TO:<user@host2>
> 250 ok
< DATA
> 354 go ahead
< Subject: VERP test
<
< .
> 250 ok 916770426 qp 1077
----------
Delivered message:
----------
Return-Path: <verptest-user=host2@host1>
Delivered-To: user@host2
Received: (qmail 16270 invoked from network); 19 Jan 1999 18:27:09 -0000
Received: from host1 (xx.xx.xx.xx)
by host2 with SMTP; 19 Jan 1999 18:27:09 -0000
Subject: VERP test
----------
Conclusion: qmail does not need to send multiple copies of VERPed message
if the destination SMTP server runs qmail (or any other VERP-enabled MTA
if such MTA existed).
Of course, it needs to figure out whether a particular MTA supports VERP.
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"NSA GCHQ KGB CIA nuclear conspiration war weapon spy agent... Hi Echelon!"
This sounds like a job for an ESMTP option.
At 08:28 PM 1/19/99 +0100, Pavel Kankovsky wrote:
>SMTP conversation:
>----------
>> MAIL FROM:<verptest-@host1-@[]>
>> 250 ok
>< RCPT TO:<user@host2>
>> 250 ok
>< DATA
>> 354 go ahead
>< Subject: VERP test
><
>< .
>> 250 ok 916770426 qp 1077
>----------
>
>Delivered message:
>----------
>Return-Path: <verptest-user=host2@host1>
>Delivered-To: user@host2
>Received: (qmail 16270 invoked from network); 19 Jan 1999 18:27:09 -0000
>Received: from host1 (xx.xx.xx.xx)
> by host2 with SMTP; 19 Jan 1999 18:27:09 -0000
>Subject: VERP test
>----------
>
>Conclusion: qmail does not need to send multiple copies of VERPed message
>if the destination SMTP server runs qmail (or any other VERP-enabled MTA
>if such MTA existed).
>
>Of course, it needs to figure out whether a particular MTA supports VERP.
>
>--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
>"NSA GCHQ KGB CIA nuclear conspiration war weapon spy agent... Hi Echelon!"
>
>
>
On Wed, 20 Jan 1999, Mark Delany wrote:
> This sounds like a job for an ESMTP option.
It seems like a logical solution. Unfortunately, it is qmail-send that
needs to know it can group deliveries, not qmail-remote.
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"NSA GCHQ KGB CIA nuclear conspiration war weapon spy agent... Hi Echelon!"
Okay, VERP has solved the bounce problem. Now we need VERB (Variable
Envelope Recipient in Body) to solve the unsubscribe problem.
Basically, we need qmail-remote to merge the envelope recipient into
the message somewhere. The problem, of course, is *where* to insert
it. What I did for one customer is to insert it whenever a certain
magical character sequence was seen. This worked for them because
they could ensure that that magical sequence only appeared where they
wanted it. So how do we ensure that out-of-band data (the insertion
point marker) doesn't get confused with in-band data (the email
message itself).
In case it's not obvious what I'm getting at, imagine if you could say:
--
To unsubscribe, send mail to [EMAIL PROTECTED]
instead of the usual:
--
To unsubscribe, send mail to [EMAIL PROTECTED]
--
-russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson
Crynwr supports Open Source(tm) Software| PGPok | There is good evidence
521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
Russell Nelson wrote:
> In case it's not obvious what I'm getting at, imagine if you could say:
> To unsubscribe, send mail to [EMAIL PROTECTED]
> instead of the usual:
> To unsubscribe, send mail to [EMAIL PROTECTED]
BWT I encountered some problems with remote hosts limiting the sender
address to 62 characters, which has been exceeded for my env.sender
address was already "long", and so was the remote address. What you
propose could help me out.
So, what about a X-Header holding the data? This would require the
user's mailing agent to return that header, too.
But anyway: your "new" unsubscription mechanism only works if the whole
message (containing the "out of band" data) would be returned.
A blank message to "[EMAIL PROTECTED]" would not work if
the envelope sender address is different from the address stored in the
subscriber list. (Besides, this seems to involve some list manager
issues, too).
Bounces generated by some MTA would be required to include the out of
band data too, and I think the unreliability of "foreign" MTAs was one
of the reasons why Dan invented VERPs, for they encapsulate the bouncing
address in the recipient address, which is guaranteed to be returned ;-)
Ragards,
Matthias
--
w e b f a c t o r y | matthias pigulla
www.webfactory.de [EMAIL PROTECTED]
On Tue 1999-01-19 (20:11), Russell Nelson wrote:
> Okay, VERP has solved the bounce problem. Now we need VERB (Variable
> Envelope Recipient in Body) to solve the unsubscribe problem.
> Basically, we need qmail-remote to merge the envelope recipient into
> the message somewhere. The problem, of course, is *where* to insert
> it. What I did for one customer is to insert it whenever a certain
> magical character sequence was seen. This worked for them because
> they could ensure that that magical sequence only appeared where they
> wanted it. So how do we ensure that out-of-band data (the insertion
> point marker) doesn't get confused with in-band data (the email
> message itself).
>
> In case it's not obvious what I'm getting at, imagine if you could say:
> --
> To unsubscribe, send mail to [EMAIL PROTECTED]
>
> instead of the usual:
> --
> To unsubscribe, send mail to [EMAIL PROTECTED]
I asked about something like this on the ezmlm list, because one of our list
admins was having problems with people being subscribed under addresses
different to the address they thought they were subscribed under. (Mostly
Windoze users that didn't read the confirmation message and/or deleted it).
This meant that the list admin had to manually remove users when they
complained of not being able to unsubscribe, usually to the mail list with a
few explecitives attached. Sometimes the admin had to make a guess at what
the subscriber's address was and hope that some innocent bystander didn't get
caught in the crossfire.
Perhaps this rewriting could be restricted to the last line of the message,
and then you could have something like:
To unsubscribe, send mail to:
[email protected]
with qmail-remote rewriting ?USER? and ?HOST?.
But that's not an optimal solution. Are there any characters that are not
allowed in SMTP messages? I thought about from my reading of Dan's web page
LF's can appear in the middle of a message.
- Keith
> -russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson
--
Keith Burdis - MSc (Com Sci) - Rhodes University, South Africa
Email : [EMAIL PROTECTED]
WWW : http://www.rucus.ru.ac.za/~keith/
IRC : Panthras JAPH
"Any technology sufficiently advanced is indistinguishable from a perl script"
Standard disclaimer.
---
On Tue, 19 Jan 1999, Matthias Pigulla wrote:
> BWT I encountered some problems with remote hosts limiting the sender
> address to 62 characters, which has been exceeded for my env.sender
> address was already "long", and so was the remote address. What you
> propose could help me out.
Too bad. They're broken. I'm generally not in favor of crippling
something in order to accomodate someone's broken software.
On 19 Jan 1999, Russell Nelson wrote:
> Okay, VERP has solved the bounce problem. Now we need VERB (Variable
> Envelope Recipient in Body) to solve the unsubscribe problem.
> Basically, we need qmail-remote to merge the envelope recipient into
> the message somewhere. The problem, of course, is *where* to insert
> it. What I did for one customer is to insert it whenever a certain
> magical character sequence was seen. This worked for them because
> they could ensure that that magical sequence only appeared where they
> wanted it. So how do we ensure that out-of-band data (the insertion
> point marker) doesn't get confused with in-band data (the email
> message itself).
I'd say that it should be either a command-line arg for qmail-remote, or
an environment variable. It could be control/remote-verb-cookie, but that
makes it more difficult to have different ones for different lists, e.g.
The only problem with both command-line args and environment variables, is
that I can't see an easy way to hack them in, without significant patches.
The control/remote-verb-cookie method would be a relatively simple patch.
About making sure that it's not confused with actual message data, that's
difficult, because it isn't out-of-band: it's part of the message body.
However, it doesn't have to be easy to type, and since it's not actually
being transferred, just stored locally and then munged, it could include
control-characters. So you could use \000\000VeRbHeRe\000\000, where the
\000's are actual ASCII NULs. This has the "advantage" that people aren't
likely to type the cookie while discussing it on the list. :-)
> In case it's not obvious what I'm getting at, imagine if you could say:
> --
> To unsubscribe, send mail to [EMAIL PROTECTED]
>
> instead of the usual:
> --
> To unsubscribe, send mail to [EMAIL PROTECTED]
>
> --
> -russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson
> Crynwr supports Open Source(tm) Software| PGPok | There is good evidence
> 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the
> Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
>
--
"Life is much too important to be taken seriously."
Thomas Erskine <[EMAIL PROTECTED]> (613) 998-2836
Matthias Pigulla writes:
> But anyway: your "new" unsubscription mechanism only works if the whole
> message (containing the "out of band" data) would be returned.
No, that's not how I expect it would work. The list manager would
append a trailer, and the trailer would have some magic that caused
qmail-remote to merge the envelope recipient in. The user would see
that trailer, fail to be stupid enough to miss it, and cut/paste that
address into a new piece of mail.
> A blank message to "[EMAIL PROTECTED]" would not work if
> the envelope sender address is different from the address stored in the
> subscriber list. (Besides, this seems to involve some list manager
> issues, too).
Right, that's why they would send the mail to the address at the bottom.
For me it would be [EMAIL PROTECTED], and for you
[EMAIL PROTECTED]
--
-russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson
Crynwr supports Open Source(tm) Software| PGPok | There is good evidence
521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
Matthias Pigulla wrote:
> So, what about a X-Header holding the data? This would require the
[snip]
> address in the recipient address, which is guaranteed to be returned ;-)
Sorry, seems as if I misunderstood Russells intention, I thought he
wanted to move VERPs into VERBs. He just want's "individual"
attachments.
IMHO this is a mailing list issue, qmail has no idea of an
"unsubscription address".
Matthias
--
w e b f a c t o r y | matthias pigulla
www.webfactory.de [EMAIL PROTECTED]
On Tue, 19 Jan 1999, Matthias Pigulla wrote:
> Bounces generated by some MTA would be required to include the out of
> band data too, and I think the unreliability of "foreign" MTAs was one
> of the reasons why Dan invented VERPs, for they encapsulate the bouncing
> address in the recipient address, which is guaranteed to be returned ;-)
Unless the other MTA is a SMTP gateway to any of those big name mail
systems sending bounces to From: address. :)
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"NSA GCHQ KGB CIA nuclear conspiration war weapon spy agent... Hi Echelon!"
Russell Nelson wrote:
> No, that's not how I expect it would work. The list manager would
> append a trailer, and the trailer would have some magic that caused
> qmail-remote to merge the envelope recipient in. The user would see
> that trailer, fail to be stupid enough to miss it, and cut/paste that
> address into a new piece of mail.
First, I don't like the idea of having a qmail-remote or qmail-send
rewriting messages being sent for some mailing list purposes. This whole
stuff seems to be mailing-list relevant.
Such changes to qmail modules would blur the nicely fragmented qmail
system. Qmail is intended to deliver mail, not to parse and rewrite it.
Of course, hacking some VERB functions into qmail-send or qmail-remote
would be the easiest thing, but (I repeat myself) would not be a clean
solution.
Maybe one could introduce a new module for such rewriting purposes, that
all data would be fed through. Only... to handle messages efficiently,
it's necessary to keep the "original" (to speak with the words of the
envelopes man page) as long as possible and make "copies" as late as
possible, i.e. in qmail-send <-> qmail-remote. Unfortunately, in this
case the copies will have to be modified.
Regards,
Matthias
--
w e b f a c t o r y | matthias pigulla
www.webfactory.de [EMAIL PROTECTED]
Pavel Kankovsky wrote:
> Conclusion: qmail does not need to send multiple copies of VERPed message
> if the destination SMTP server runs qmail (or any other VERP-enabled MTA
> if such MTA existed).
Without having looked at this closer (I claim to _remember_ from the
source code), I assume the address will be rewritten by qmail-send on
the host receiving the mail, for the rewriting mechanism is triggered by
the -@[] suffix. The message is queued and examined by qmail-send,
wheter it is delivered remotely or locally. But that leads away from the
subject.
There seems to be a parallel to that "qmail wastes bandwith" thread.
Regard the following as a RFC: What optimizations could be done to make
qmail save bandwith by not having multiple connections to remote hosts?
What aspects would have to be paid attention to? What could be done? You
see any problems?
That e.g. means that identical messages to several users at _one_ remote
host could bundled by providing several RCPT TO commands at SMTP level.
No features should become dropped (like VERPs).
Let me start with some things I have in mind (also from what others
wrote on this list!), please contribute...
- identical messages to several users at _one_ remote host can be
bundled by providing several RCPT TO commands at SMTP level, if VERPs
are _not used_.
- if the remote system is running qmail, the above can be done in
connection with VERPs, by providing the "magic" envelope sender address
with a trailing -@[].
- even more messages can be bundled if 'one' remote host is not defined
by the hostname, but smtproutes is checked too. E.g. smtproutes routes
@domaina and @domainb to the same host, so it should be possible to give
both recipient types (@domaina and @domainb) to the smarthost in one
SMTP session.
- I'm not that familiar with such techniques, but would it be possible
for a site to "bundle" several mail machines together, serving under
(virtually) the same hostname -> I think AOL does so, I cannot imagine
they only have one mail server ;-) Now, should all recipients be given
to one of those machines, or should load be spawned over several hosts?
Anyway, could that be decided by the local (sending) host at all?
- Would it be desireable (and I assume it is not) to overlook the queue
of messages to recycle SMTP connections in that way that all mail
(_several different_ messages) for a certain remote host is delivered,
once the connection is established? This seems to require a continuous
overlooking of the queue. (And, on my opinion, is not worth the load. =)
Regards,
Matthias
--
w e b f a c t o r y | matthias pigulla
www.webfactory.de [EMAIL PROTECTED]
Here's a copy of the message I sent to the ezmlm mailing list, and the
detailed reply I got from Fred Lindberg describing why ezmlm can't do the
rewriting and how qmail would have to do it.
- Keith
----- Forwarded message from [EMAIL PROTECTED] -----
Subject: Fwd: Re: Unsubscribe info
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Tue, 19 Jan 1999 21:54:14 -0000
Begin forwarded message:
Original Article: http://www.egroups.com/list/djb-ezmlm/?start=884
On Fri, 9 Oct 1998 12:41:42 +0200, Keith Burdis wrote:
> So (and I finally get to the point), I would like for the unsubscription
> info for each subscriber to appear at the end of each message. eg.
>
> To unsubscribe from this mailing list send a message to:
>
> list-unsubscribe-user=userhost@host
>
> That way it is pretty clear what address they are subscribed under and what
> they have to do to unsubscribe.
Yes, that would be very nice. Unfortunately, ezmlm sends out only one
message per post, _not_ one per subscriber. Thus, this would require
qmail support for VERP expansion and header addition (least unlikely),
VERP expansion in arbitrary header. In the message body is
"impossible", since that might lead to message corruption.
Unfortunately, this would require some major redoing of qmail. At the
moment, qmail-send does the expansion for SENDER (the message incl
headers is not altered), then qmail-lspawn/rspawn pass it on to
qmail-remote/local. In -local there are several places for delivery. In
order to still keep it one message per post in the queue, the new
header/header-expansion would have to be done by qmail-remote/local.
THe other alternative, sending one message per recipient would have a
severe impact on ezmlm efficiency (10k message x 10k recipients = 100 M
queue space) and require a complete redesign of ezmlm to deal with
failures after a subset of messages have been sent. This is
"impossible".
-Sincerely, Fred
(Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
----- End forwarded message -----
--
Keith Burdis - MSc (Com Sci) - Rhodes University, South Africa
Email : [EMAIL PROTECTED]
WWW : http://www.rucus.ru.ac.za/~keith/
IRC : Panthras JAPH
"Any technology sufficiently advanced is indistinguishable from a perl script"
Standard disclaimer.
---
Hi mailinglist,
where can I look up descriptions for error messages qmail logs, e.g. "I
could'nt find any host by that name (#4.1.2)"?
I once found the descriptions in one of the many (Well done, Dan!)
documentation files... but where?
Matthias
--
w e b f a c t o r y | matthias pigulla
www.webfactory.de [EMAIL PROTECTED]
Hi,
I am having a few problems getting qmail-pop3d to time out. I was
wondering if anyone else has had similar problems and could help me out.
Once again, I imagine it is something I have set up wrongly in my qmail
or tcpserver configuration. I have tried setting the tcpserver timeout
to 180 seconds but this does not seem to make a difference in this case.
I have also modified my versions of saferead() and safewrite() both in
qmail-pop3d and qmail-popup to timeout after 300 seconds (Don't tell
Dan!), but again this doesnt seem to have any effect.
Thanks in advance for any help,
Regards,
Richard Aldridge,
Systems Engineer,
Cable Internet.
p.s. Some more info which might help :
Running Slackware 3.5 Kernel 2.0.35
# pstree -ahupl | grep pop
| |-grep(17220) pop
|-tcpserver(13432) -P -H -R 0 pop3 /var/qmail/bin/qmail-popup
tigers.cableinet.net /bin/checkpassword ...
| |-qmail-popup(17158) tigers.cableinet.net /bin/checkpassword
/var/qmail/bin/qmail-pop3d Maildir
| | `-qmail-pop3d(17198,mailuser) Maildir
| |-qmail-popup(20447) tigers.cableinet.net /bin/checkpassword
/var/qmail/bin/qmail-pop3d Maildir
| | `-qmail-pop3d(20490,mailuser) Maildir
| |-qmail-popup(21815) tigers.cableinet.net /bin/checkpassword
/var/qmail/bin/qmail-pop3d Maildir
| | `-qmail-pop3d(21880,mailuser) Maildir
| |-qmail-popup(16778) tigers.cableinet.net /bin/checkpassword
/var/qmail/bin/qmail-pop3d Maildir
| | `-qmail-pop3d(16794,mailuser) Maildir
| `-qmail-popup(19440) tigers.cableinet.net /bin/checkpassword
/var/qmail/bin/qmail-pop3d Maildir
| `-qmail-pop3d(19482,mailuser) Maildir
# strace -p 20490
oldselect(2, NULL, [1], NULL, {241, 120000} <unfinished ...>
# strace -p 20490
oldselect(2, NULL, [1], NULL, {236, 460000} <unfinished ...>
Hello all
Trying to install qmail on a solaris 7 intel box. I have compiled other
programs fine. When I try to install qmail I get the following. I have
taken a look at the archives but not found any answers. Thanks for any help.
Bert Beaudin
chmod 755 makelib
./compile case_diffb.c
./compile case_diffs.c
./compile case_lowerb.c
./compile case_lowers.c
./compile case_starts.c
./makelib case.a case_diffb.o case_diffs.o case_lowerb.o \
case_lowers.o case_starts.o
ar: cannot open case_diffb.o
No such file or directory
ar: cannot open case_diffs.o
No such file or directory
ar: cannot open case_lowerb.o
No such file or directory
ar: cannot open case_lowers.o
No such file or directory
ar: cannot open case_starts.o
No such file or directory
ar: case_diffb.o not found
ar: case_diffs.o not found
ar: case_lowerb.o not found
ar: case_lowers.o not found
ar: case_starts.o not found
make: *** [case.a] Error 5
Try putting /usr/ccs/bin in your path, I don't know if this will fix your
problem but it fixed a lot of compile problems I was having on Solaris.
--Adam
----- Original Message -----
From: Bert Beaudin <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 19, 1999 10:21 PM
Subject: Solaris 7 intel and Qmail install
:Hello all
: Trying to install qmail on a solaris 7 intel box. I have compiled other
:programs fine. When I try to install qmail I get the following. I have
:taken a look at the archives but not found any answers. Thanks for any help.
:
:Bert Beaudin
:
:
:chmod 755 makelib
:./compile case_diffb.c
:./compile case_diffs.c
:./compile case_lowerb.c
:./compile case_lowers.c
:./compile case_starts.c
:./makelib case.a case_diffb.o case_diffs.o case_lowerb.o \
:case_lowers.o case_starts.o
:ar: cannot open case_diffb.o
: No such file or directory
:ar: cannot open case_diffs.o
: No such file or directory
:ar: cannot open case_lowerb.o
: No such file or directory
:ar: cannot open case_lowers.o
: No such file or directory
:ar: cannot open case_starts.o
: No such file or directory
:ar: case_diffb.o not found
:ar: case_diffs.o not found
:ar: case_lowerb.o not found
:ar: case_lowers.o not found
:ar: case_starts.o not found
:make: *** [case.a] Error 5
:
:
:
:
:
