Bouncing Mail

Bouncing Mail

Post by Frederick Barne » Sun, 22 Jun 1997 04:00:00



Hello all,

I need to have some method of forcing a mail-bounce. Ideas tried to far:

Create a large file in the users home-dir to produce a hard-write fail
when the quota runs out.

Create a .mail.lock, but procmail will remove this after n seconds, or if
n = 0, it will try forever.

Try chmodding the .mail to 000, result, causes it to be renamed to
BOXUS.xxxx and therefore no good.

Chmod the users home dir to 000, result, needs more permissions than can
be safely allowed. - and other admin overheads

Does anybody have any ideas that might work ?

Many thanks,
  Fred.

+----------------------------------------------------oOOo--oOOo----+
| Fred Barnes, CS Student, Canterbury, UK.                         |

| http://stue030/ (UKC only)  http://www.geocities.com/~dr_barnes/ |
+------------------------------------------------------------------+

 
 
 

Bouncing Mail

Post by Andrew Giert » Sun, 22 Jun 1997 04:00:00


[off-topic; followups to poster only]

 Frederick> Hello all,

 Frederick> I need to have some method of forcing a mail-bounce.

You mentioned procmail; if you set EXITCODE in a procmail recipie
to a non-zero value, a bounce is generated (even if the mail was
delivered successfully).

By choosing the right values for EXITCODE, you can even control
what the error reported in the bounce is. See /usr/include/sysexits.h
for possible values (e.g. 67 = no such user, 77 = permission denied,
etc.)

--
Andrew.

comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>

 
 
 

Bouncing Mail

Post by James Spence » Thu, 26 Jun 1997 04:00:00


I was wondering how to read and analyse the memory files /dev/kmem and
/dev/mem... I have read several articles that suggest writing programs to
analyse these files, but it gives no indication as to how... any
assistance would be greatly appreciated and i apologise in advance if
this question is too basic or otherwise inappropriate for this newsgroup..

 
 
 

Bouncing Mail

Post by Steffen Ja » Thu, 26 Jun 1997 04:00:00


: I was wondering how to read and analyse the memory files /dev/kmem and
: /dev/mem... I have read several articles that suggest writing programs to
: analyse these files, but it gives no indication as to how... any
: assistance would be greatly appreciated and i apologise in advance if
: this question is too basic or otherwise inappropriate for this newsgroup..

  % man mem

mem(7D) -------------------- Devices --------------------- mem(7D)

NAME
     mem, kmem - physical or virtual memory

SYNOPSIS
     /dev/mem
     /dev/kmem

DESCRIPTION
     The file /dev/mem is a special file that is an image of  the
     physical  memory  of  the computer.  The file /dev/kmem is a
     special file that is an image of the kernel  virtual  memory
     of  the computer.  Either may be used, for example, to exam-
     ine, and even patch the system.

     Byte addresses  in  /dev/mem  are  interpreted  as  physical
     memory  addresses.   Byte  addresses in /dev/kmem are inter-
     preted as kernel virtual memory  addresses.   References  to
     non-existent  locations  cause  errors  to  be returned (see
     ERRORS below).

     The file /dev/kmem accesses up  to  4GB  of  kernel  virtual
     memory.   The  file  /dev/mem  accesses physical memory; the
     size of the file is equal to the amount of  physical  memory
     in  the  computer.   This  can  be larger than 4GB; in which
     case, memory beyond 4GB can be accessed using  a  series  of
     read(2)  and write(2) commands or a combination of llseek(2)
     and read(2) and write(2).

ERRORS
     EFAULT         Bad address.  This error can occur when  try-
                    ing   to:   write(2)  a  read-only  location,
                    read(2) a write-only location, or read(2)  or
                    write(2)   a  non-existent  or  unimplemented
                    location.

     ENXIO          This error results from attempting to mmap(2)
                    a  non-existent  physical  (mem)  or  virtual
                    (kmem) memory address.

FILES
     /dev/mem       File containing image of physical  memory  of
                    computer.
     /dev/kmem      File  containing  image  of  kernel   virtual
                    memory of computer.

SEE ALSO
     llseek(2), mmap(2), read(2), write(2)

NOTES
     Some of /dev/kmem  cannot  be  read  because  of  write-only
     addresses or unequipped memory addresses.

-- SunOS 5.5.1 ----------------------- Last change: 18 Mar 1994 --

--
It's not a bug. It's a feature!

 
 
 

Bouncing Mail

Post by Peter Kelle » Sat, 28 Jun 1997 04:00:00


[snip]
: This is highly system dependant. mainly because the layout of core memory
: will vary a lot from system to system. It is now accepted that this is
[snip]

: I would say that this sort of thing is not worth the bother, unless you are
: particularly *ic.

I *am* *ic and I would like to know where I could find
information like that. I've looked around, but I'm comming to
the conclusion that it is proprietary info and not released anywhere.
Any help in locating /dev/mem layouts for any OS release would be
really helpful. There's magic in them thar bits.

-pete

 
 
 

Bouncing Mail

Post by Steffen Ja » Sun, 29 Jun 1997 04:00:00


: I *am* *ic and I would like to know where I could find
: information like that. I've looked around, but I'm comming to
: the conclusion that it is proprietary info and not released anywhere.
: Any help in locating /dev/mem layouts for any OS release would be
: really helpful. There's magic in them thar bits.

Perhaps you can start with debugging the kernel image, e.g. on SunOS

  % adb -k /vmunix /dev/mem

There are some answerbook for this topic. To get the symbol space look at
the object file format, e.g. elf(3e). Also have a look at the more general
pseudo devices ksyms and kstat.

Enjoy!  ;-)

--
It's not a bug. It's a feature!

 
 
 

Bouncing Mail

Post by Villy Kru » Fri, 04 Jul 1997 04:00:00



>I *am* *ic and I would like to know where I could find
>information like that. I've looked around, but I'm comming to
>the conclusion that it is proprietary info and not released anywhere.
>Any help in locating /dev/mem layouts for any OS release would be
>really helpful. There's magic in them thar bits.
>-pete

Start with a nm listing of /unix or /vmunix or whatever the name of the
kernel is.  Then plough through all the files in /usr/include/sys to
get the layout of the verious structures.  For each structure you need
to find the offsets of the structure members so you would be able
to relate this to a hex dump fo /dev/kmem.  If your system comes with
the crash utility this would be a helpful starting point.

There used to be a book written by Bach: The Design of the UNIX Operating
System Prentice Hall 1986  
 which describes the internal structure of t System V rel2 version. If you
can find that book get it.

 
 
 

Bouncing Mail

Post by Steffen Ja » Sat, 05 Jul 1997 04:00:00


: There used to be a book written by Bach: The Design of the UNIX Operating
: System Prentice Hall 1986 which describes the internal structure of t
: System V rel2 version. If you can find that book get it.

Bach's book is really fine written, but not up to date. Of course it is
best to understand the general architecture of UNIX.

Two other references:

  Berny Goodheart, James Cox: The Magic Garden Explained. Prentice
    Hall, Englewood Cliffs, 1994.

  Chris Drake und Kimberly Brown. Panic! - UNIX System Crash
    Dump Analysis. Prentice Hall, Upper Saddle River, 1995.

--
It's not a bug. It's a feature!

 
 
 

Bouncing Mail

Post by Peter Kelle » Wed, 09 Jul 1997 04:00:00



:  
: >
: >I *am* *ic and I would like to know where I could find
: >information like that. I've looked around, but I'm comming to
: >the conclusion that it is proprietary info and not released anywhere.
: >Any help in locating /dev/mem layouts for any OS release would be
: >really helpful. There's magic in them thar bits.

: >-pete

: Start with a nm listing of /unix or /vmunix or whatever the name of the
: kernel is.  Then plough through all the files in /usr/include/sys to
: get the layout of the verious structures.  For each structure you need
: to find the offsets of the structure members so you would be able
: to relate this to a hex dump fo /dev/kmem.  If your system comes with
: the crash utility this would be a helpful starting point.

[snip]

I wonder if a perl tool can be written to do that for me..... Just give
it all of the information about the nm dump and the kernel structures.
It actually might be pretty fun to attempt to write somthing like that. It
would really add to debugging the kernel....maybe. The script would
have to understand about C syntax and what not but it might not be too
hard. I mean you can already find C yacc grammers and such fairly easily.
ok, so I'm an optomist, it'll prolly have to be written in C.

-pete

 
 
 

1. procmail: WHat is the standard idiom for bouncing mail?

I am away from my references, but I remember having done this in the past.
(I thought it would be in either "man procmailrc" or "man procmailex", but
it isn't).

Anyway, I am using:

:

{
        EXITCODE=77
        HOST=done

But I can't quite remember if that is right.  What exactly is the
significance of the 77?

2. RCS global repository

3. Bouncing Mails

4. Set up VPN client

5. Sendmail bounces mail ... please help!

6. JAVA RPM Dualality

7. Spam/Bounce-Mail

8. SGI <-> Linux

9. alfie@dcs.warwick.ac.uk bounced mail

10. bounced mail/dns resolution

11. Bounced mail

12. bounced mail/dns resolution

13. Bouncing mail from a certain sender.