qmail Digest 11 Oct 1999 10:00:06 -0000 Issue 786
Topics (messages 31441 through 31488):
Re: Beware when patching Solaris machines
31441 by: Harald Hanche-Olsen
31442 by: Stig Sandbeck Mathisen
Files and Directories ownership for Qmail
31443 by: Subba Rao
Re: Queue stalls
31444 by: Jos Backus
Qmail won't start
31445 by: Subba Rao
Supervise command
31446 by: Subba Rao
31447 by: Magnus Bodin
31450 by: Subba Rao
31469 by: Magnus Bodin
Test
31448 by: David Summers
31449 by: David Summers
Starting as a daemon in rc*
31451 by: Todd A. Jacobs
31470 by: Magnus Bodin
daemontools 0.61
31452 by: B. Engineer
31453 by: Frank D. Cringle
Security considerations of chown qmaill
31454 by: Todd A. Jacobs
David Sill's startup script
31455 by: Subba Rao
No man pages installed?
31456 by: Todd A. Jacobs
31457 by: Markus Stumpf
31459 by: Todd A. Jacobs
Qmailanalog Equivalent
31458 by: Karl Lellman
Address Substitution
31460 by: Subba Rao
31461 by: Todd A. Jacobs
31462 by: Subba Rao
31477 by: Todd A. Jacobs
getting qmail to retry
31463 by: Phil Howard
31465 by: Sam
31466 by: Phil Howard
31468 by: Sam
31475 by: Phil Howard
qmailanalog documentation
31464 by: Ben Beuchler
qmail-inject: fatal: qq read error (#4.3.0)
31467 by: Vince Vielhaber
ECHOMAIL/MENTADENT
31471 by: Robert
control/{locals,rcpthosts,virtualdomains}
31472 by: Franck PORCHER
31473 by: Magnus Bodin
Qmail-Inject error related to Datemail
31474 by: Jon Lur�s
Selective relaying and ORBS
31476 by: John Newbigin
31478 by: Ken Jones
31479 by: John Newbigin
31483 by: John Newbigin
inetd
31480 by: Todd A. Jacobs
31482 by: thomasz.hostmaster.org
31485 by: Todd A. Jacobs
virtual email problem
31481 by: Benjamin de los Angeles Jr.
31484 by: Todd A. Jacobs
31487 by: Benjamin de los Angeles Jr.
Re: problem with svscan in daemontools 0.61
31486 by: Tetsu Ushijima
Re: Shadow Password and checkpassword
31488 by: Claus F�rber
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]
----------------------------------------------------------------------
+ Giles Lean <[EMAIL PROTECTED]>:
| On Thu, 07 Oct 1999 00:35:51 +0200 Harald Hanche-Olsen wrote:
|
| > Now, one or more of these patches "upgraded" /usr/lib/sendmail
|
| I make my startup scripts remove /usr/lib/sendmail and re-create the
| symlink that I want, just in case.
Good idea! Now, why didn't I think of that simple solution?
| The introduction of a new startup file is harder to deal with, of
| course.
Well, one could just have a script that runs
rm -f /etc/rc?.d/[SK]??sendmail
as early as possible.
Russ, something for the tips section on wwww.qmail.org?
- Harald
* Harald Hanche-Olsen (Thu, Oct 07, 1999 at 12:35:51AM +0200)
> Our sysadmin installed a bunch of patches on our Solaris machines
> today - basically, he just got a cluster of recommended patches and
> installed them all.
>
> Now, one or more of these patches "upgraded" /usr/lib/sendmail (was a
> symlink to /var/qmail/bin/sendmail, became a "real" sendmail). But
> not only that; the patch most helpfully installed the file
> /etc/rc2.d/S88sendmail for us. Came time to reboot the machine, and
> lo and behold, we now had a running sendmail daemon, which started
> rejecting all kinds of incoming mail. (It got to the smtp port before
> tcpserver+qmail-smtpd did.)
To prevent sendmail from starting at boot, remove
/etc/sendmail.cf, as the /etc/init.d/sendmail script exits if
that does not exist.
As Giles Lean mentioned: If you run Solaris with sonething else
than Solaris stock sendmail installed, you need to check at
every boot (and after every patch) that it hasn't "repaired" the
sendmail installation.
If you're feeling _really_ paranoid, make sure these commands
are in the script used to start, stop, restart and reload qmail
(if you use such a thing), and not only in a script run only at
boot. (Not every Solaris patch package requires a reboot. You
might be surprised one day. :-)
--
SSM - Stig Sandbeck Mathisen
Trust the Computer, the Computer is your Friend
This is my 3rd attempt at installing and getting to qmail to work.
I was distracted with different work during the previous 2 attempts,
When I execute the command at #9 in the INSTALL, the "rc" script
exits immediately. I am doing this as root.
When I list the contents of /var/qmail directory, all the directories ownership
is under ROOT:QMAIL.
Is this the way the file ownership should be?
How do I troubleshoot the installation process itself?
I don't know if this helps, but I am installing this on Slackware 4.0 with kernel
2.2.12.
Thank you in advance.
Subba Rao
[EMAIL PROTECTED]
==============================================================
Disclaimer - I question and speak for myself.
http://pws.prserv.net/truemax/
______________________________________________________________
On Sat, Oct 09, 1999 at 09:04:53AM -0500, Kevin Sawyer wrote:
> OK, I'm finally on to something. I'm seeing this in my logs:
>
> warning: trouble opening local/xx/xxxxx; will try again later
> warning: trouble opening remote/xx/xxxxx; will try again later
(This probably isn't very useful but anyhow...)
On Fridaymorning a system that handles diagnostic messages was being flooded
by thousands of emails coming from another system that had been having a
connectivity problem. The todo queue grew to over 10.000 entries and I was
seeing loads of the above messages as well. Scary.
Another thing I was seeing was that even after the todo queue had been emptied
and with >6000 messages still to be delivered locally, local concurrency kept
sticking around 1-2 out of 10. When sending an ALRM to qmail-send this number
would temporarily go up to 10 but dwindle to 1 again shortly after.
Unfortunately, it turned out that because of the amount of logging output all
this activity produced, the interesting entries were pushed out of the logs
:-( I have doubled the queue depth since, so maybe next time I'll have some
hard evidence.
The thing that scared me most was that it took qmail over 15 minutes to
process the todo queue. As a result, several time-critical heartbeat messages
from other systems were not delivered in time, triggering (admittedly false)
alerts.
So, I'm really hoping that the new zeroseek technology that qmail 2 supposedly
will be using will address this todo issue.
--
Jos Backus _/ _/_/_/ "Reliability means never
_/ _/ _/ having to say you're sorry."
_/ _/_/_/ -- D. J. Bernstein
_/ _/ _/ _/
[EMAIL PROTECTED] _/_/ _/_/_/ use Std::Disclaimer;
I haven't made any changes, I left behind since the last 2 installation
attempts. The last time I stopped the Qmail install, I could see the
entries in "syslog". This time around nothing is happening. The script
stops immediately. When I do a "ps waux", there are no processes listed
for qmail. Please look at the output below.
Can someone please shed some light, on what I could be missing?
Thank you in advance.
Subba Rao
[EMAIL PROTECTED]
==============================================================
Disclaimer - I question and speak for myself.
http://pws.prserv.net/truemax/
______________________________________________________________
root@caesar:/var/qmail# cat rc
#!/bin/sh
# Using splogger to send the log through syslog.
# Using qmail-local to deliver messages to ~/Mailbox by default.
exec env - PATH="/var/qmail/bin:$PATH" qmail-start ./Mailbox splogger qmail
root@caesar:/var/qmail#
root@caesar:/var/qmail# csh -cf '/var/qmail/rc &'
[1] 8156
[1] Exit 111 /var/qmail/rc
root@caesar:/var/qmail#
I am using the startup script from David Sill's LWQ document.
When I execute this script, I get the following:
root@caesar:/etc/rc.d# ./rc.qmail start
Starting qmail: qmail-send qmail-smtpdsupervise: usage: supervise dir
.
root@caesar:/etc/rc.d#
Can someone please tell me, how to get the "supervise" to work?
Thank you in advance.
Subba Rao
[EMAIL PROTECTED]
==============================================================
Disclaimer - I question and speak for myself.
http://pws.prserv.net/truemax/
______________________________________________________________
On Sun, Oct 10, 1999 at 01:29:01PM -0400, Subba Rao wrote:
>
> I am using the startup script from David Sill's LWQ document.
> When I execute this script, I get the following:
>
>
> root@caesar:/etc/rc.d# ./rc.qmail start
> Starting qmail: qmail-send qmail-smtpdsupervise: usage: supervise dir
> .
> root@caesar:/etc/rc.d#
>
> Can someone please tell me, how to get the "supervise" to work?
You must create a directory for supervise to place it's lock in.
If you read e.g. the documentation for supervise or
Life with qmail start: http://web.infoave.net/~dsill/lwq.html#start-qmail
(follow all of 2.8.x)
--
magnus
-- MOST useless 1998 * http://x42.com/
I do have the /var/supervise directory.
The subdirectories are,
qmail
qmail/send
qmail/smtpd
I have changed the following program names to their current names.
setuser - setuidgid
accustamp - tai64n
cyclog - mulitlog
Subba Rao
[EMAIL PROTECTED]
==============================================================
Disclaimer - I question and speak for myself.
http://pws.prserv.net/truemax/
______________________________________________________________
On Sun, 10 Oct 1999 19:43:51 +0200, Magnus Bodin wrote:
>On Sun, Oct 10, 1999 at 01:29:01PM -0400, Subba Rao wrote:
>>
>> I am using the startup script from David Sill's LWQ document.
>> When I execute this script, I get the following:
>>
>>
>> root@caesar:/etc/rc.d# ./rc.qmail start
>> Starting qmail: qmail-send qmail-smtpdsupervise: usage: supervise dir
>> .
>> root@caesar:/etc/rc.d#
>>
>> Can someone please tell me, how to get the "supervise" to work?
>
>You must create a directory for supervise to place it's lock in.
>If you read e.g. the documentation for supervise or
>Life with qmail start: http://web.infoave.net/~dsill/lwq.html#start-qmail
>(follow all of 2.8.x)
>
>--
>magnus
> -- MOST useless 1998 * http://x42.com/
>
On Sun, Oct 10, 1999 at 02:07:32PM -0400, Subba Rao wrote:
> I do have the /var/supervise directory.
> The subdirectories are,
>
> qmail
> qmail/send
> qmail/smtpd
>
> I have changed the following program names to their current names.
> setuser - setuidgid
> accustamp - tai64n
> cyclog - mulitlog
NO NO NO NO!
If you want to use daemontools 0.53, then USE daemontools 0.53 (setuser,
accustamp and cyclog).
They have not just changed their names, they've changed behavoir too.
You CAN NOT just rename the programs to make them BEHAVE like daemontools
0.61.
If you want to use daemontools 0.61 (setuidgid, tai64n & multilog) then
download the new daemontools package and install that!
--
magnus
-- MOST useless 1998 * http://x42.com/
Test.
--
David Wayne Summers "Linux: Because reboots are for upgrades!"
[EMAIL PROTECTED] PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = C0 E0 4F 50 DD A9 B6 2B 60 A1 31 7E D2 28 6D A8
Woops, I was trying to set up my local news posting program and goofed.
Sorry for the wasted bandwith.
On 10 Oct 1999, David Summers wrote:
> Date: 10 Oct 1999 12:49:39 -0500
> From: David Summers <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Newsgroups: ml.qmail
> Subject: Test
>
> Test.
> --
> David Wayne Summers "Linux: Because reboots are for upgrades!"
> [EMAIL PROTECTED] PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
> PGP Key fingerprint = C0 E0 4F 50 DD A9 B6 2B 60 A1 31 7E D2 28 6D A8
>
David Wayne Summers "Linux: Because reboots are for upgrades!"
[EMAIL PROTECTED] PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = C0 E0 4F 50 DD A9 B6 2B 60 A1 31 7E D2 28 6D A8
I'm new to qmail, and have been playing around with trying to get the
qmail-send process to start and stop in certain runlevels. I've found that
SIGTERM send to qmail-send will kill all the qmail processes. I can't seem
to write a usable rc-style script to automate this, though.
Does anyone has such a beast? Is it even a good idea?
--
Todd A. Jacobs
Network Systems Engineer
On Sun, Oct 10, 1999 at 11:16:21AM -0700, Todd A. Jacobs wrote:
> I'm new to qmail, and have been playing around with trying to get the
> qmail-send process to start and stop in certain runlevels. I've found that
> SIGTERM send to qmail-send will kill all the qmail processes. I can't seem
> to write a usable rc-style script to automate this, though.
>
> Does anyone has such a beast? Is it even a good idea?
See:
http://Web.InfoAve.Net/~dsill/lwq.html#start-qmail
--
magnus
-- MOST useless 1998 * http://x42.com/
Hi:
I have moved over to deamontools 0.61 but cannot logging to work
as DJB intended.
deamontools suggests that pipe is a big no no, so here is my qmail rc
script that works fine.
#!/bin/ksh
# Using stdout for logging
# Using control/defaultdelivery from qmail-local to deliver messages by
default
exec env - PATH="/var/qmail/bin:$PATH" \
qmail-start "`cat /var/qmail/control/defaultdelivery`" \
|setuidgid qmaill /local/bin/multilog t s99000000 n20 /var/log/qmail
This works fine.
When I switch to running under supervise, I changed it to remove the
logging line from the above so now its only
qmail-start "`cat /var/qmail/control/defaultdelivery`" when it is
invoked by the run script.
and I have made a directory/file called ./log/run that has
exec setuidgid qmaill /local/bin/multilog t s99000000 n20 /var/log/qmail
but when I run it under supervise, qmail logs go to standard out and ps
does not show any multilog process.
Where am I going wrong.
Thanks
Burzin
"B. Engineer" <[EMAIL PROTECTED]> writes:
> Hi:
> I have moved over to deamontools 0.61 but cannot logging to work
> as DJB intended.
> ...
> and I have made a directory/file called ./log/run that has
> exec setuidgid qmaill /local/bin/multilog t s99000000 n20 /var/log/qmail
>
> but when I run it under supervise, qmail logs go to standard out and ps
> does not show any multilog process.
The idea is to use svscan to start 2 supervise processes with a pipe
between them. See the documentation in svscan.html on djb's website:
If a subdirectory sub is sticky, svscan starts a pair of supervise
processes, one for sub, one for sub/log, with a pipe between them.
svscan needs two free descriptors for each pipe.
There must be some story explaining why the documentation is not
included in the tarball, but I don't know what it is.
--
Frank Cringle, [EMAIL PROTECTED]
voice: (+49 2304) 467101; fax: 943357
In the web site at
http://web.infoave.net/%7Edsill/lwq.html.proxymate.qs#install-daemontools,
there's a point where one is directed to create a directory and chown
qmaill. Part of the init.d script seems to rely on this step.
My question is whether there is a security consideration, because qmaill
is part of the nofiles group. Isn't security being compromised by allowing
qmaill to own files?
--
Todd A. Jacobs
Network Systems Engineer
I am using the startup script from David Sill's LWQ document.
When I execute this script, I get the following:
root@caesar:/etc/rc.d# ./rc.qmail start
Starting qmail: qmail-send qmail-smtpdsupervise: usage: supervise dir
.
root@caesar:/etc/rc.d#
Can someone please tell me, how to get the "supervise" to work?
I did substitute the new names for the programs such as setuser, cyclog etc.
Nothing else was changed.
Qmail starts for the following command,
csf -cf '/var/qmail/rc &'
When I use David Sill's script, it does not work. Has anyone else got the David's
script to work?
One other question, how do I make my email clients to read from the Maildir?
I use ELM and MUTT. I would like to be able to read these messages. I do see
them in the Maildir/new directory.
Thank you in advance.
Subba Rao
[EMAIL PROTECTED]
==============================================================
Disclaimer - I question and speak for myself.
http://pws.prserv.net/truemax/
______________________________________________________________
The man pages were not installed by default. How can I install them?
--
Todd A. Jacobs
Network Systems Engineer
On Sun, Oct 10, 1999 at 01:44:59PM -0700, Todd A. Jacobs wrote:
> The man pages were not installed by default. How can I install them?
They probably are, but they go to
/var/qmail/man
Add this directory to your MANPATH environemt variable and the "man"
command will find them.
\Maex
--
SpaceNet GmbH | http://www.Space.Net/ | Yeah, yo mama dresses
Research & Development | mailto:[EMAIL PROTECTED] | you funny and you need
Joseph-Dollinger-Bogen 14 | Tel: +49 (89) 32356-0 | a mouse to delete files
D-80807 Muenchen | Fax: +49 (89) 32356-299 |
On Sun, 10 Oct 1999, Markus Stumpf wrote:
> They probably are, but they go to
> /var/qmail/man
> Add this directory to your MANPATH environemt variable and the "man"
> command will find them.
Thanks. It worked like a charm. :)
--
Todd A. Jacobs
Network Systems Engineer
Hi,
I have had a customers site (reasonably) happily using Qmail 1.03 as a mail
relay between the internet and their internal MS Exchange server. I have
had odd problems with Qmail making connections through the proxy based
firewall, but nothing too major.
A new release of the firewall product has come out, which now has a sendmail
implementation inbuilt. Although I'm not a huge sendmail fan, it is a lot
more practical and reliable (re delivery problems through proxy) than the
current qmail implementation. So basically the qmail machine is going to
loose out in the case to sendmail.
What I am curious about is whether there is a qmailanalog equivalent for
sendmail? I have setup cron jobs on this users machine to generate
extrememly useful stats and reports daily for the customer and will
definitely miss not having this with sendmail.
I know that this isn't the ideal place to ask this question, but I've always
been one to go about things differently from the normal.
Thanks,
Karl Lellman
Systems Consultant
Extranet Technologies Limited
Level 3, 60 Cook Street, Auckland, New Zealand
P.O. Box 7726, Wellesley Street, Auckland, New Zealand
Phone +64 9 3771122, Fax +64 9 3771109, Mobile +64 21 771188
e-mail: [EMAIL PROTECTED]
I have many local users on my machine. The domainname, I use for my LAN is a bogus
domainname.
When a local user sends out email, I want the address to be translated to my ISP given
email address.
The little documentation, I found on virtualdomains, is not helping me.
How can I achieve that setup?
Thank you in advance.
Subba Rao
[EMAIL PROTECTED]
==============================================================
Disclaimer - I question and speak for myself.
http://pws.prserv.net/truemax/
______________________________________________________________
Put your "real" email address into /var/qmail/control/defaultdomain. That
should create all new emails as being from that domain.
--
Todd A. Jacobs
Network Systems Engineer
Thank you for replying.
What if I have different email address at different service providers?
This account has ibm.net, while I have an account at yahoo.com, netscape.com etc.
How do I append different domainname to different accounts?
Thank you once again.
Subba Rao
[EMAIL PROTECTED]
==============================================================
Disclaimer - I question and speak for myself.
http://pws.prserv.net/truemax/
______________________________________________________________
On Sun, 10 Oct 1999 17:01:36 -0700 (PDT), Todd A. Jacobs wrote:
>Put your "real" email address into /var/qmail/control/defaultdomain. That
>should create all new emails as being from that domain.
>
>--
>Todd A. Jacobs
>Network Systems Engineer
>
>
On Sun, 10 Oct 1999, Subba Rao wrote:
> What if I have different email address at different service providers?
> This account has ibm.net, while I have an account at yahoo.com, netscape.com etc.
> How do I append different domainname to different accounts?
It's easier to rewrite the From: header in your email. Just set up your
MUA to write what you want in that header, and qmail shouldn't overwrite
it. The default is just that: a default, in case nothing is specified.
--
Todd A. Jacobs
Network Systems Engineer
I got this back for a bounced bounce:
| Hi. This is the qmail-send program at ipal.net.
| I tried to deliver a bounce message to this address, but the bounce bounced!
|
| <[EMAIL PROTECTED]>:
| 204.68.24.19 does not like recipient.
| Remote host said: 552 <[EMAIL PROTECTED]>... User exceed storage quota
| Giving up on 204.68.24.19.
Is there a way to get qmail to not give up on such messages?
Can it be done by configuration or does this require a hack?
In cases of exceeding quota, I want outgoing mail to keep trying
for just as long as it would in cases of not being able to reach
the mail host at all.
Yes, I want the mail servers of businesses that host spammers to
have their mail servers persistently bounded on for days from all
the various places the spammer spewed their filth. They can junk
sink hole the box to stop it.
--
Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
at | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
dot | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
On Sun, 10 Oct 1999, Phil Howard wrote:
> I got this back for a bounced bounce:
>
> | Hi. This is the qmail-send program at ipal.net.
> | I tried to deliver a bounce message to this address, but the bounce bounced!
> |
> | <[EMAIL PROTECTED]>:
> | 204.68.24.19 does not like recipient.
> | Remote host said: 552 <[EMAIL PROTECTED]>... User exceed storage quota
> | Giving up on 204.68.24.19.
>
> Is there a way to get qmail to not give up on such messages?
> Can it be done by configuration or does this require a hack?
No. The remote server indicated that this is a permanent failure.
Permanent failures get bounced, period.
> In cases of exceeding quota, I want outgoing mail to keep trying
> for just as long as it would in cases of not being able to reach
> the mail host at all.
This is not up to you. The remote server responded with a permanent
failure code. The mail gets bounced.
Sam replied:
> On Sun, 10 Oct 1999, Phil Howard wrote:
>
> > I got this back for a bounced bounce:
> >
> > | Hi. This is the qmail-send program at ipal.net.
> > | I tried to deliver a bounce message to this address, but the bounce bounced!
> > |
> > | <[EMAIL PROTECTED]>:
> > | 204.68.24.19 does not like recipient.
> > | Remote host said: 552 <[EMAIL PROTECTED]>... User exceed storage quota
> > | Giving up on 204.68.24.19.
> >
> > Is there a way to get qmail to not give up on such messages?
> > Can it be done by configuration or does this require a hack?
>
> No. The remote server indicated that this is a permanent failure.
> Permanent failures get bounced, period.
>
> > In cases of exceeding quota, I want outgoing mail to keep trying
> > for just as long as it would in cases of not being able to reach
> > the mail host at all.
>
> This is not up to you. The remote server responded with a permanent
> failure code. The mail gets bounced.
I understand that it is a permanent failure code. But clearly a full
mailbox is not a true permanent situation (although a spammer case is
probably one that not only will not be emptied, but likely to be cut
off as well).
What I was looking for is if there was a table of response codes and
how to act when receiving them. Because of scattered documentation
for qmail that means I haven't yet found everything, I'm trying to
focus at the moment on what's important now.
If it is the case that the answer is "no", then the answer is mapped into
being "you'll have to make a hack to do that". I take it you are trying
to say that the answer is "no".
--
Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
at | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
dot | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
On Sun, 10 Oct 1999, Phil Howard wrote:
> Sam replied:
>
> > On Sun, 10 Oct 1999, Phil Howard wrote:
> >
> > > Is there a way to get qmail to not give up on such messages?
> > > Can it be done by configuration or does this require a hack?
> >
> > No. The remote server indicated that this is a permanent failure.
> > Permanent failures get bounced, period.
> >
> > > In cases of exceeding quota, I want outgoing mail to keep trying
> > > for just as long as it would in cases of not being able to reach
> > > the mail host at all.
> >
> > This is not up to you. The remote server responded with a permanent
> > failure code. The mail gets bounced.
>
> I understand that it is a permanent failure code. But clearly a full
> mailbox is not a true permanent situation (although a spammer case is
This is not your call. It is the receiving mail server that gets to
decide what is a permanent failure, and what is a temporary failure.
> probably one that not only will not be emptied, but likely to be cut
> off as well).
>
> What I was looking for is if there was a table of response codes and
> how to act when receiving them.
Well, yes. It's called RFC 822. It specifies that all 4xx error codes
are temporary failures, and that all 5xx error codes are permanent
failures.
There's also RFC 1893, which lists specific error codes for specific
situations, but that is only for the purpose of generating meaningful
English error messages, and it does not alter in any way the basic
definition of what is a permanent, and what is a transient error.
> Because of scattered documentation
> for qmail that means I haven't yet found everything, I'm trying to
> focus at the moment on what's important now.
This has nothing to do with Qmail. This is the core definition of SMTP -
that all 5xx error codes are permanent failures, and there's nothing that
Qmail, or any other mail server out there, can do anything about. If
Qmail gets ANY 5xx error code from the remote mail server, it is obligated
to immediately return the message as undeliverable. To do otherwise would
violate RFC 822.
All properly written mail servers will do that. Qmail is not an issue
here. Perhaps you can persuade usa.net to issue a 422 error instead of a
522 error for this condition, but I don't think you'll have much success.
usa.net does not want repeated delivery attempts when one of their
mailboxes is full, and it is their call as far as that's concerned.
--
Sam
Sam replied:
> On Sun, 10 Oct 1999, Phil Howard wrote:
>
> > Sam replied:
> >
> > > On Sun, 10 Oct 1999, Phil Howard wrote:
> > >
> > > > Is there a way to get qmail to not give up on such messages?
> > > > Can it be done by configuration or does this require a hack?
> > >
> > > No. The remote server indicated that this is a permanent failure.
> > > Permanent failures get bounced, period.
> > >
> > > > In cases of exceeding quota, I want outgoing mail to keep trying
> > > > for just as long as it would in cases of not being able to reach
> > > > the mail host at all.
> > >
> > > This is not up to you. The remote server responded with a permanent
> > > failure code. The mail gets bounced.
> >
> > I understand that it is a permanent failure code. But clearly a full
> > mailbox is not a true permanent situation (although a spammer case is
>
> This is not your call. It is the receiving mail server that gets to
> decide what is a permanent failure, and what is a temporary failure.
But my server can decide whether to bounce it now or requeue it and try
again later as if it were a temporary error.
> > probably one that not only will not be emptied, but likely to be cut
> > off as well).
> >
> > What I was looking for is if there was a table of response codes and
> > how to act when receiving them.
>
> Well, yes. It's called RFC 822. It specifies that all 4xx error codes
> are temporary failures, and that all 5xx error codes are permanent
> failures.
I mean a programmed table in qmail, where it specifies the internal routines
for the action. If such a table is in a config file, I could change it
there. If it is in the code, I can change it there. If it's not organized
that way, I guess I'll have to code explicit checks.
> > Because of scattered documentation
> > for qmail that means I haven't yet found everything, I'm trying to
> > focus at the moment on what's important now.
>
> This has nothing to do with Qmail. This is the core definition of SMTP -
> that all 5xx error codes are permanent failures, and there's nothing that
> Qmail, or any other mail server out there, can do anything about. If
> Qmail gets ANY 5xx error code from the remote mail server, it is obligated
> to immediately return the message as undeliverable. To do otherwise would
> violate RFC 822.
My question was how make a change in qmail, not whether my change conformed
to the standards.
> All properly written mail servers will do that. Qmail is not an issue
> here. Perhaps you can persuade usa.net to issue a 422 error instead of a
> 522 error for this condition, but I don't think you'll have much success.
> usa.net does not want repeated delivery attempts when one of their
> mailboxes is full, and it is their call as far as that's concerned.
So I'll map 522 to 422, perhaps only if the string "quota", "exceeded",
or "full" is present.
--
Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
at | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
dot | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Is there a source of good documentation for qmailanalog? As near as I can
tell, it's just trial and error to figure out what type of output each
script will produce.
And, barring that, any suggestions on a useful cron setup to produce daily
reports?
Ben
----------
The phrasing, style, and content of this message are the sole property of
Ben Beuchler, Inc. and may not be reproduced in any way, shape or form
without the written consent Ben Beuchler Enterprises. All rights reserved.
Void where prohibited by law. Do not remove under penalty of law. Do not
spindle or fold. Not valid in Alaska, Hawaii, or Puerto Rico.
What are some possible causes for this error?
qmail-inject: fatal: qq read error (#4.3.0)
Friday everything was fine, today I can't send mail. The above was
from /var/qmail/bin/mailsubj, but I get the same from pine. Mail is
coming in just fine it's just locally generated mail (and it's not
going thru smtp).
I've run make setup check figuring something may have changed, no go.
There's plenty of disk space too. Anyone have an idea?
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
==========================================================================
I just received a very odd bounce message from my qmail server. Can
anyone tell me what this all means?? I have pasted a small snippett of
the text below. Thank you.
Delivery Failure Report
Your failure
notice
document:
was not
preventive
delivered
to:
because: Error delivering to ECHOMAIL/MENTADENT preventive.nsf;
File does
not
exist
Echomail/Mentadent, Echomail/Mentadent
Hello,
First, I would like to thank any contributor, and especially
D.J.Bernstein, for giving the community this great alternative.
To my knowledge, our young company is the first to have setup qmail down
here in Tahiti (French Polynesia).
We got definitely convinced to give it a serious try after attending an
excellent tutorial
in LinuxWorld expo (San Jose March 1999).
Our local airline company has now switched, and we are working with the
government to help them swith
from sendmail to qmail (1500 users).
Eventhough I feel somehow aquainted with qmail, I still have a few
points
unresolved, for which I would be quite grateful to anyone who could and
would actually help me solve them (yes I have read the faq and ALL the
doc)
a) control/locals
Let's say I'm trying to have my qmailhost server locally delivers mail
for my top domain, eg "esoft.pf", and some of its sub domains as well,
eg "sales.esoft.pf", "edu.esoft.pf" etc.. That means that qmail-smtp
and qmail-send would have to accept mail adresses like [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]
So far, I have had to put a separate line for each allowed subdomain in
control/locals.
My questions are :
- Is that the only way to do it ? If not, which are the other ways?
- Is that the best way ?
- Is there a way we can use wildcards, like ".esoft.pf"
b) control/rcpthosts
For the mail to be received for those subdomains, I added a separate
line in control/rcpthosts, and it works fine.
Now, this server working inbound and outbound, it will have to accept
ANY mail on port 25 (qmail-smtp) from internal employees using local
clients like "outlook express" or "Netscape Messenger', and handle
remote delivery for any external address. I understand that this means
this server will have to be configured as a RELAYCLIENT.
I have read how to set up the RELAYCLIENT environment variable, so
that's one solution.
Now, my question is about the use of wildcards within rcpthosts as
another solution. It is said in the qmail-smtpd man page (8), that
rcpthosts may include
wildcards, in the form ".domain", meaning "accept any address belonging
to <domain>". I tested it and it works. Now, in the sake of coherence,
what is the reason
why rcpthosts does not accept the record made of the dot itself ".",
meaning "accept any address belonging to any topdomain", which would be
another simple way to setup RELAYCLIENT='' ? I may be missing
something...
c) For some reason, I have a employee, lets's say "jean", that works at
home, and who gets his email thru a mailbox at our ISP : all email
received by this ISP
and matching the address "[EMAIL PROTECTED]" goes to his mailbox. So far, so
good.
The problem I'm having here is that my qmailer being configured to
locally deliver any mail to "esoft.pf" (see question a),
it considers the address "[EMAIL PROTECTED]" to be local (cf point a) and
does not deliver messages for jean thru my ISP. Here is my question :
What would be the best way to configure qmail to have this specific
address ([EMAIL PROTECTED]) remotely delivered to my ISP (say "mail.pf"), so
any local mail to
[EMAIL PROTECTED] would eventually end-up in his remote mailbox. ?
I thought of putting
[EMAIL PROTECTED]:alias-myisp
in "control/virtualdomains",
then setting up
~alias/.qmail-myisp-default ($DEFAULT holding "jean", and $HOST
holding"esoft.pf")
but I just do not seem to find out what to put in
~alias/.qmail-myisp-default so messages controlled by this file
are actually sent to '"$DEFAULT"@"$HOST"' thru my remote isp (mail.pf).
[A wonderful "ecard" rendering our beautiful lagoons to any one
helping me solve those issues"
Thank you
Franck PORCHER
Essential Software
begin:vcard
n:PORCHER;Franck
tel;work:(689) 56 23 95
x-mozilla-html:TRUE
url:http://www.esoft.pf/
org:Essential Software
adr:;;BP 4206 ;Papeete;Tahiti;98713;Polyn�sie fran�aise
version:2.1
email;internet:[EMAIL PROTECTED]
title:Fondateur & g�rant. Founder & Executive Director
x-mozilla-cpt:;2240
fn:Franck PORCHER
end:vcard
On Mon, Oct 11, 1999 at 05:25:33AM +0000, Franck PORCHER wrote:
>
> a) control/locals
> Let's say I'm trying to have my qmailhost server locally delivers mail
> for my top domain, eg "esoft.pf", and some of its sub domains as well,
> eg "sales.esoft.pf", "edu.esoft.pf" etc.. That means that qmail-smtp
> and qmail-send would have to accept mail adresses like [EMAIL PROTECTED],
> [EMAIL PROTECTED], [EMAIL PROTECTED]
> So far, I have had to put a separate line for each allowed subdomain in
> control/locals.
> My questions are :
> - Is that the only way to do it ? If not, which are the other ways?
> - Is that the best way ?
> - Is there a way we can use wildcards, like ".esoft.pf"
Putting a domain in "locals" makes it local, which means that EVERY USER on
the system gets the mail for <user>@<domain>.
If you have at least one user that should not get local domain mail this
way, it's most often better to make the domain "virtual" and thus putting it
in virtualdomains INSTEAD (never in both) of locals.
> b) control/rcpthosts
> For the mail to be received for those subdomains, I added a separate
> line in control/rcpthosts, and it works fine.
Good.
You could have wildcarded with
.esoft.pf
as well.
> Now, this server working inbound and outbound, it will have to accept
> ANY mail on port 25 (qmail-smtp) from internal employees using local
> clients like "outlook express" or "Netscape Messenger', and handle
> remote delivery for any external address. I understand that this means
> this server will have to be configured as a RELAYCLIENT.
>
> I have read how to set up the RELAYCLIENT environment variable, so
> that's one solution.
>
> Now, my question is about the use of wildcards within rcpthosts as
> another solution. It is said in the qmail-smtpd man page (8), that
> rcpthosts may include wildcards, in the form ".domain",
> meaning "accept any address belonging
> to <domain>". I tested it and it works. Now, in the sake of coherence,
> what is the reason why rcpthosts does not accept the record made of the
> dot itself ".", meaning "accept any address belonging to any topdomain",
> which would be another simple way to setup RELAYCLIENT='' ? I may be
> missing something...
This is a tcprules/tcpserver matter. You'll want to look into the
documentation and man pages for tcpserver and tcprules (found in the
ucspi-tcp-package). I would recommend filtering on IP-numbers instead of
domain names as they're much harder to fake/spoof.
You will definitively only relay for the hosts within your own net. All nets
(LAN/WAN:s) and ISP:s should include an SMTP host.
> c) For some reason, I have a employee, lets's say "jean", that works at
> home, and who gets his email thru a mailbox at our ISP : all email
> received by this ISP and matching the address "[EMAIL PROTECTED]"
> goes to his mailbox. So far, so good.
How is this mail fetched from the ISP? SMTP? POP?
> The problem I'm having here is that my qmailer being configured to
> locally deliver any mail to "esoft.pf" (see question a),
> it considers the address "[EMAIL PROTECTED]" to be local (cf point a) and
> does not deliver messages for jean thru my ISP. Here is my question :
> What would be the best way to configure qmail to have this specific
> address ([EMAIL PROTECTED]) remotely delivered to my ISP (say "mail.pf"), so
>
> any local mail to
> [EMAIL PROTECTED] would eventually end-up in his remote mailbox. ?
> I thought of putting
>
> [EMAIL PROTECTED]:alias-myisp
>
> in "control/virtualdomains",
> then setting up
>
> ~alias/.qmail-myisp-default ($DEFAULT holding "jean", and $HOST
> holding"esoft.pf")
>
> but I just do not seem to find out what to put in
> ~alias/.qmail-myisp-default so messages controlled by this file
> are actually sent to '"$DEFAULT"@"$HOST"' thru my remote isp (mail.pf).
Why do you want to forward this mail?
Where does jean pick up the mail? At the ISP or at your host?
If just the endpoint mail host is configured as a primary mail server, then
no forwarding has to be done.
--
magnus
-- MOST useless 1998 * http://x42.com/
Hello!
I have a problem, here is what my qmail log says:
>939620707.238895 status: local 1/10 remote 0/20
>939620710.595702 delivery 1: success: qmail->
> inject:_fatal:_read_error/did_1+0+1/
>939620710.620806 status: local 0/10 remote 0/20
The first time I got this error was with the Vacation program from
Peter Samuel. The Vacation program uses Datemail. When I
removed Vacation from the .qmail file and used Datemail directly I
still got the error. I have tried with Forward in the .qmail and this
works okay.
I am quite sure that this problem has something to do with
permissions. I have look at all the permissions in the /var/qmail/bin
and in the /home/user/Maildir/ with no success so far.
The system is a Redhat 6.0 and I used the
qmail-1.03-14ucspi.src.rpm for installation.
Vennlig hilsen
Jon Lur�s
I just received a message from the ORBS database. It seems that qmail
has a bug.feature which allows relaying of messages in the form
jn%it.swin.edu.au@[1.2.3.4]
Where 1.2.3.4 is the IP address of my mail server, not for
it.swin.edu.au. (I don't want everyone on the list to try it :).
The machine should accept mail for 1.2.3.4, but the message is actualy
sent to [EMAIL PROTECTED]
The mail relay should only accept mail for [EMAIL PROTECTED]
I have tcpd set up to allow relaying only from machines inside 1.2.3.0
Is there a way to dissable this feature/bug.
If you want to test your system, use the telnet service from here
http://maps.vix.com/tsi/ar-test.html
I am sure that there are many people with a simalar setup which could
pose a large spam risk.
I would appreciate a speedy reply.
John.
--
Information Technology Innovation Group
Swinburne University. Melbourne, Australia
http://uranus.it.swin.edu.au/~jn
I just ran the telnet test on my test qmail setup.
>>> MAIL FROM:<[EMAIL PROTECTED]>
<<< 250 ok
>>> RCPT TO:<[EMAIL PROTECTED]>
<<< 250 ok
Relay test result
Uh oh, host appeared to accept a message for relay.
The host may reject this message internally, however
Connection closed by foreign host.
Qmail does reject it internally.
Ken Jones
Inter7
John Newbigin wrote:
>
> I just received a message from the ORBS database. It seems that qmail
> has a bug.feature which allows relaying of messages in the form
> jn%it.swin.edu.au@[1.2.3.4]
> Where 1.2.3.4 is the IP address of my mail server, not for
> it.swin.edu.au. (I don't want everyone on the list to try it :).
>
> The machine should accept mail for 1.2.3.4, but the message is actualy
> sent to [EMAIL PROTECTED]
> The mail relay should only accept mail for [EMAIL PROTECTED]
>
> I have tcpd set up to allow relaying only from machines inside 1.2.3.0
>
> Is there a way to dissable this feature/bug.
>
> If you want to test your system, use the telnet service from here
> http://maps.vix.com/tsi/ar-test.html
>
> I am sure that there are many people with a simalar setup which could
> pose a large spam risk.
>
> I would appreciate a speedy reply.
>
> John.
>
> --
> Information Technology Innovation Group
> Swinburne University. Melbourne, Australia
> http://uranus.it.swin.edu.au/~jn
I did some tests and the host 1.2.3.4 did indeed relay the message.
I can't seem to connect to orbital.inter7.com to test it.
Ken Jones wrote:
> I just ran the telnet test on my test qmail setup.
>
> >>> MAIL FROM:<[EMAIL PROTECTED]>
> <<< 250 ok
> >>> RCPT TO:<[EMAIL PROTECTED]>
> <<< 250 ok
> Relay test result
> Uh oh, host appeared to accept a message for relay.
> The host may reject this message internally, however
> Connection closed by foreign host.
>
> Qmail does reject it internally.
>
> Ken Jones
> Inter7
>
> John Newbigin wrote:
> >
> > I just received a message from the ORBS database. It seems that qmail
> > has a bug.feature which allows relaying of messages in the form
> > jn%it.swin.edu.au@[1.2.3.4]
> > Where 1.2.3.4 is the IP address of my mail server, not for
> > it.swin.edu.au. (I don't want everyone on the list to try it :).
> >
> > The machine should accept mail for 1.2.3.4, but the message is actualy
> > sent to [EMAIL PROTECTED]
> > The mail relay should only accept mail for [EMAIL PROTECTED]
> >
> > I have tcpd set up to allow relaying only from machines inside 1.2.3.0
> >
> > Is there a way to dissable this feature/bug.
> >
> > If you want to test your system, use the telnet service from here
> > http://maps.vix.com/tsi/ar-test.html
> >
> > I am sure that there are many people with a simalar setup which could
> > pose a large spam risk.
> >
> > I would appreciate a speedy reply.
> >
> > John.
> >
> > --
> > Information Technology Innovation Group
> > Swinburne University. Melbourne, Australia
> > http://uranus.it.swin.edu.au/~jn
--
Information Technology Innovation Group
Swinburne University. Melbourne, Australia
http://uranus.it.swin.edu.au/~jn
Sorry to cause a worry.
The problem turned out to be the % hack, but not on the qmail box. It
acts as a relay for another box running sendmail. It was the sendmail
doing the %hack and then forwarding the message back to the qmail box for
deleviery.
Thanks for the help all the same.
John.
John Newbigin wrote:
> I just received a message from the ORBS database. It seems that qmail
> has a bug.feature which allows relaying of messages in the form
> jn%it.swin.edu.au@[1.2.3.4]
> Where 1.2.3.4 is the IP address of my mail server, not for
> it.swin.edu.au. (I don't want everyone on the list to try it :).
>
> The machine should accept mail for 1.2.3.4, but the message is actualy
> sent to [EMAIL PROTECTED]
> The mail relay should only accept mail for [EMAIL PROTECTED]
>
> I have tcpd set up to allow relaying only from machines inside 1.2.3.0
>
> Is there a way to dissable this feature/bug.
>
> If you want to test your system, use the telnet service from here
> http://maps.vix.com/tsi/ar-test.html
>
> I am sure that there are many people with a simalar setup which could
> pose a large spam risk.
>
> I would appreciate a speedy reply.
>
> John.
>
> --
> Information Technology Innovation Group
> Swinburne University. Melbourne, Australia
> http://uranus.it.swin.edu.au/~jn
--
Information Technology Innovation Group
Swinburne University. Melbourne, Australia
http://uranus.it.swin.edu.au/~jn
As instructed by the installation guide, I placed an entry for smtp into
inetd.conf. However, the entry:
smtp stream tcp nowait qmaild /var/qmail/bin/tcp-env \
tcp-env /var/qmail/bin/qmail-smtpd
doesn't seem to pay any attention to /etc/hosts.deny. I tried prefacing it
with tcpd, but that didn't do much good either. Suggestions?
--
Todd A. Jacobs
Network Systems Engineer
inetd is not recommended anymore.
One feature of inetd which is heavily used by tcp-wrappers is that it passes the first
argument as argv[0] which is usually the command itself.
Therefore you have to remove the single tcp-env after the command line, this will read:
smtp stream tcp nowait qmaild /path/to/tcpd /var/qmail/bin/tcp-env
/var/qmail/bin/qmail-smtpd
Thomas
Heisenberg may have slept here...
-------------------------------------------------
T h o m a s Z e h e t b a u e r ( TZ251 )
PGP encrypted mail preferred - KeyID 96FFCB89
mail [EMAIL PROTECTED]
-------------------------------------------------
PGP signature
On Mon, 11 Oct 1999 [EMAIL PROTECTED] wrote:
> One feature of inetd which is heavily used by tcp-wrappers is that it
> passes the first argument as argv[0] which is usually the command
> itself. Therefore you have to remove the single tcp-env after the
> command line, this will read: smtp stream tcp nowait qmaild
> /path/to/tcpd /var/qmail/bin/tcp-env /var/qmail/bin/qmail-smtpd
I tried your suggestion, but the same thing happened as before: the remote
site connects, but the localhost closes the connection after about 3
seconds.
I *did* read the install guides, and while it recommends tcpserver for
heavily-used environments, my needs aren't so great. I really don't want
to have to run a seperate service for this.
--
Todd A. Jacobs
Network Systems Engineer
Hello,
I'm having this kind of error message when delivering to a virtual email:
1999-10-11 14:41:34.825523500 starting delivery 12402:
msg 165908 to local [EMAIL PROTECTED]
1999-10-11 14:41:34.825537500 status: local 1/10 remote 20/20
1999-10-11 14:41:34.851102500 delivery 12402: failure:
Sorry,_no_mailbox_here_by_that_name._(#5.1.1)/
I noticed that all virtual emails with '.' (i.e. civil.engg) has this error.
Is there a work-around on this? I just migrated from Sendmail to Qmail and
never expected this would happen.
Thanks.
_Bench
On Mon, 11 Oct 1999, Benjamin de los Angeles Jr. wrote:
> I noticed that all virtual emails with '.' (i.e. civil.engg) has this error.
> Is there a work-around on this? I just migrated from Sendmail to Qmail and
> never expected this would happen.
It's documented. Use ':' instead of '.' when setting up local aliases, and
the incoming dots will get handled properly.
--
Todd A. Jacobs
Network Systems Engineer
Thanks, but now I'm trying to give a supervised qmail-send a HUP signal by
svc -h /var/supervise/qmail/send but it won't work, my virtualdomains file
is not reread.
Regards,
_Bench
On Mon, 11 Oct 1999, Todd A. Jacobs wrote:
> On Mon, 11 Oct 1999, Benjamin de los Angeles Jr. wrote:
>
> > I noticed that all virtual emails with '.' (i.e. civil.engg) has this error.
> > Is there a work-around on this? I just migrated from Sendmail to Qmail and
> > never expected this would happen.
>
> It's documented. Use ':' instead of '.' when setting up local aliases, and
> the incoming dots will get handled properly.
>
> --
> Todd A. Jacobs
> Network Systems Engineer
>
>
George Hong writes:
> 1. I have qmail, qmail-smtpd, qmail-pop3d directories under directory
> /var/lock/qmailsvc with run script in each directory. When I run svscan
> in /var/lock/qmailsvc, the processes will all be invoked and work. If I
> put it in the script, it will give the error message and fails:
Are you sure that svscan can find supervise in $PATH?
> 2. The second question is that it doesn't write to the log file, all
> the message will be displayed at the console window.
svscan takes care of DIR/log only when DIR is sticky.
--
Tetsu Ushijima
Ng Hak Beng <[EMAIL PROTECTED]> schrieb/wrote:
> After looking through the archive, is checkpassword able to authenticate
> shadow passwords? I've got a RH 6 box running qmail, but I don't seem to
> be able to authenticate through pop3.
Yes, it works with shadow passwords. Have you installed checkpassword
(which is aspearate package) and checked all programme paths and
paramters?
--
Claus Andre Faerber <http://www.faerber.muc.de>
PGP: ID=1024/527CADCD FP=12 20 49 F3 E1 04 9E 9E 25 56 69 A5 C6 A0 C9 DC
