[top-posting]
Thanks for your informative post, Rich. Interesting. It puts some
interesting light on the issue.
I have to tell you though, even if I accept all your reasoning, I still
dislike the notion as it just seems snobbish behaviour to me, which I
don't like. I prefer blunder to attitude.
Gadi.
On 7/12/10 2:40 PM, Rich Kulawiec wrote:
> On Sun, Jul 11, 2010 at 02:13:51AM +0300, Gadi Evron wrote:
>> Mail clients handle dups well, as do mailing lists. Two layers of
>> protection again the horrible double messages.
>
> Ah, but it's not quite that simple, unfortunately.
>
> The proper way to filter (or file) mailing list traffic is via
> RFC 2919's "List-Id" header. The funsec list is run via Mailman,
> which automagically inserts that header unless overridden by the
> list-owner, so all messages traversing the list carry it. Off-list
> replies to on-list messages don't -- and shouldn't.
>
> Which means that anyone who is correctly dealing with funsec traffic --
> that is, using the List-Id and not the subject-line tag (a bad idea in
> itself, but let's gloss over that for the moment) will likely send
> on-list traffic to one file/folder, and off-list traffic to another.
> So given that duplicate messages arrive asynchronously and are disposed
> of differently, duplicate detection is something that a mail client
> is not likely to be able to handle.
>
> In addition: modern mailing list mechanisms (like Mailman) permit
> subscribers to join lists from multiple addresses and to set a "nomail"
> flag on any or all of those. It's not uncommon for subscribers to use
> this to receive of list messages at one address but to gain posting privileges
> from another. (Since nearly all mailing lists don't permit, or at
> least don't permit with owner approval, traffic from non-subscribers.)
> Thus there is no way for any other subscriber to know that "the address
> that onlist messages from subscriber S come from" is also "the address
> at which S receives list traffic". And of course if they *do* differ,
> than duplicate replies will result in mail to different addresses,
> possibly on different servers and handled by different mail clients.
>
> And in addition to that, there's the hairball of SMTP filtering,
> including greylisting and other mechanisms: since the duplicate copies
> originate from different hosts on different networks, there's no way
> for senders to know if they'll be treated differently. A subscriber
> may have exempted linuxbox.org from greylisting but not other subscribers'
> outbound mail relays, so it's quite possible for on-list messages to
> arrive considerably in advance of off-list duplicates. Or vice-versa.
> The same is true of other SMTP filtering mechanisms in the path,
> which may or may not handle both copies the same way, and some of which
> may or may not be under the control of subscribers. (While it's likely
> a safe presumption to guess that subscribers who *do* control those
> mechanisms have taken steps to ensure delivery of on-list traffic, it's
> not a safe presumption to ensure that they've done the same for off-list,
> especially since there's really no way for the to know where it's going
> to come from.)
>
>> What *most* mail clients do not do is handle reply-to-list well
>> (practical + non annoying).
>
> Well, true, but I think that argues for choosing a better mail client
> or for modifying the current one (whether via configuration, if possible,
> or code, if necessary).
>
> Any decent mail client will present the key headers (From, To, Cc, Bcc,
> Subject, Reply-To) for editing so that senders can appropriately modify
> all of them (or not) before sending. Thoughtful and clueful senders
> will take into consideration proper netiquette and deal with them,
> as much as they'll trim quoted material or take other steps to minimize
> not only the total mail traffic, but the inconvenience to recipients.
> And that last is what proper netiquette is really about: being frugal
> with the use of others' resources, especially their time.
>
> ---Rsk
> _______________________________________________
> Fun and Misc security discussion for OT posts.
> https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
> Note: funsec is a public and open mailing list.
>
--
Gadi Evron,
[email protected].
Blog: http://gevron.livejournal.com/
_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.
