Delivery Notification Failure spam

[patrickg]

I received a spam this morning that spam cop reports as "Nothing to do" after submitting for parsing.

The spam is disguised as a Delivery Notification Failure and was emailed to me from what appears to be a legitimate ISP - and it had no problems passing our spamassassin filter.

However, what makes it strange is, it is plainly a spam for the dreaded V drug with image src links and links to site all intact.

Other than in the final (actual) header where it is addressed to me (patjr_at_galadv_dot_com) nowhere else in the presumably forged prior headers is my IP or domain mentioned which would implicate the final sender (in my small mind anyway).

Here is the tracking url: http://www.spamcop.net/sc?id=z2712492826z6...d388067cf33c7bz

My question is can the spamcop parsing engine be defeated by simply disguising a spam as a Delivery Notification Failure? Has this been addressed in the past? - I was unable to find anything exactly like this, my apologies if so. I had some time, I'm curious and I figured I'd post, thanks for taking a look.

[rconner]

I have a feeling that this might be a bona-fide bounce from galaeren.se. However, if so, it is a "delayed bounce" so it went to the Reply-To or From in the original message, rather than straight back to the mail host that delivered it (you could check the header that appears in the last MIME part, it may have your address in thse fields -- we can't tell because SpamCop munges this in tracking links).

As for your main question, I've no idea why the parser simply threw up its hands on this one.

We know that SpamCop can parse bounces, because I've reported hundreds of delayed bounces through it over the years.

-- rick

[patrickg]

I have a feeling that this might be a bona-fide bounce from galaeren.se...(you could check the header that appears in the last MIME part, it may have your address in thse fields -- we can't tell because SpamCop munges this in tracking links)....

Thanks for reply Rick. Yes, it might be legit, but I really suspect perhaps not.

I checked the headers again and even the body looking for my ip/domain, the only place it appears is in the final galaerans header to me. That really made me think it was they that intended to send it. I'm far from expert on this, but if the first header in the path isn't forged it looks like it was originally sent from an IP that is listed in cbl.abuseat (92 dot 102 dot 120 dot 184) for galaeren.se. Their filter scored it as junkmail and returned a final recipient failed 5.1.1 message. That leads to 3 things in my mind: why would it bother scoring an email if the recipient didn't exist and why would it respond to me and not the 92 dot etc... ip; and finally, don't notifications edit or truncate the original content? So if my reasoning is correct here (I'd be the first to be surprised if it was) that leaves galaerens as the spammer, yet spamcop gave up on it and my spamassassin scored it okay. It strikes me as an unusual email (at least to me) and just worth posting for comment..... Thanks again.

[Wazoo]

I received a spam this morning that spam cop reports as "Nothing to do" after submitting for parsing.

Can't tell what happened at this point, as your Tracking URL is currently pointing to a 'live' report, with a target provided for the Report. It actually needs to be 'handled' ....

Other than in the final (actual) header where it is addressed to me nowhere else in the presumably forged prior headers is my IP or domain mentioned which would implicate the final sender (in my small mind anyway).

Quite on the other hand, I'll say that it not 'disguised' at all ... this really is a (delayed) bounce/rejection message. As far as why you received it ... note the following lines as seen from the "View entire message" link in your Tracking URL ...

Return-Path: <x>

Received: (qmail 7317 by uid 275); Thu, 19 Mar 2009 02:46:04 +0100

Message-Id: <20090319034604.7319.qmail[at]Jojo-Factory>

To: <x>

Subject: RE: UK Pharmacy Message 54936

From: VIAGRA ® Official Site <x>

Three instances where 'your' e-mail address was forged into the original spam .. assumedly it was the From: or Return-Path: line used to generate the 'bounce' message ... which is defined in these parts as a "MisDirected Bounce" ....

My question is can the spamcop parsing engine be defeated by simply disguising a spam as a Delivery Notification Failure? Has this been addressed in the past?

This submittal was the Bounce/Rejection notice, and that's just what the parser analyzed. The actual/original spam has been packaged up as an attachment within that 'bounce' e-mail .... the parser doesn't analyze the source or specific contents of an attachment. (Yeah this might be confusing, as e-mail submittals need to be configured in a certain way, usually described as "Forward as attachment" .. but taken in that light, the 'original' spam in this case would end up being an attachment to/under the attachment .. a sub-level to deep for the parser's purpose and intent.)

[rconner]

Thanks for reply Rick. Yes, it might be legit, but I really suspect perhaps not.

I checked the headers again and even the body looking for my ip/domain, the only place it appears is in the final galaerans header to me. That really made me think it was they that intended to send it. I'm far from expert on this, but if the first header in the path isn't forged it looks like it was originally sent from an IP that is listed in cbl.abuseat (92 dot 102 dot 120 dot 184) for galaeren.se. Their filter scored it as junkmail and returned a final recipient failed 5.1.1 message. That leads to 3 things in my mind: why would it bother scoring an email if the recipient didn't exist and why would it respond to me and not the 92 dot etc... ip; and finally, don't notifications edit or truncate the original content? So if my reasoning is correct here (I'd be the first to be surprised if it was) that leaves galaerens as the spammer, yet spamcop gave up on it and my spamassassin scored it okay. It strikes me as an unusual email (at least to me) and just worth posting for comment..... Thanks again.

Having a little trouble following the above. Let me possibly insult you with an elementary description of delayed bouncing, maybe this will ring a bell.

1. Spammer creates spam message.
   
2. Spammer uses some host somewhere (not yours, probably a zombie) to contact someone else's incoming mail host (MX).
   
3. Spammer tells MX he has a message to deliver, and that it is from YOUR address (i.e., he forges your address into the MAIL FROM: command of SMTP).
   
4. MX host accepts the message without further ado.
   
5. The spammer (and his stolen mail host) then hang up and go away, with their mission accomplished.
   
6. Recipient's MX hands the message to a mail delivery host. The mail delivery host looks at the message and decides (1) that it is spam, and (2) that it does not want to finish delivery of the message for this reason.
   
7. Mail delivery host cannot contact the host that delivered the message (it and the spammer are long gone). In order to follow standard practice and issue a nondelivery notice, the ony thing that the delivery host can do is to compose an e-mail message back to the From address, which is -- wait for it -- YOU.
   
8. You receive what appears to be a genuine, bona-fide bounce message for a message that you never sent.
   
9. Your IP addresses (as well as those of your provider) will not appear in the headers of the original message, because (of course) these addresses were not involved in the sending of the spam.
   
10. Your e-mail address will appear (obviously) in the To field of the bounce, but also likely in the From: field (or Return-Path or Envelope-From) of the message that is being bounced. If the bouncing delivery host includes the full header of the bounced message (as this one did) you will be able to see this.
    

I think bounces can contain complete e-mail packets; in fact, I believe that this used to be standard practice until spam (and misidrected bouncing) became common.

Nobody here cares much for delayed bounces, but many services persist in using them. Those that do are just trying to be compliant with SMTP, which requires acknowledgment of nondelivery back to the sender. Recently, the SMTP RFC was updated, and I believe that it now relaxes the rule: you do not have to send a bounce if you suspect spam or other mail abuse.

-- rick

[Lking]

Now that I've had some time to look at the URL you provided, I think nothing is the correct thing to do. this is a spam/bounce message has been around the block twice, your report would be the third.

It is hard to tell how/where your address came from with all the SpamCop munges. But here is what I see.

Starting at the bottom:

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

To: <x>

Subject: RE: UK Pharmacy Message 54936

From: VIAGRA ® Official Site <x>

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

the VIAGRA spammer sent email TO: <X> . After X's system (SpamAssassin) evaluated the message about "RE: UK Pharmacy..." the spam evaluation was added, the subject was changed to *****spam***** ... and the delayed spam evaluation was sent to another x at galaren.se

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

Received: from localhost by galarensrv01.Galaren.local

with SpamAssassin (version 3.0.2);

Thu, 19 Mar 2009 12:58:58 +0100

From: VIAGRA ® Official Site <x>

To: <x>

Subject: *****spam***** RE: UK Pharmacy Message 54936

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

Now when postmaster[at]galaren.se got the message with a bad address they bounced it to you.

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

From: postmaster[at]galaren.se

To: x

...

Subject: Delivery Status Notification (Failure)

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

You then sent the delivery notification to SpamCop. SpamCop chose to do nothing.

Do you have spamassassin? It appears to me that SpamCop has munged you address in the original "RE: UK Pharmacy" message. == the <X>'s in the To: and Return-Path: ==

Now I see Wazoo's answer. I'm learning.

[patrickg]

Thanks for reply Wazoo, but I think spamcop's "munging", as everyone so eloquently refers to it, is making this more difficult for me to explain than I expected.

Quite on the other hand, I'll say that it not 'disguised' at all ... this really is a (delayed) bounce/rejection message. As far as why you received it ... note the following lines as seen from the "View entire message" link in your Tracking URL ...

Return-Path: <x>

Received: (qmail 7317 by uid 275); Thu, 19 Mar 2009 02:46:04 +0100

Message-Id: <20090319034604.7319.qmail[at]Jojo-Factory>

To: <x>

Subject: RE: UK Pharmacy Message 54936

From: VIAGRA ® Official Site <x>

Three instances where 'your' e-mail address was forged into the original spam .. assumedly it was the From: or Return-Path: line used to generate the 'bounce' message ... which is defined in these parts as a "MisDirected Bounce" ....

Is that an actual copy and paste from what you see Wazoo? I ask because the header above does not quite match what I copied and pasted in the parser. But in the header area that most closely matches above, the "x's" in question are all galaeren - is that what you expected or did you think it would be my domain name galadv or gallagheradvertising dot com (and I really wish it wasn't so close in similar domain name to mine ) )

This submittal was the Bounce/Rejection notice, and that's just what the parser analyzed. The actual/original spam has been packaged up as an attachment within that 'bounce' e-mail .... the parser doesn't analyze the source or specific contents of an attachment. (Yeah this might be confusing, as e-mail submittals need to be configured in a certain way, usually described as "Forward as attachment" .. but taken in that light, the 'original' spam in this case would end up being an attachment to/under the attachment .. a sub-level to deep for the parser's purpose and intent.)

The email was all in line, as far as I can tell there was no attachment. I copied the raw source and pasted it into the parser window as usual. And if you're sure it's a legitimate return notification, why would it come to me? I am confused, it seems this stuff is beyond me. Thanks for yours and everyone's attention though, much appreciated, it's how I learn.

[Wazoo]

Is that an actual copy and paste from what you see Wazoo?

Yes, exactly as I 'see' it ...

From the top .. the parser attempts some munging to try to protect your identity .. in this case the e-mail address found in the To: line of the e-mail you submitted was selected for the munging action. So when I then see the "<x>" entries further down in the data, it is taken to mean that your e-mail address was originally placed within the headers of the actual spam. Ig that 'embedded' data didn't matc up with your e-mail address, that data woudn't have been munged by the parser (of course, this would also suggest that you wouldn't have seen the bounce notice either <g>)

Possibly confusing is that you might actually still see your r-mail address in the "live" parse results. Blame that on the fact that my logged-in cookie data doesn't match yours, so it's known to the parser that I didn't submit this spam. After this report is "handled" and this Report goes to "storage" no one will see your e-mail address in the data, as only the munged version is stored.

The email was all in line, as far as I can tell there was no attachment. I copied the raw source and pasted it into the parser window as usual.

Your (received) portion of the submitted e-mail contains:

Content-Type: multipart/report; report-type=delivery-status; boundary="9B095B5ADSN=_01C9A8899BB5978800000019mail.galaeren.se" (formatting changed by this Forum application)

Notice the multipart/report bit ... this is important, as the "attached" issue comes up further down in the body of what you submitted, the actual/original spam bit showing up under the MIME boundary section defined as;

------------=_49C23382.F3E20000

Content-Type: message/rfc822; x-spam-type=original

Content-Description: original message before SpamAssassin

Content-Disposition: attachment

This is in contrast to the previous section, containing the "spam analysus" section;

------------=_49C23382.F3E20000

Content-Type: text/plain

Content-Disposition: inline

This where I used the "attachment to an attachment" scenario ....

And if you're sure it's a legitimate return notification, why would it come to me?

Again, based on what I "see" the munging action of the parser replaced all instances of your e-mail address seen in the To: line of the bounce e-mail throughout the rest of the header and body content ... so when I see the "<x>" items in the headers of the 'original' spam, that says t me that your e-mail address was forged into the Ro:. From:, and Reply-To: lines of the original soam ... that's why it was 'returned' to you, using the "delayed / MisDirected Bounce" scenario described by others (and in the FAQs, Wiki, etc.) ....

Had the original spam been handled "correctly" (in today's environment) it would have had the connection dropped by the mail.galaeren.se server and that would have been the end of that e-mail.

[rconner]

And if you're sure it's a legitimate return notification, why would it come to me?

The usual reason would be that the spammer stole your e-mail address and used it as the from-address of his spam (see this wiki page). You would never learn of this until the spam is delivered to a mail system that practices delayed bouncing, then this system sends a DSN to your e-mail address because it has no other way to signal nondelivery. This happens to me (and many others among us here) every couple of months or so. Sometimes I get hundreds of them in a week.

If the Return-Path in the header of the original spam (down near the bottom of the message) is an address that belongs to you, then this is clearly what happened. If this Return-Path is not your address, then I'm stumped.

-- rick

[Wazoo]

Note: off-Topic for the original question, yet somewhat partially connected due to the initial "parsing result" description and my initial check of the suggested Tracking URL results...???

Can't tell what happened at this point, as your Tracking URL is currently pointing to a 'live' report, with a target provided for the Report. It actually needs to be 'handled' ....

Interesting ..... now I'm seeing the "Nothing to do message" .... very strange ...

OK .. oddities abound ... when I started this, was running IE7 under Win-XP-Home on this system. I'd powered it down, upgraded from 256Meg of RAM to 1Gig ... re-booted to Ubuntu, fired up FireFox and ran into the "Nothing to do" situation.

OK, copied off the data as seen feom "View message source", slid the data over a 'Synergy' connection to a Win-XP-Pro system, once again using IE7 .. pasted the data into the web-form and got the result;

http://www.spamcop.net/sc?id=z2713045246zf...25bc0dd201f9c9z

Report spam to:

Re: 217.13.226.83 (Bounce)

To: abuse[at]dgc.se (Notes)

Canceled this Report, but 'replays' of that Tracking URL end up with showing a Report target address.

Yeah, I'm confused at the moment .... different parsing servers have been touched, but the same parser servers have offered both of the different results .. leaving the only significant difference being between the browser/Operating System differences, which should have direct impact on the parsing system results ... very, very strange. (OK, there might be something happening in the copy/paste operation, possibly the Linux to Windows cross-over?? ... still looking at that)

Again, starting poster's Tracking URL -> http://www.spamcop.net/sc?id=z2712492826z6...d388067cf33c7bz

My Tracking URL, same data -> http://www.spamcop.net/sc?id=z2713045246zf...25bc0dd201f9c9z

Just checked both under Ubuntu/FF .. same results ... mine shows a target, original shows "nothing to do"

Windows/IE7 ... mine shows a target, original came up "live"

However, I did see a difference in servers ....

Nothing to do servers -> sc-app2, sc-app9, sc-app11

Live parse result server -> sc-app6

All servers showing the same data line:

<!-- 05look $Revision: #1 $ produced by sc-app2 -->

<!-- 05look $Revision: #1 $ produced by sc-app11 -->

<!-- 05look $Revision: #1 $ produced by sc-app9 -->

<!-- 05look $Revision: #1 $ produced by sc-app6 -->

Don/Deputies contacted ... however, having to note that the timing sucks, as we are right on the cusp of the postponed and postponed again hardware maintenance and software upgrades to the Reporting system ....

[SpamCopAdmin]

http://www.spamcop.net/sc?id=z2712492826z6...d388067cf33c7bz

I'm sorry, but I don't understand what the fuss is all about.

The email at issue is a delayed bounce that parses just fine for me. SpamCop correctly recognizes it as a delivery failure notice.

The final recipient address is different than the address the bounce was sent to. I don't know why.

217.13.226.83 has been sending bounces to our traps, too.

- Don D'Minion - SpamCop Admin -

.

[Farelf]

...I'm sorry, but I don't understand what the fuss is all about. ...

The unexpected termination to the parse most of us are seeing is:

Tracking message source: 217.13.226.83:

Routing details for 217.13.226.83

[refresh/show] Cached whois for 217.13.226.83 : abuse[at]dgc.se

Using abuse net on abuse[at]dgc.se

abuse net dgc.se = abuse[at]dgc.se

Using best contacts abuse[at]dgc.se

Message is 20 hours old

217.13.226.83 not listed in dnsbl.njabl.org

217.13.226.83 not listed in dnsbl.njabl.org

217.13.226.83 not listed in cbl.abuseat.org

217.13.226.83 not listed in dnsbl.sorbs.net

217.13.226.83 not listed in accredit.habeas.com

217.13.226.83 not listed in plus.bondedsender.org

217.13.226.83 not listed in iadb.isipp.com

Nothing to do.

- except, apparently, on server sc-app6 (I confirm the unexpected termination shows on sc-app1, sc-app7, sc-app8, sc-app10 and sc-app12 too). The variance of sc-app6 from the others is causing consternation too (haven't observed it myself, haven't pulled up that server yet¹).

On http://www.spamcop.net/sc?id=z2712492826z6...d388067cf33c7bz , to confirm the 'version'.

If you are not seeing 'Nothing to do' do you see the report sent/cancelled or still open (live)?

¹ [On edit] Oops no, just snagged sc-app6 and it is now showing the same as the others - early termination. But at one stage it was showing reports unsent, ready to go. Apparently. Perhaps just a momentary glitch as Wazoo has demonstrated normal parsing on re-try.

[patrickg]

Received another one this morning. Same exact email, same parse result.

Anyway, I have posted the complete raw text of yesterday's email and a jpeg screenshot of the previewed email (below the raw text email) to my website here galrenspam

if you'd like to see the un-munged version.

The only place I see my email address is in the bounce header. I still don't comprehend how a legitimate bounce would be sent to my address if it was never shown in any of the other headers. Perhaps posting the email on my website will shed some further light? Thanks.

[rconner]

Received another one this morning. Same exact email, same parse result.

Thanks for posting the web page. I see the quandary now -- the original message was "from" sales[at]mumblemumble and also "to" this same address, with this address appearing once again as the Reply-To. This address presumably is not one of yours.

If this were truly a delayed bounce, then galaren should have sent this to themselves, not to you, there's nothing that explicitly links you with them. I have no idea how this mail would have been sent to you in a bounce.

I still can't quite believe that it is an elaborately-concocted spam, but I'm not sure what to believe anymore, especially since it appears that we are still getting the "nothing to do" at the bottom of the SpamCop parse (or at least that is what I get). As you can see, this latter point has kicked off a bit of an investigation.

Please be sure to take the web page down after the smoke has cleared and everyone here has seen it, so it won't be harvested.

-- rick

[patrickg]

Thanks for posting the web page. I see the quandary now -- the original message was "from" sales[at]mumblemumble and also "to" this same address, with this address appearing once again as the Reply-To. This address presumably is not one of yours.

You presume correctly - galaren is not one of mine.

If this were truly a delayed bounce, then galaren should have sent this to themselves, not to you, there's nothing that explicitly links you with them. I have no idea how this mail would have been sent to you in a bounce.

As a bounce, yes, galaren should have sent it to themselves - simply put and I think the crux of what I was trying to spit out myself. Thanks Rick.

I still can't quite believe that it is an elaborately-concocted spam, but I'm not sure what to believe anymore, especially since it appears that we are still getting the "nothing to do" at the bottom of the SpamCop parse (or at least that is what I get). As you can see, this latter point has kicked off a bit of an investigation.

Please be sure to take the web page down after the smoke has cleared and everyone here has seen it, so it won't be harvested.

Yes, I'll take page down in a few days. (I'm not too concerned with harvesting as we receive so much spam as it is, I don't think there's any spammer left who hasn't harvested it already )

Kidding aside, my thought was if this is indeed a spam, then it got past all my defenses pretty easily. Uh oh.

Moderator Edit: fixed quoting tag problem, removed excessive use of vertical whitespace

[Farelf]

Received another one this morning. Same exact email, same parse result.

Anyway, I have posted the complete raw text of yesterday's email and a jpeg screenshot of the previewed email (below the raw text email) to my website here galrenspam

if you'd like to see the un-munged version. ...

Thanks. Again, that data parses fine - only indenting the line continuations it produces http://www.spamcop.net/sc?id=z2715230377zd...6edb4ec931626dz for me (auto munged by SC). Whatever is causing the parser to choke when you do it is issue #1. I can see no cause, offhand.

...The only place I see my email address is in the bounce header. I still don't comprehend how a legitimate bounce would be sent to my address if it was never shown in any of the other headers. Perhaps posting the email on my website will shed some further light?

You're right, that thing looks bogus. From: postmaster[at]galaren.se - bloke doesn't know the name of his own domain! But maybe he just has a short attention span. Trying to bounce to VIAGRA ® Official Site <sales[at]galaeren.se> on behalf of <sales[at]galaeren.se> could do that to a robot. Of course he has completely lost track of the likely source - 92.102.120.184

This might have started as an 'ignorant' bounce by a MailwWasher-wielding BCC recipient to the apparent sender which was rejected by galaeren.se for spam content. Where you came into it is anyone's guess. Maybe you were another BCC and 'near enough is good enough' for (some of) that bunch.

[edit] Oh yeah, and then maybe the ignorant bouncer bounced the bounce (leading to the collation of in-line and attachment parts). That almost fits. This could go on for some time.

[patrickg]

This might have started as an 'ignorant' bounce by a MailwWasher-wielding BCC recipient to the apparent sender which was rejected by galaeren.se for spam content. Where you came into it is anyone's guess. Maybe you were another BCC and 'near enough is good enough' for (some of) that bunch.

[edit] Oh yeah, and then maybe the ignorant bouncer bounced the bounce (leading to the collation of in-line and attachment parts). That almost fits. This could go on for some time.

Hmmm, looks like my quotes broke to Rick above for some reason - I'm dangerous on the web.... I just wanted to draw pictures not become a computer techie. But thank you Farelf and all others who put their time and effort in to this. Seems there's not much more to see from that email for me. It certainly had me stumped though. Pesky these bounces. Cheers!

[StevenUnderwood]

If this were truly a delayed bounce, then galaren should have sent this to themselves, not to you, there's nothing that explicitly links you with them. I have no idea how this mail would have been sent to you in a bounce.

I'm not sure about that, though it would be unusual... is it not possible that the original was sent with a "MAIL FROM:" patrick's address which was not placed in the headers, but was still known to the system when the non-delivery was noticed and used to send the bounce?

[rconner]

I'm not sure about that, though it would be unusual... is it not possible that the original was sent with a "MAIL FROM:" patrick's address which was not placed in the headers, but was still known to the system when the non-delivery was noticed and used to send the bounce?

Could be. I noticed that there was a Return-Path in the top line of the original spam header, it was the same as the From and To in this message. I assumed that this would come from the MAIL FROM, and that it would be the address to which a bounce would be sent, but of course this appears not to have been the case.

-- rick

[ccronan]

I am getting a number of what appears to be "delivery notification failure" .

(Actually I get about 100 messages a day as spam. I think this happened because I insulted a spammer.)

Anyway, I am getting messages of nondelivery with no id of who I non-delivered to, but claims it is coming from my ISP (postmaster[at]isp, etc.) and ALWAYS a 28K zip file attached, no way will I open that.

What is this called? I have received 5 or 6 of them over the last few days.

Is there a topic for these?

Thanks.

[rconner]

Is there a topic for these?

Try this wiki page. It describes a very common occurrence on the net, the forgery by spammers of from-addresses in their mailings. If this doesn't seem to describe your situation, then you might start your own topic. Patrickg's case was a bit stranger than normal, not simple from-address forgery.

-- rick

[Miss Betsy]

I am getting a number of what appears to be "delivery notification failure" .

(Actually I get about 100 messages a day as spam. I think this happened because I insulted a spammer.)

Possibly. However, lots of people get as many without any direct contact with a spammer.

Anyway, I am getting messages of nondelivery with no id of who I non-delivered to, but claims it is coming from my ISP (postmaster[at]isp, etc.) and ALWAYS a 28K zip file attached, no way will I open that.

While you are looking at the wiki page about Misdirected Bounces, you might also search for 'Tracking URL' - your description creates a lot of questions. It may not be a bounce at all, but a spam that uses your ISP postmaster address as sender and NDR as the subject so that you will open it.

What is this called? I have received 5 or 6 of them over the last few days.

If it is a Misdirected Bounce, you are lucky only to get 5 or 6. Some people get hundreds!

Is there a topic for these? Thanks.

Once you have figured out whether this is a typical or atypical Misdirected Bounce or an ordinary spam that uses forged FROM and subject to fool you, then you will know whether to start a new topic or continue in this topic or some other.

Miss Betsy