Jump to content

Would appreciate opinion on this header


bobbear

Recommended Posts

Most of my spam comes from my Tiscali UKaddresses. On examining the email header source code I generally find that my address appears nowhere in the header, e.g:

Return-Path: <uwsystqe[at]hotmail.com>

Received: from DXz7Ts (83.29.77.21) by mk-cpfrontend.uk.tiscali.com (7.0.024.3-1)

id 410B1DBD004171B4; Mon, 2 Aug 2004 22:31:52 +0100

Message-ID: <410B1DBD004171B4[at]mk-cpfrontend-5.mail.uk.tiscali.com> (added by postmaster[at]uk.tiscali.com)

From: Timothy Ward <uwsystqe[at]hotmail.com>

To: boban[at]tiscali.co.uk

Subject: whats up!?

X-Mailer: Becky! ver. 2.00.07

Organization: bandgap woodland

Date: Mon, 02 Aug 2004 17:31:52 -0400

Mime-Version: 1.0

Content-Type: multipart/alternative;

boundary="--8707112655361121"

(That To: Tiscali address is not mine). Obviously the Tiscali pop3 server has to know in what mailbox to place the spam, so it must have been tagged with my address at some point but is apparently not displayed. Is this a normal server configuration? I only seem to see this behaviour on the Tiscali server.

This is often raised on the Tiscali forums and the usual reply from their support staff is that the spam must have been sent using a bcc field which is easily disproved - emails sent using the bcc field still show the delivery address in the top line of the source code.

Any mail server configuration gurus around?

Link to comment
Share on other sites

using a bcc field which is easily disproved - emails sent using the bcc field still show the delivery address in the top line of the source code

Huh? Actually, the BCC: data is carried within the envelope, which is normally not seen at all at the end-user level. There may be lines like Undisclosed Recipients:, there might even be a line that is BCC: but blank, on and on, but these variances are more based on the e-mail server application's characterisitcs and the actual e-mail (envelope) structure and contents, some of which are "manipulated" by the other servers involved in the e-mail flow from point A to your InBox.

If you really want an "e-mail server expert" .. you'd have to at least start with identifying just what e-mail server app you're talking about. However, as above, I don't think this is needed for your query.

Link to comment
Share on other sites

Huh?  Actually, the BCC: data is carried within the envelope, which is normally not seen at all at the end-user level.  There may be lines like Undisclosed Recipients:, there might even be a line that is BCC: but blank, on and on, but these variances are more based on the e-mail server application's characterisitcs and the actual e-mail (envelope) structure and contents, some of which are "manipulated" by the other servers involved in the e-mail flow from point A to your InBox.

If you really want an "e-mail server expert" .. you'd have to at least start with identifying just what e-mail server app you're talking about.  However, as above, I don't think this is needed for your query.

14609[/snapback]

Ok, I'm afraid I can't answer the query on what server app. Tiscali are running, sorry, but I'm downloading my mail from the Tiscali pop3 server using OE6. Just to show the difference here is a message sent from my OE6 with my Tiscali address in the bcc field only, then downloaded back into OE6 from the Tiscali pop3 server, (as was the previous message, by the way). In other words it's just an ordinary bcc message to me[at]tiscali.co.uk from a separate domain:

Return-Path: <me[at]metronet.co.uk>

Received: from mail.metronet.co.uk (213.162.97.75) by mk-cpfrontend.uk.tiscali.com (7.0.024.3-1)

id 410A532E002B7EB4 for me[at]tiscali.co.uk; Tue, 3 Aug 2004 22:44:17 +0100

Received: from bobs (unknown [213.162.000.00])

by mail.metronet.co.uk (MetroNet Mail) with SMTP

id AAAA642FEC0; Tue, 3 Aug 2004 22:43:59 +0100 (BST)

Message-ID: <001e01c479a2$fafb90f0$527da2d5[at]bobs>

From: "Bob" <me[at]metronet.co.uk>

To: "Bob" <me[at]virgin.net>

Subject: Bcc test: Tiscali address in bcc field only. App: OE6

Date: Tue, 3 Aug 2004 22:43:17 +0100

MIME-Version: 1.0

Content-Type: multipart/alternative;

boundary="----=_NextPart_000_001B_01C479AB.44FE46E0"

X-Priority: 3

X-MSMail-Priority: Normal

X-Mailer: Microsoft Outlook Express 6.00.2800.1437

X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441

As you can see, the email address of the addressee (me[at]tiscali.co.uk) appears in the final server received information, whereas for spam I receive on the Tiscali pop3 server there is absolutely nothing in the source code as listed by OE6 to identify me as the recipient - I just wondered why this was??

Link to comment
Share on other sites

As you can see, the email address of the addressee (me[at]tiscali.co.uk) appears in the final server received information, whereas for spam I receive on the Tiscali pop3 server there is absolutely nothing in the source code as listed by OE6 to identify me as the recipient - I just wondered why this was??

Because spammers often put one address at a given domain in the "To" and then all the others in a BCC, which you wouldn't see (hence "Blind" in Blind Carbon Copy).

dt

Link to comment
Share on other sites

That's an interesting observation. I don't have time to see if that happens to me, but I think that sometimes it does. However, I don't think that it probably has any significance. Often, I think, that it happens when my mail server inserts (misconfigured) into the headers. Some spammers and/or their trojans don't always do things quite correctly - close enough to get them delivered, but not really the way it should be done.

Miss Betsy

Link to comment
Share on other sites

Because spammers often put one address at a given domain in the "To" and then all the others in a BCC, which you wouldn't see (hence "Blind" in Blind Carbon Copy).

dt

14615[/snapback]

Thank you David, but as you can see from my second test example, where I sent a message to myself with me[at]tiscali.co.uk in the bcc field, putting addresses in a mail client bcc field, (OE6 in this case), may hide them from the casual observer by not displaying them in the recipient displayed fields, but it does not prevent them being displayed in the source code. The bcc function is intended to hide from the main recipient the fact that his email has been copied to someone else, such as his boss for example, rather than to hide from the recipient whoever sent the email to him/her.

<dbiel>When you parce the spam, do you see anything different in the headers compared to viewing the headers in OE? Good point, but no, there is no difference in the displayed headers in the parser window.

On the face of it, it's a bit like getting a blank, addressless envelope pushed in your snail-mail box - normally when that happens, you know that the Post Office themselves are distributing the junk mail as a blanket service.......

This lack of any delivery information only appears in spam received by me from the Tiscali.co.uk pop3 mailserver.

Link to comment
Share on other sites

That's an interesting observation.  I don't have time to see if that happens to me, but I think that sometimes it does.  However, I don't think that it probably has any significance.  Often, I think, that it happens when my mail server inserts (misconfigured) into the headers.  Some spammers and/or their trojans don't always do things quite correctly - close enough to get them delivered, but not really the way it should be done.

Miss Betsy

14627[/snapback]

Thank you for your ideas, Miss Betsy. You could well be right - it may be a deliberate misconfiguration by the spammer/trojan/bot, although any recipient information is missing from the vast majority, (but not all), of the spam I receive from the Tiscali server, (i.e. my address appears nowhere in the headers) and at the end of the day the pop3 server has to know which individual mailbox to put the mail in, unless of course there is a commercial blanket mailing of some sort going on.

Link to comment
Share on other sites

Basically, it is due to the structure of the SMTP protocol.

The simplest message that can be delivered is as follows. Color is user input. This message creates no to: field in the resulting message. The complete headers of this message are displayed below. Basically, because SMTP is a "trusted transfer", only the server really knows where the message is supposed to go.

Try this sample on your own server and see if it is accepted.

telnet mail.kopin.com 25

220 mail.kopin.com ESMTP Service (Lotus Domino Release 5.0.12) ready at Wed, 4 Aug 2004 08:39:59 -0400

helo batman.kopin.com

250 mail.kopin.com Hello batman.kopin.com ([192.168.1.25]), pleased to meet you

mail from:user[at]example.com

250 user[at]example.com... Sender OK

rcpt to:sunderwood<at>kopin.com250 sunderwood<at>kopin.com... Recipient OK

data

354 Enter message, end with "." on a line by itself

this is a test

.

250 Message accepted for delivery

quit

221 mail.kopin.com SMTP Service closing transmission channel

Connection to host lost.

Received:  from batman.kopin.com ([192.168.1.25])          by mail.kopin.com (Lotus Domino Release 5.0.12)          with SMTP id 2004080408404949:2182 ;          Wed, 4 Aug 2004 08:40:49 -0400

$MIMETrack:  Itemize by SMTP Server on KopinPost/KOPIN CORPORATION(Release 5.0.12  |February 13, 2003) at 08/04/2004 08:40:56 AM,MIME-CD by Notes Client on Steve Underwood/KOPIN CORPORATION(Release 5.0.12  |February 13, 2003) at 08/04/2004 08:55:22 AM,MIME-CD complete at 08/04/2004 08:55:23 AM

SMTPOriginator:  user[at]example.com

From:  user[at]example.com

PostedDate:  08/04/2004 08:40:56 AM

$UpdatedBy:  CN=KopinPost/O=KOPIN CORPORATION

$Orig: 

Categories: 

$Revisions: 

RouteServers:  CN=KopinPost/O=KOPIN CORPORATION

RouteTimes:  08/04/2004 08:40:56 AM-08/04/2004 08:40:57 AM

$MsgTrackFlags:  0

$MessageID:  <OF412B7F87.8FF9E4E0-ON85256EE6.0045AAAA[at]LocalDomain>

DeliveredDate:  08/04/2004 08:40:57 AM

Link to comment
Share on other sites

Basically, it is due to the structure of the SMTP protocol.

The simplest message that can be delivered is as follows.  Color is user input.  This message creates no to: field in the resulting message.  The complete headers of this message are displayed below.  Basically, because SMTP is a "trusted transfer", only the server really knows where the message is supposed to go.

Try this sample on your own server and see if it is accepted.

14633[/snapback]

Thanks for that Richard - very interesting. I've been out all day & just picked it up so I need to think about it and have a play as you have suggested and see what results I get as I'm not sure I understand why it won't create a 'For' addition after the delivery mail server receipt message, (or even what that is normally derived from), but I appreciate what you are saying.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...