qmail Digest 15 Apr 1999 10:00:01 -0000 Issue 611

Topics (messages 24275 through 24300):

[Q] qmail speed "again"
        24275 by: Keith Burdis <[EMAIL PROTECTED]>

POP security question
        24276 by: xs <[EMAIL PROTECTED]>
        24277 by: "Evan Champion" <[EMAIL PROTECTED]>
        24279 by: Charles Cazabon <[EMAIL PROTECTED]>
        24286 by: "Fred Lindberg" <[EMAIL PROTECTED]>
        24287 by: xs <[EMAIL PROTECTED]>
        24288 by: xs <[EMAIL PROTECTED]>
        24299 by: Joel Eriksson <[EMAIL PROTECTED]>
        24300 by: Peter van Dijk <[EMAIL PROTECTED]>

qmail and juno.com
        24278 by: Peter Green <[EMAIL PROTECTED]>
        24284 by: Dave Sill <[EMAIL PROTECTED]>

FW: Web Interface to Qmail on Linux
        24280 by: Russell Nelson <[EMAIL PROTECTED]>
        24282 by: Andy Walden <[EMAIL PROTECTED]>
        24285 by: "Fred Lindberg" <[EMAIL PROTECTED]>

qmail/ezmlm writing strange envelope From?
        24281 by: Vern Hart <[EMAIL PROTECTED]>

Not checking rcpt properly... again
        24283 by: Juan Carlos Castro y Castro <[EMAIL PROTECTED]>

Qmail and Ldap
        24289 by: "Wil Boucher" <[EMAIL PROTECTED]>

Solaris 7  x86 and number of process limitation
        24290 by: "Bart Grubb" <[EMAIL PROTECTED]>
        24291 by: Mark Delany <[EMAIL PROTECTED]>
        24294 by: Richard Letts <[EMAIL PROTECTED]>
        24295 by: Mark Delany <[EMAIL PROTECTED]>

Inetd refusing connections under RedHat 5.2
        24292 by: Matthew Harrell <[EMAIL PROTECTED]>
        24293 by: Paul Farber <[EMAIL PROTECTED]>
        24296 by: Matthew Harrell <[EMAIL PROTECTED]>

Netscape return receipts. (refused by qmail)
        24297 by: Greg Moeller <[EMAIL PROTECTED]>
        24298 by: Anand Buddhdev <[EMAIL PROTECTED]>

Administrivia:

To subscribe to the digest, e-mail:
        [EMAIL PROTECTED]

To unsubscribe from the digest, e-mail:
        [EMAIL PROTECTED]

To bug my human owner, e-mail:
        [EMAIL PROTECTED]

To post to the list, e-mail:
        [EMAIL PROTECTED]


----------------------------------------------------------------------


On Wed 1999-04-14 (12:18), Silver CHEN wrote:
> Dear Keith:
> 
>   I think you got my point, thanks.
> 
>   My experience on sendmail at this tpoic *is* quite good - sorry, I don't
>   have such experience on qmail yet.
> 
>   My intuition tells me that the first way will be better, since it will send 
>   only one copy of messages on network. If I have a 30KB+ message size, and
>   400K subscribers, the first method 'seems' to be much more efficient than 
>   the second one.
> 
>   However, this is what I 'think' - no real world experience on qmail yet.
> 
>   I'll examine this behavior on qmail soon, the machine is still in the box,
>   I don't have time to open/assamble/install it these days.
> 
>   Our newsletters have 'sponsors', and some information is time-intensive,
>   so my life is harder and harder.... :(
> 
>   Anyway, thanks for any comment on this tpoic.

Please note that I only speculated that sendmail would be faster in this one
particular case. For pretty much any other scenario qmail is significantly
faster. I have noticed that using multiple-rcpt messages to one particular
host appeared to be faster than many single message individual smtp sessions,
but as my fellow list members have pointed out this does not necessarily mean
that this would always be the case.

If you're looking for speed, qmail is definitely the way to go. If all of
your 400K subscribers are on the same remote host then perhaps do some
profiling to see whether or not you'd gain by using multiple rcpt to's.
Otherwise IMHO don't bother. Just use qmail :-)

  - Keith

>   Silver CHEN

-- 
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.
---





i thought about this  one this weekend, if /bin/false is in /etc/shells
and you have ftp enabled, then a user could ftp in a .qmail file that
contains a expect script that runs chsh, and boom, they have a shell. how
to avoid this, options:
a) take /bin/fales and /bin/true out of /etc/shells
b) disable ftp
c) disable chsh and chfn
d) disable perl, expect, tcl, etc..
e) use vpops

lates,
-xs


end 
+-------------------------------------+
|Greg Albrecht  KF4MKT   [EMAIL PROTECTED]|
|Safari Internet   Fort Lauderdale, FL|
|www.safari.net           888-537-9550|
+------L-O-W-E-R--D-O-T--O-R-G--------+

On Wed, 14 Apr 1999, Joe Junkin wrote:

>Hello all,
>When a pop user logs in to check mail, they send their user password in clear
>text over the network. So, a pop user account could be comprimised, and is
>therefore unsecure. On a mail server I administer, I set all of the qmail user
>accounts shell to be /bin/false which disallows a direct login by the user. This
>is fine with me since none of my email accounts will every log in. 
>
>This seems secure, but is it enough? Is there more that one can do to secure pop
>accounts? 
>
>-- 
>Joseph R. Junkin                       Datafree Corporation
>[EMAIL PROTECTED]                        http://www.datacrawler.com
>





> i thought about this  one this weekend, if /bin/false is in /etc/shells
> and you have ftp enabled, then a user could ftp in a .qmail file that
> contains a expect script that runs chsh, and boom, they have a shell. how
> to avoid this, options:

/bin/false should never be in /etc/shells, period.

If one wanted to be paranoid about it, one could specify different passwords
for login vs. POP access by using a custom checkpassword with qmail-pop3d.
One could authenticate against a database, or perhaps against a Kerberos
server with the principal user.pop@domain (which would have a different
password than the principal user@domain).

One could also use the Cyrus IMAP/POP server which has the additional
advantage that one doesn't need users in /etc/passwd to begin with (as long
as one authenticates against Kerberos, or one writes a custom pwcheck daemon
to authenticate against something other than /etc/passwd).  Cyrus can also
support Kerberised POP if the MUA supports it (ie: Eudora) which means
encrypted POP sessions.

Finally, assuming all customers use MUAs that support SSL (ie: Communicator
and Outlook Express) one could wrap the POP server with stunnel and do
encrypted POP sessions.

I described how to get Cyrus' deliver to cooperate with qmail and how to
wrap qmail-pop3d with stunnel a few months ago; one should be able to find
those messages quite easily in the list archives.

Evan






Joe Junkin <[EMAIL PROTECTED]> wrote:
> When a pop user logs in to check mail, they send their user password in clear
> text over the network. So, a pop user account could be comprimised, and is
> therefore unsecure. On a mail server I administer, I set all of the qmail user
> accounts shell to be /bin/false which disallows a direct login by the user. This
> is fine with me since none of my email accounts will every log in. 
> 
> This seems secure, but is it enough? Is there more that one can do to secure pop
> accounts? 

Or you could do what I do -- run an ssh server on the POP server and ssh client on the 
clients.  Have the
clients configured to forward a local port over the encrypted tunnel to the POP port 
on the server -- voila,
instant secure POP with any POP client.  Works well.

Charles
-- 
----------------------------------------------------
Charles Cazabon           <[EMAIL PROTECTED]>
Any opinions expressed are just that -- my opinions.
----------------------------------------------------





On Wed, 14 Apr 1999 08:06:45 -0400 (EDT), xs wrote:

>i thought about this  one this weekend, if /bin/false is in /etc/shells

What about /bin/passwd? Allows people to change password via telnet ...

Another alternative is to use Bruce Guenter's vmailmgr and make all the
pop accounts virtual. You can also use tcpwrapper/tcpcontrol/firewall
to limit access so that only local users can pop. We do this and then
allow remote access via sqwebmail, but with a different password.



-Sincerely, Fred
Fred Lindberg, Inf. Dis., WashU, St. Louis, MO, USA







i don't see how with a shell as /bin/false that changing their own
password would matter, they still don't have a shell to use.

-xs


end 
+-------------------------------------+
|Greg Albrecht  KF4MKT   [EMAIL PROTECTED]|
|Safari Internet   Fort Lauderdale, FL|
|www.safari.net           888-537-9550|
+------L-O-W-E-R--D-O-T--O-R-G--------+

On Wed, 14 Apr 1999, Fred Lindberg wrote:

>On Wed, 14 Apr 1999 08:06:45 -0400 (EDT), xs wrote:
>
>>i thought about this  one this weekend, if /bin/false is in /etc/shells
>
>What about /bin/passwd? Allows people to change password via telnet ...
>
>Another alternative is to use Bruce Guenter's vmailmgr and make all the
>pop accounts virtual. You can also use tcpwrapper/tcpcontrol/firewall
>to limit access so that only local users can pop. We do this and then
>allow remote access via sqwebmail, but with a different password.
>
>
>
>-Sincerely, Fred
>Fred Lindberg, Inf. Dis., WashU, St. Louis, MO, USA
>
>
>






also may i note that i saw a problem similar to this before:
say you give a user pop3 only access, and the ability to change their
.qmail file. you're still ownable, don't forget about any setid programs
you may have clogging up your harddrive. or worse.

just $.02



end 
+-------------------------------------+
|Greg Albrecht  KF4MKT   [EMAIL PROTECTED]|
|Safari Internet   Fort Lauderdale, FL|
|www.safari.net           888-537-9550|
+------L-O-W-E-R--D-O-T--O-R-G--------+







<<< multipart/signed; boundary=X1bOJ3K7DJ5YkBrT; micalg=pgp-md5;protocol="application/pgp-signature": Unrecognized >>>




On Thu, Apr 15, 1999 at 10:55:15AM +0200, Joel Eriksson wrote:
> On Wed, Apr 14, 1999 at 02:49:08PM -0400, xs wrote:
> > 
> > also may i note that i saw a problem similar to this before:
> > say you give a user pop3 only access, and the ability to change their
> > .qmail file. you're still ownable, don't forget about any setid programs
> > you may have clogging up your harddrive. or worse.
> 
> That's why I modified qmail-local.c so that only users listed in
> /var/qmail/control/staffusers are able to do filedelivery or execute
> programs from their .qmail-files.

Hmm mind sharing that patch? I'd suppose Russell would happily put it on
www.qmail.org

Greetz, Peter
-- 
| 'He broke my heart,    |                              Peter van Dijk |
     I broke his neck'   |                     [EMAIL PROTECTED] |
   nognixz - As the sun  |        Hardbeat@ircnet - #cistron/#linux.nl |
                         | Hardbeat@undernet - #groningen/#kinkfm/#vdh |




We have a list that, when it goes out, pushes our mail server's
qmail-remote processes to its max, 180. At points, almost every single one
is "connecting" to juno.com, effectively disallowing any other mail from
getting through. juno.com, meanwhile, is timing out.

Is the best way to deal with this simply to drop timeoutconnect to
something less than 60 (seconds)? How low is too low? It seems like it
shouldn't take more than 10 or 15 seconds for the initial connection;
after that, there's probably either a network connectivity problem or the
remote server is bogged down, right?

/pg
-- 
Peter Green
Gospel Communications Network, SysAdmin
[EMAIL PROTECTED]





Peter Green <[EMAIL PROTECTED]> wrote:
>
>We have a list that, when it goes out, pushes our mail server's
>qmail-remote processes to its max, 180. At points, almost every single one
>is "connecting" to juno.com, effectively disallowing any other mail from
>getting through. juno.com, meanwhile, is timing out.

Hmm. That's not supposed to happen. See "man qmail-tcpto".

You could use a virtual domain to deliver the juno mail to a maildir,
and deliver that via maildir2smtp.

>Is the best way to deal with this simply to drop timeoutconnect to
>something less than 60 (seconds)? How low is too low? It seems like it
>shouldn't take more than 10 or 15 seconds for the initial connection;
>after that, there's probably either a network connectivity problem or the
>remote server is bogged down, right?

It'd be nice if qmail had an initialtimeoutconnect, which you could
set aggressively to zip through lists quickly, while subsequent
attempts would wait a little longer.

-Dave




Peter Gradwell writes:
 > At 11:11 am -0700 13/4/99,the wonderful Matthew Kaing wrote:
 > >Hi, I like users to be able to access and manage their email via a browser.
 > >Does anyone know of a web-based interface to Qmail or other similar packages
 > >for Linux that is freeware?
 > 
 > 
 > www.endymion.com/products/mailman

Their "Licensing" page says "MailMan is not free."

-- 
-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.




Not only that, but overall in my experience, it pretty much sucks. It
screwed up quite a bit corrupted mail files and ran quite slowly. After
using it for a month, they sent us an invoice. We promptly deleted it and
now use dmailweb from netwinsite.com. Works like a charm, very fast and
good support. 

-andy

--
-----------------------------------------------------------------------
Andy Walden                        Work Email: [EMAIL PROTECTED]
Network Administrator,             Pers Email: [EMAIL PROTECTED]
MTCO Communications                Phone: (800) 859-6826
  " Reality is just Chaos with better lighting. "



On 14 Apr 1999, Russell Nelson wrote:

> Peter Gradwell writes:
>  > At 11:11 am -0700 13/4/99,the wonderful Matthew Kaing wrote:
>  > >Hi, I like users to be able to access and manage their email via a browser.
>  > >Does anyone know of a web-based interface to Qmail or other similar packages
>  > >for Linux that is freeware?
>  > 
>  > 
>  > www.endymion.com/products/mailman
> 
> Their "Licensing" page says "MailMan is not free."
> 
> -- 
> -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.
> 





On Wed, 14 Apr 1999 10:28:31 -0500 (CDT), Andy Walden wrote:

>Not only that, but overall in my experience, it pretty much sucks. It
>screwed up quite a bit corrupted mail files and ran quite slowly. After
>using it for a month, they sent us an invoice. We promptly deleted it and
>now use dmailweb from netwinsite.com. Works like a charm, very fast and
>good support. 

We use Sam's sqwebmail. Everybody loves it. Zero admin.



-Sincerely, Fred
Fred Lindberg, Inf. Dis., WashU, St. Louis, MO, USA






On Tue, 13 Apr 1999, David Lindes wrote:
> 
> I've got a setup on my ISP's machine using qmail where they are
> hosting several virtualdomains for me, and I am setting up
> mailing lists within some of those domains with ezmlm.
> 
> The problem I'm seeing is that the envelope from header on
> messages going out from ezmlm to me or other people on the same
> ISP are getting re-written (or written in the first place by
> ezmlm, I'm not sure which) such that instead of having
> listname-return-id-user=domain, they have
> listname-return-id-qmaildeliverexpansion=domain
> 
> For example, when sending mail to [EMAIL PROTECTED], which
> [EMAIL PROTECTED] is a subscriber of, instead of having:
> 
> [EMAIL PROTECTED]
> 
> I get:
> 
> [EMAIL PROTECTED]
> 
> Because the virtualdomains entry (in /var/qmail/control) for
> daveltd.com looks like this:
> 
> daveltd.com:lindes-daveltd.d/com/q

You're subscribed as [EMAIL PROTECTED] which is a local address.  It
locally translates to lindes-daveltd.d/com/q-lindes=daveltd.com.  It
seems to me it shouldn't be translating it because translating the
local part without changing the host part to a local host (as opposed
to a virtual host) often makes it an invalid address.

qmail-send is the program that rewrites foo-return-@host-@[] to
foo-return-recip=domain@host.  qmail-send is also the program that
translates the address according to the rules in virtualdomains.

It sounds to me like there's an order of operations error here.

If your address -were- to start bouncing, I don't think ezmlm would know
because the bounce will be coming back with an invalid address embedded
in the envelope.  That doesn't seem right.

After a quick glance at qmail-send.c, it's not immediately obvious how
to change the order of operations.

Cheers,
Vern
-- 
\ \   / __| _ \  \ |   Vern Hart
 \ \ /  _|    / .  |   [EMAIL PROTECTED]
  \_/  ___|_|_\_|\_|






Well, for the people who took their time to telnet to my server and
check (thank you!) its rcpt handling (@nabla.com.br), I suggest using
the following syntax:

RCPT To:<[EMAIL PROTECTED]>

without spaces between To: and < and with the case shown. Could it be
the problem?

-- 

 ___THE___ "Commercial OS vendors are, at the moment, all closed
 \  \ /  /  economies, and doomed to fall in their competition with
  \  V  /   open economies just as communism eventually fell."
   \   /                            -- H. Reiser, Unix OS developer
   /   \     _____________________________________________________
  /  ^  \   | Juan Carlos Castro y Castro - [EMAIL PROTECTED] |
 /  / \  \  |  Diretor de Informática e Eventos Sobrenaturais da  |
 ~~~   ~~~  |                 E-RACE CORPORATION                  |
   RACER     -----------------------------------------------------




Is anyone using Qmail with the Ldap patch from Andre Oppermann in a
production environmet?

Anyone using it with a Lot'o'users?

Interested in hearing some performace tales and feedback on the success...

Thanks

Wil.






I am running qmail on machine who's sole purpose is sending remote email.  Each message contains unique text as ordered by the user and generated from a database.  The email is queuing much faster than it is sending over the DS3 WAN connection.  The bandwidth is not totally being used and I have unused CPU Bus and Disk I/O.  The ulimits/kernel configurable limits have not been met unless I am missing something.
 
My problem is that even though I have set the "concurrencyremote" to 509 I still do not meet this amount of remote sends.  The number of remote sends hovers around 256(253-260).  This seems to close to the common number of 256 to be a coincidence, but I could be wrong.  To be quite frank I'm not sure what is causing this.  I need to get these remote sends up to something closer to the 509 in order to get the information out on a timely bases. Any help would be appreciated. 
 
Thanks .... Bart




At 12:51 PM Wednesday 4/14/99, Bart Grubb wrote: 
>
> I am running qmail on machine who's sole purpose is sending remote email. 
> Each message contains unique text as ordered by the user and generated from a
> database.  The email is queuing much faster than it is sending over the DS3
> WAN connection.  The bandwidth is not totally being used and I have unused
> CPU Bus and Disk I/O.  The ulimits/kernel configurable limits have not been
> met unless I am missing something.
>  
> My problem is that even though I have set the "concurrencyremote" to 509 I
> still do not meet this amount of remote sends.  The number of remote sends
> hovers around 256(253-260).  This seems to close to the common number of 256
> to be a coincidence, but I could be wrong.  To be quite frank I'm not sure
> what is causing this.  I need to get these remote sends up to something
> closer to the 509 in order to get the information out on a timely bases. Any
> help would be appreciated. 



That's easy. The maximum for concurrencyremote is 256.


Check out conf_spawn in the sources. To get higher than that you need 
multiple instances of qmail installed.


Regards.




On Wed, 14 Apr 1999, Mark Delany wrote:

> That's easy. The maximum for concurrencyremote is 256.

I think this is mainly because the processes communicate by writing a
single byte backwards to qmail-send. does the semantics of read&write of
multiple-byte values mean that if I write 2 bytes into a pipe I'll always
get 2 bytes out of the pipe in a single read? 

if so then one might be able to patch qmail to support 65k qmail-remotes?

RjL





The theory is, if select() says that you can write to a pipe then you are 
guaranteed an atomic write of PIPE_BUF size which is typically at least 512 
bytes (eg, on Solaris 2.6 it's 5120, on FreeBSD 2.2.8 it's 512).

So in theory, a 2 byte atomic write is fine if preceeded by an appropriate 
select()

In practice I'm told that some select() implementations are buggy in this 
regard and may simply return "writable" if a single byte will fit. I have no 
direct evidence of this though.


Regards.


At 11:12 PM Wednesday 4/14/99, Richard Letts wrote:
>On Wed, 14 Apr 1999, Mark Delany wrote:
>
>> That's easy. The maximum for concurrencyremote is 256.
>
>I think this is mainly because the processes communicate by writing a
>single byte backwards to qmail-send. does the semantics of read&write of
>multiple-byte values mean that if I write 2 bytes into a pipe I'll always
>get 2 bytes out of the pipe in a single read? 
>
>if so then one might be able to patch qmail to support 65k qmail-remotes?
>
>RjL
>






Okay, this is a really strange sounding problem but I could use any ideas 
anyone has.

I have three systems sending out mail in large quantities.  One is the "master"
as the other two send it all the administrative messages and it is in charge
of parsing them.  This machine is running a pretty much stock RedHat 5.2 
system.

Anyway, all goes fine most of the time except occasionally (five times today)
I will get a lot of incoming traffic on the server and inetd decides it wants
to stop delivering on the smtp port.  My line looks like

smtp    stream  tcp     nowait  qmaild  /usr/sbin/tcpd /usr/qmail/bin/tcp-env
 /usr/qmail/bin/qmail-smtpd

and when this happens I don't even get any notification from the tcpd log files
denoting any kind of connection attempt.  When I try to telnet to the smtp port
I get the error

  telnet: Unable to connect to remote host: Connection refused

but in all other senses of the word inetd works fine.  All it takes to get my
smtp connection back is a HUP of inetd but this is rather annoying anyway.

Any ideas what the problem could be or where I should look?

-- 
  Matthew Harrell                          Beauty is in the eye of the beer
  Simulation Technology Division, SAIC      holder.
  [EMAIL PROTECTED]




Use tcpserver, you are most likely respawning the inetd process to
quickly.

Use tcpserver as a way to manage the incoming conections.

Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
[EMAIL PROTECTED]

On Wed, 14 Apr 1999, Matthew Harrell wrote:

> 
> Okay, this is a really strange sounding problem but I could use any ideas 
> anyone has.
> 
> I have three systems sending out mail in large quantities.  One is the "master"
> as the other two send it all the administrative messages and it is in charge
> of parsing them.  This machine is running a pretty much stock RedHat 5.2 
> system.
> 
> Anyway, all goes fine most of the time except occasionally (five times today)
> I will get a lot of incoming traffic on the server and inetd decides it wants
> to stop delivering on the smtp port.  My line looks like
> 
> smtp    stream  tcp     nowait  qmaild  /usr/sbin/tcpd /usr/qmail/bin/tcp-env
>  /usr/qmail/bin/qmail-smtpd
> 
> and when this happens I don't even get any notification from the tcpd log files
> denoting any kind of connection attempt.  When I try to telnet to the smtp port
> I get the error
> 
>   telnet: Unable to connect to remote host: Connection refused
> 
> but in all other senses of the word inetd works fine.  All it takes to get my
> smtp connection back is a HUP of inetd but this is rather annoying anyway.
> 
> Any ideas what the problem could be or where I should look?
> 
> -- 
>   Matthew Harrell                          Beauty is in the eye of the beer
>   Simulation Technology Division, SAIC      holder.
>   [EMAIL PROTECTED]
> 





Paul Farber was overheard saying:
: Use tcpserver, you are most likely respawning the inetd process to
: quickly.
: 
: Use tcpserver as a way to manage the incoming conections.

Duh.  Okay, while searching for where to find tcpserver I ran across the FAQ
comment about inetd and high loads.  

Sorry about wasting bandwidth...

-- 
  Matthew Harrell                          Gravity is a myth, the Earth sucks.
  Simulation Technology Division, SAIC
  [EMAIL PROTECTED]




We've just gone full-time with Qmail(as you've probably noticed by my past 
posts) and one last problem I have is with clients complaining about trying to 
send Email with return receipts and netscape.  The Qmail server refuses Email 
and netscape resends the Email without the return receipt.
Eudora works fine, with no problems.

Anyone know what causes this, or how to fix it?
(telling them to not use netscape isn't an option, we're an ISP and they get 
really pissy when their toy which used to work, stops working)

Greg






On Wed, Apr 14, 1999 at 11:58:37PM -0500, Greg Moeller wrote:

There is an ESMTP feature called DSN, Delivery Status notification. It
allows a client, like netscape, to request the mail server to inform it
when the message is successfully delivered. Sendmail supports DSN. However,
qmail doesn't, and so netscape will complain. There is no fix, other than
to add DSN support into qmail yourself. There is, however, another form of
return receipts, which works at a client level, and which netscape also
supports. It basically allows netscape to insert a header in the email
requesting a return receipt when the recipient opens the email message,
assuming the clinet supports return receipts.

This has nothing to do with qmail, and you should read all the
documentation on netscape for more info.

> We've just gone full-time with Qmail(as you've probably noticed by my past 
> posts) and one last problem I have is with clients complaining about trying to 
> send Email with return receipts and netscape.  The Qmail server refuses Email 
> and netscape resends the Email without the return receipt.
> Eudora works fine, with no problems.
> 
> Anyone know what causes this, or how to fix it?

-- 
System Administrator
See complete headers for address, homepage and phone numbers


Reply via email to