On Thu, Jan 15, 2009 at 07:38:17PM +0100, Alessandro Vesely wrote:
Yet, attentive postmasters are not omniscient. They need a data feed.
It's called "their own log files". Those who do not pay attention to
what's in them are highly unlikely to pay attention to anything else.
Having an appropriate error message is not enough. It is also necessary
to deliver that message to the right operator. Delivering error messages
to end users may be counter productive. For a non-viral example, what can
users do if their mail is bounced because of bad DKIM signatures?
Nothing. Again, it's up to mail system administrators to read their
own log files and act (if necessary) on what they find. I would
think a log file full of SMTP rejects with "Hey, your DKIM signature
is wrong" would get their attention. If not -- hey, if they don't care,
why should anyone else?
That's exactly why I proposed a meta channel: to direct error messages
to someone who can act appropriately.
But there's no point in going through all the debate and design
and implementation and deployment effort associated with this.
The same people who are presently ignoring their own log files
will ignore this too.
A much easier way to reach that subset of postmasters who are actually
paying attention is to use appropriately verbose messages in rejection
messages. For example:
message rejected
isn't nearly as helpful as
message rejected; our antivirus scanner detected Blottosplang; contact
jan2009(_at_)example(_dot_)com if you believe this is an error and reference
case 1234abcde
where of course jan2009(_at_)example(_dot_)com is unfiltered and forwards to the
mailbox(es) of the right people. It also changes periodically because
not only will it be harvested by spammers and targeted, but because
every now and then someone's truly broken system will spew a backlog
of several hundred no-longer-relevant messages at it.
This is a better method because (a) it avoids generating more SMTP
traffic (b) it's much harder to game and (c) it caters the most to
the people who are paying the most attention: those who are monitoring
their mail server logs in real time and (d) it utilizes what we already
have without the need to invent or deploy new technology.
There *are* issues with it: for example, information leakage (do you
really want to tell the world *which* virus scanner you're running?) and
non-standardization of error messages, for starters. But the former
is addressed by some judicious local choices, and the latter with Perl.
---Rsk
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg