On Thu, 14 Jul 2005, Mark Nipper wrote:
> On 14 Jul 2005, Michael Haardt wrote:
> > out of the blue, I am getting a bunch of mails with a very deep MIME
> > nesting and an "email-info.scr" file inside.
[...]
> > Any idea what that crap is?
>
> I'd also be very interested in feedback on this issue as
> I've had the exact same situation crop up just recently.
I've generally found that the first step when confronted by such stuff
is to type the offending attachment filename into a search engine and
see what comes up. This seems to be no exception, and a mere glance
at the first two or three hits at google indicates that this is almost
certainly a phishing attempt.
> This results in an error message which the remote side encapsulates
> in one additional layer of MIME, and then tries to attempt delivery
> again to my end!
Are you implying that the envelope sender of the original abusive mail
is one of your own email addresses? Then that would seem to be quite
a reasonable handle on which to catch it in the first place, without
even proceeding to the DATA stage and AV scanning.
> As far as I've read, the remote end is in error here and
> should have stopped attempting delivery after the first 5xx level
> error message resulting in an undeliverable message or some such
> frozen in the remote SMTP queue.
In this kind of situation where the remote MTA hasn't managed to
identify the item as abusive, I'd expect it to compose a non-delivery
report (i.e with a null envelope sender) addressed to the original
envelope-sender. At that point, the chain should stop. If it
doesn't, something is very wrong at their end.
If in fact it's composing these non-delivery reports with non-null
envelope senders, then we'd blacklist those envelope senders as being
a misuse of mail procedures. If it's obvious that the reports are
being generated by bogus virus alert software - most recent example
seen here being Symantec_AntiVirus_for_SMTP_Gateways@??? - then
we have a specific rejection message for them, otherwise we'd just use
our routine blacklisting message (and possibly inform their
postmaster, if we deemed it beneficial to us to do so).
As a general comment, we experience quite a number of problems with
sites at which our users have email addresses which they've forwarded
to us - sites whose anti-abuse measures are significantly less
effective than ours. In effect, the forwarding MTA is "laundering"
abusive mail, and offering it to us in a way that defeats several of
our normal anti-abuse measures, mostly those which take effect without
the overhead of having to actually scan the data. We've tried several
strategems to deal with a few of the sites that are of most importance
to our users, but none of the strategems have been without their
problems, I'm afraid.
best regards
