Douglas Campbell wrote:
the bounce e-mail contains virtually NO information to allow
me to backtrace. Any ideas?
If you're 100% sure that the original spam wasn't sent by "you"
(i.e. malware on your system) you can report the "backscatter"
with SpamCop. A "minority" thinks that this is bad without SPF
FAIL policy, but this "minority" is somewhat limited (= me ;-).
I've just realized that the .forward capability in sendmail
operates differently than my MUA, thunderbird, does when I
manually forward..
Yes, "forward", "bounce", and "sender" are confusing terms,
everybody has its own definition. When you "forward" manually
with a MUA, it's normally MAIL FROM you, and it can be
- "resend" (MUA adds Resent-* header fields, see RfC (2)822)
- a mail with MIME Content-Type message/rfc822 (your header +
the forwarded mail with the complete original header)
- dito with Content-Disposition "attachment" (OE can do this,
bad idea but mostly harmless)
- dito multipart/digest, one or more message/rfc822 parts plus
optionally other parts (like a text/plain part where you can
say why you forwarded one or more complete mails ;-)
- dito multipart/mixed, almost the same, only a different
default type for the one or more parts: the digest default
is message/rfc822, and the mixed default is text/plain.
- pseudo-forward, calendar software like Outlook abused as MUA
could create a single part, your text, followed by a ruler,
old From / Date / Subject (most other header fields AWOL),
followed by the body of the original mail (if it was plain
text, no idea how bad it gets for other content types)
- in theory you (= your MUA) could also forward multiple mails
in one of the many mbox formats (MIME type application/mbox)
OTOH when talking about SMTP "forward" generally means one MTA
sending stuff as is to the next hop, adding a timestamp line
(Received header field).
That can be on the side of the "sender" (MUA = MTA to MSA, MSA to
"mailout") or on the side of the receiver (secondary MX to
primary MX, MX to MDA, maybe a separate AV-MTA before the MDA).
And of course it can be between "sender" (last mailout MTA) and
receiver (first MX on his side). These cases of "forwarding"
are all sane as far as SPF is concerned, if the "sender" has
enumerated all IPs of his "mailouts" (sending border MTAs), and
the receiver checks SPF at his border, not behind it.
"RTFM" is all it takes (e.g. the primary MX should white list
the secondary MX, the latter "forwards" mails to the primary).
Also no problem for mailing-lists, when they redistribute mails
(another case of "forward"), they use their own MAIL FROM to
catch error messages. That case is messy with PRA (SenderID).
The most interesting case of "forward" is "251 user not local",
because then the mail is sent to a 3rd party. If the forwarder
kept the original MAIL FROM as proposed in RfC 1123 5.3.6(a) it
breaks: Error messages won't go to the responsible party (i.e.
the forwarder), and if the MAIL FROM was forged they also don't
go to the originator (as mandated by 2821), they hit innocent
bystanders. RfC 1123 5.3.6(a) forwarding is broken by design.
Why is the automated process different from the manual one?
It used to work before 1123, keep almost everything as is, add
host to MAIL FROM (reverse path), add timestamp line, use new
RCPT TO, ready.
Then they eliminated the "unnecesary" routing crap, after all
why should the final recipient C route error messages via the
forwarder B, if it could send it directly to an originator A ?
The subtle problem identified more than a decade later, the
poor A never was the originator. It's a "mission impossible",
a bug, they screwed up when they tried to eliminate routing.
I'm coming to the conclusion from my own bounce message
problems that bounce messages are intrinsically bad, because
they can easily be turned into a third party DOS issue.
IBTD. Numerous things can go wrong in SMTP. It's a "simple"
protocol, no rocket science, it doesn't work very well if mail
routinely vanishes in black holes instead of reporting errors.
The "intrinsically bad" thing are forged Return-Paths, and SPF
allows (or rather asks) to _reject_ FAIL. Bounces to SPF PASS
never hit innocent bystanders, they are good.
I've thought of adding abuse(_at_)aol(_dot_)com to a .forward file in
my postmaster account, given that they are hosting the
spamvertised website's portal page and refuse to take it down
Fighting abuse with abuse is often a very bad plan. Bye, Frank
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg