[EMAIL PROTECTED] writes:
> This is prehaps ambiguous, more accurately I should have said
>
> "The users who go to the web interface can check mail and take advantage
> of all of the functionality of sqwebmail except for sending email"
That is an entirely different matter.
> I beg your pardon for the abiguity.
The reason it was ambiguous was because you were convinced it was
a problem with relay-after-pop, which has no bearing on sqwebmail
unless you're trying to do something very silly like logging in to
sqwebmail in an attempt to allow smtp relaying (relay-after-pop still
has no bearing even then, but if you were trying to do that then you
might think it did).
> I'm not sure what you are getting at. The relay-ctrl package allows
> relay after POP3 authentication for our members that connect via an
> email client. It may be the case that this is causing a conflict of some
> sort,
Nope. Relay-after-pop affects the setting of the environment variable
RELAYCLIENT when qmail-smtpd is spawned to deal with an incoming
connection, and the value given to RELAYCLIENT depends upon the
IP address of the incoming connection and the rules in
~vpopmail/etc/tcp.smtp. But sqwebmail doesn't talk to smtpd so this
is irrelevant.
> And it would make sence that sqwebmail would use a mechinism like
> qmail-inject or something to send mail rather than making a connection to
> the smtp server.
Which is what it does, unless you've been playing with sendit.sh.
> What exactly was I wanting to do that would require a patch?
The patch would have been necessary to solve what your ambiguous
statements implied you thought you needed.
> There is probably more than one ISP that uses qmail, vpopmail, sqwebmail
> that offers their customers both pop3/smtp access with a mail client and
> access via the web with sqwebmail?
There probably is more than one ISP doing that. We do that, so I know that
there is at least one.
> It seems that this has made you rather upset.
I am not upset at all.
> If you would like to talk about it please give a phone call at your
> earliest convience 503.223.1481 and ask for sparky and we can get this
> issue sorted out.
If you wish support by phone Softflare will be happy to provide it at
our standard consultancy rates plus call charges for a call from the
UK to the US (or you can phone us and we won't bill for the phone
charges). Or I can do it in my own time, but I charge even more than
Softflare does for working in my own time. Perhaps somebody out there
is willing to give you free consultancy by phone but I am not.
> However, it may be the case that the account that the cgi program
> /home/<user>/cgi-bin/sqwebmail cannot launch qmail-inject.
> Unfortunately, I am not even sure if sqwebmail uses qmail-inject or does
> something else that talks to qmail-inject or by-passes it totally.
Sqwebmail has a script called sendit.sh which invokes qmail-inject.
> Also, when logged in as the user that owns the sqwebmail binary I can
> successfully execute the manual qmail-inject test. So, I would suspect
> that the binary owned by that user would also be able to do the same.
So would I. So the next step is to see if you can do a similar test
using
sendit.sh bounce-address sender-address
> >If you can't send mail with sqwebmail then one possibility
> > is that you have not allowed localhost (it might be your local net
> > if sqwebmail is accessing the mail directories over NFS) to relay.
Forget I mentioned that. That stuff is not involved at all. This is
not a relaying issue because sqwebmail doesn't talk to smtpd. It has
nothing to do with relay-after-pop.
--
Paul Allen
Softflare Support
