Re: sender rewriting scheme

Meng Weng Wong <[email protected]> wrote:
> Is there a better solution to the .forward problem than sender rewriting?

  We should say explictly that the body of the message will never be
touched.

> This is huge.  They are innocent bystanders caught in the crossfire of
> our consent system.

  No, there are not.  Mostly because we are not designing a consent
system.

  If recipient MTA's determine as local site policy that they do not
accept email which they can trivially tell is forged, that's their
business.  If individuals sending email to those MTA's don't like it,
too bad.

  Part of any consent system is the idea that *all* parties consent.
The whining (quite frankly, bitching) I hear from roaming users is
that they want to send messages DESPITE any recipient MTA policy which
refuses forged messages.  This means that the roaming users idea of
"consent" is that they do whatever the hell they want to do, and
everyone else has to like it.

  Such attitudes are indistinguishable from spammers, and I have zero
patience for them.  My response to their complaints is "Don't talk to
me, talk to the MTA who's refusing your messages."


  Hmm... as a side idea, any solution we propose should include errors
messages describing WHY a message was rejected.  This allows the
sender to determine how to change his behaviour, in order to comply
with the consent requirements of the recipient.

  We probably also need a published statement that the MTA is looking
for that consent.  e.g. part of the information available via the
consent system for a recipient MTA is that it does ASRG-RMX lookups,
and denies messages which don't follow the spec.  This statement makes
it easier for senders to determine consent.

  Alan DeKok.