Hi Rich,
To explain: once upon a time, many mail system operators made at least
a good-faith effort to support the "postmaster" role address, and to
at least read -- if not answer -- messages sent there. With the advent
of mega-providers, we've seen that disappear. I happen to think that
this is unprofessional and unethical: one should never build something
that one isn't capable of running properly. But my sentiments aside,
this is the reality we face.
And because we face it, we no longer operate in an environment where
queries to postmaster personnel will likely generate a response. We're
left with either (a) figuring it out on our own (b) consulting other
email people and hoping one of them has already figured it out or
(c) trying to page someone via the mailop or nanog mailing lists.
Totally agree with you on the postmaster address, even the email
address(s) in the whois information can't always be relied on.
We do however live in the real world were many constantly
want what they want without thinking why they want what
they want, and having no regard for others outside there little
empires.
The approach of "Hey, could you grep this message-id through
your logs and tell me what just happened?" is pretty much dead.
I find myself learning about and using as much header-carried
data as I can in order to diagnose problems, or -- in some cases --
to try to ascertain if a problem even exists or where it might be.
So to borrow a word from part of Dave's message that I elided,
I find this "premature".
I think it's only the 'little' guy, or oldtimers like myself that
are still happy to help others when we can with diag
information from checking logs. I often use my logs first
because trying to extract header information from a 'normal'
email recepient isnt always easy. Though now I basically have
to keep header information for the Australian government that
shouldnt be such a big problem now.
As an aside: I think this kind of approach is becoming more useful
by the day, as I'm firmly convinced that [most] message-body scanning
is becoming less useful by the day.
I have disabled general email body scanning except for
phishing and mismatching URL's on my server, to
many problems and false positives with general body
scanning.
Many spammers-for-hire and other unethical mail system operators now
embed tracking links in their messages. These are unique URLs keyed
to some tuple of {recipient address, message, etc.} and of course
their activation reveals recipient IP address, mail/web client version,
possibly recipient OS type/version, timestamp, etc. This form of spyware
is becoming increasing pervasive, to the point where I think it's worth
noting that all the header redaction in the world (and all the on-the-wire
and message-body encryption) will fail to protect recipient privacy as
long as this technology is extent and as long as recipients insist on
using web-capable mail clients.
I firmly believe that if you start removing the obvious forms of
header information, then those that need that information for
more than diagnostic reasons will simply do something that is
not so obvious and is easier to both overlook and hide in the
general body of the email. Another way of looking at it is dont
give the unethical mail system operator a reason to change
their MO, it only forces you the ethical operator to work harder
or faster to spot the next method of obfuscation, tracking. or
misdirection.
To me privacy is important in the body of an email, the headers
are no different than a physical email with an address and chain
of custody, though it goes without saying that all tracking except
the last server the email went through are not always 100%
trusted, the important of diagnostic information should never
be discounted.
Header information is also important for local anti-abuse
systems such as you and others mentioned, I use it for
manual additions to my servers filtering, others use it
to add to automated filtering systems, the more untainted
header information, the lower the false positive hits.
Cheers
Ian Manners
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp