Re: Mail-related comments in ACM risks

--On 2000-02-19 01.21 -0800, ned.freed@innosoft.com wrote:

> You're right, it is nonsense. The idea is to get two lists bouncing mail
> back to each other. But this only works if the lists put their address in
> the envelope from of the bounce message. Not only would this be a
> standards violation, it would be a terribly dumb thing to do.

The internal mail system at Tele2 did this...which afterwards is a quite
funny story:

- The outgoing mail MTA had a limit of size of 5 MB for a message.
- Incoming MTA had no limit at all.
- I created a forwarding feature from this mail system on my account
  to my email address on the internet (yes, we do NOT talk about internet
  mail here)
- Someone sent me a message which was 10 MB large

I could say that the rest is left as an exercise to the reader...but here
we go:

The incoming MTA pass the mail over to my mail account. The forwarding
mechanism forwarded the mail (added about 100k of junk) and sent the mail
to my internet address. The outgoing MTA stopped the mail because of size
and sent a bounce back to the sender, i.e. my forwarding mechanism, as they
act as an agent for the user itself (added about 200k of junk telling what
happened). The forwarding mechanism on my account got this message, and
forwarded it to my internet account.

...

Two days later they called me and asked why I don't delete email on this
mail system. I told them nicely that I don't use it at all, but promised to
have a look.

Luckily the system is slooooow (runs on a specific operating system which
probably should not handle this kind of things) so it had only filled one
raid with about 12GByte of repeated messages.

I did "select all - delete", which was an operation which took some 2
hours(!) after which the software on my client side crashed. Reboot, and
select-all-delete again and 30 minutes later the mail was gone.


I got a very specific email address after this which doesn't even try to
send the message to my mail account from the incoming MTA...

     paf

Received on Saturday, 19 February 2000 05:09:56 UTC