ietf-asrg
[Top] [All Lists]

Re: [Asrg] Re: bounceone

2006-12-15 07:37:02
Frank

Many thanks for your comments; some thoughts of mine inline.

Tom Petch


----- Original Message -----
From: "Frank Ellermann" <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
To: <asrg(_at_)ietf(_dot_)org>
Sent: Thursday, December 14, 2006 9:57 PM
Subject: [Asrg] Re: bounceone


Tom Petch wrote:

Less good is
postmaster@<domain-name>
since, while technically correct, it is unlikely to convey the
meaning clearly to a lay user, especially as the <domain-name>
may be unknown to the user.

I think you want to say that there should be a display name like
"Mail Administator" in addition to the postmaster@ address, is
that correct ?

Yes, my terminology is sloppy; I mean that there should be a display name and
not just an e-mail address and especially not the destination e-mail address of
the original e-mail (as some do)


Other e-mail addresses are likely to mislead.

+1  Whatever it is, they must be ready to get "manual" replies
at this address, if there's no separate Reply-To.

perhaps, a SMTP trace eg
----- Transcript of session follows -----
... while talking to mail.example.com:
DATA
<<< 554 5.7.1 virus Exploit.HTML.IFrame detected
554 5.0.0 Service unavailable

Somebody, maybe AOL, but I'm not sure, managed it to note the
alleged MAIL FROM nowhere, that's bad.   I can determine it,
it ends up in an X-Envelope-To, but that's unreliable.  This
point is of course moot if the bounce contains the complete
header _with_ (forged) Return-Path somewhere, but normally
it's only the complete header _without_ Return-Path.  Yes, I
use one of those funny catchall vanity host mailboxes.


Yes, in my message 'bouncetwo', the ones I classify as v112 all have an AOL
address in them and a X-AOL-... in the original message headers.  They have
text/rfc822-headers but the headers look as if they have been edited removing
the lines that would appear before the first 'Received:'; others do this too (eg
Internet Mail Server).

At the very least, the extract from the original mesage must
contain "From:", "To:" and "Date:".

NAK, complete header, no compromises, unless it's monstrous,
a loop of Received lines until one party crashed or similar.

It should contain the entire message header

SHOULD as near to a MUST as possible.

I am looking at this from the viewpoint of the lay user who gets a 'reply' to a
message that they never sent, so what I was trying to convey was that the
immediately visible part should make sense to the lay user - From, To, Date -
while what the professional needs - the complete header - can be in a different
part, as message/rfc822 or text/rfc822-headers.  Giving a lay user all the
'Received:' etc could increase the confusion.

particularly the earliest "Received:" to show where the
message entered the system.

It allegedly entered the system there.  In reality it entered
the system later, the bottom timestamp lines were preloaded by
the spammer / worm author, more or less plausible.


This is the bit that intrigues me; I was expecting forged 'Received:' and I
don't see them; often there is but one 'Received:' which cannot then be forged
(?); in other cases, the additional 'Received:' tie in with the header of the
DSN and so look genuine to me.

To date, such bodies are in excess of 20kbyte so providing
up to 10kbyte runs no risk of propagating a virus

After MyDoom (spring 2004) my ISPs blocked or deleted almost
all worms.  Until then the limit went down to 12,000 bytes,
that's for 1200 + 8100 * 4/3 (B64).  IIRC Sober was quite small.

Ah, I was ignorant of that; I know an IETF mail list that has a 10kb limit and
was trusting them to have done their homework.

Another approach would be to truncate bodies at the first line
starting with TV or UE (credits for that trick to JohnL).  Or
any potential B64 crap that's not a potential MIME text part.

note that while message headers are currently one or two kbyte,
they are steadily increasing in size with the advent of
anti-spam procedures such as SPF and DKIM.

SPF doesn't add message header fields, at least not on the side
of the sender.  Spammers trying in vain to preload Received-SPF
is an idea, but it's futile, receivers would either ignore it
if they normally don't get it, or pick the top Received-SPF as
inserted by their own side.  And Received-SPF is fairly small.

For DKIM it's another issue, so you better state your limits
for the copied part of the body, excl. the complete header, or
you have two limits, with say 8100*4/3 for the body.  Or less.

In Spamcop reports I use POP3 "TOP 10" (first ten lines of the
body) plus complete header.  So far no abuse desk complained
that they needed more... :-)

Yes, I was trying to keep it simple and using sloppy terminology; complete
header plus n lines of body is a better approach.  There are a number of headers
I do not recognise eg 'X-Habeas-SWE-' which I take to be anti-spam traps.  Also,
I am proposing this as a good idea for all DSN, including genuine ones to
genuine mail which could have SPF and DKIM in them.  (I agree that SPF is
usually small).

a "Content-Type:" of 'message/rfc822' will be treated as an
attachment

If some broken UAs do this it's their problem.  Content-Type and
Content-Disposition are in essence unrelated.  A MIME part is a
MIME part, it's not necessarily an attachment.  Please don't use
Microsoft (or rather OE) terminology, they don't understand MIME,
it's a hopeless case.

Weeelll, there is one software provider whose UA products are in use by
ninety-something point something of the world's workstations, and they are the
ones at which the 'lay users' mostly sit; hence my descent into the language of
the 'hopeless cases'.  I do not see Content-Disposition used in the DSN at all
except where it is part of the original message (the worm is an attachment) so
what I am describing is what I am seeing, text/rfc822-headers displayed in the
body and message/rfc822 not.  Is there a default behaviour for
Content-Disposition described somewhere? (I don't see it in eg RFC3462).

'message/rfc822' suitable for the (truncated) original message
with the headers of the original message included as a
"Content-Type:" of 'text/rfc822-headers'.

Sending the complete header twice is a bad idea.  The truncated
message/rfc822 is fine, it contains the complete header.  You'd
use text/rfc822 only in conjunction with something that is _not_
message/rfc822.

Finally the body should identify the software that is generating
the bounce message.

That should go into the reporting header, as User-Agent or similar,
not as part of the Subject.  Admittedly I add the id. of the tool
truncating bodies (the "TOP 10" mentioned above) below that body,
but that's a kludge.  For some time it was a complete URL, until I
reported my own site as "spamvertized", then I changed it for naive
users incl. me... :-)

Frank



_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg