> On Thu February 24 2005 13:14, [email protected] wrote:
> > RFC 2821 does distinguish between SMTP systems that don't modify messages
> > (relays) and ones that do (gateways).
> You are correct that gateways are not only permitted to modify content,
> they are required to ensure that address fields contain content which
> is "effective and useful for sending replies" (RFC 2821 sect. 3.8.4).
> Indeed, that is one of the reasons that use of an invalid or
> unresolvable domain name is not a viable option.
> In the case of either anonymity or lack of an Internet mailbox,
> "sending replies" isn't a possibility (except in the latter case
> given a Reply-To field). I can address this issue more fully in
> the next revision.
> > To the extent that message
> > modification impinges on missing From fields, I believe they do so by filling
> > in the field with "something". Common choices for "something" include:
> >
> > (0) The envelope from address (if present).
> > (1) An address derived from available authentication information. (The
> > information can come from SASL AUTH, TLS, or even some entirely
> > external mechanism like RADIUS.)
> > (2) A known-bogus address (e.g., missing-address@missing-domain)
> > (3) A mail administrator address of some sort.
> >
> > The only one of these that poses a significant problem is (1) since it can have
> > the effect of revealing exactly the information the sender needed to have
> > hidden. The others mostly have nuisance value and nothing else. (1) is a real
> > risk and needs to be called out in the draft, but I don't think the practice is
> > so common that by itself it will preclude deploying this change.
> Either (0) or (1) could defeat anonymity,
(0) only comes into play if the envelope from contains information about the
sender, in which case there is no anonymity to be had.
> but they are predicated
> on transport mechanisms. The draft is intended to address the
> message format issues rather than transport of the content (some
> transport mechanisms have an envelope or use authentication; others
> do not).
> > Another major problem is that the draft as written deals with the technical
> > issue of making From: optional but doesn't discuss the myriad security issues
> > that surround the idea of anonymous email. IMO it is borderline irresponsible
> > (*) to publish a document that discusses this one small aspect of email
> > anonymity while not providing any guidance about the more general set of issues
> > here. If this is to move forward this material needs to be provided - possibly
> > by a companion document.
> [...]
> > (*) It is precisely because the potential consequences of breach of anonymity
> > are so grave that this omission is of such great concern.
> Yes, as noted above it deals with the message format rather than
> transport (including non-email transport of Internet Message Format
> messages such as via Usenet).
> Point taken; the next revision will mention the possibility of
> transport mechanisms leaking information under security
> considerations.
OK.
> > Even if you
> > assume SpamAssassin is the norm and that using the absence of a From: field as
> > a check for possible spam doesn't happen at all currently, all it would take
> > would be a major influx of spam without From: fields to change this. And I
> > somehow doubt that arguments that this breaks the ability to send mail
> > anonymously will impress the folks that build anti-spam software much if at
> > all.
> If a particular user or set of users wishes to ignore anonymous
> messages, they are of course free to do so; it may indeed be the
> case that any such messages received by some such users(s) would
> be considered spam. On the other hand, recipients who might
> reasonably expect to receive anonymous messages would almost
> certainly not use anti-spam software that discards such messages.
Unfortunately this is just not the way things are headed. Users are
increasingly not able to control these sorts of actions being done on their
behalf. For example, Sun filters all incoming mail and summarily discards
everything it thinks is spam. (In fact a recent misconfiguration led to a bunch
of mail being discarded incorrectly.) I have absolutely no control over this -
no way to change filter threshholds, no personal whitelist, no Bayesian
training, no option to file spam in a spam folder, nothing. And while it is
perhaps true that I wouldn't want and have no business receiving anonymous mail
sent to my Sun account, I deal with large ISP setups all the time and I can
tell you that many if not most of them are similarly set up and are similarly
inflexible.
Of course it is hard to tell when the ubiquity of such setups reaches a point
where it truly compromises the general ability to send anonymous email. But my
guess is that if we haven't passed that point yet we're about to.
Ned
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.