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 ?
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.
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.
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.
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.
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... :-)
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.
'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