Generating Mail-Followup-To: headers

Generating Mail-Followup-To: headers

[Matt Armstrong]

I forget the status of Gnus support for generating Mail-Followup-To:
headers.  Is somebody planning to implement this?

I took a several month long hiatus from Gnus to try to learn what all
the fuss with mutt was all about.  I'm back (addicted to auto scoring
and automatic message expiration), but I miss mutt's ability to
generate Mail-Followup-To:.

It seems like it would be fairly easy to mimic mutt's feature set here
through message-send-hook.  If nobody steps forward, I will probably
give it a try.

-- 
matt

Re: Generating Mail-Followup-To: headers

[Paul Jarc]

Matt Armstrong <matt@lickey.com> wrote:
> I forget the status of Gnus support for generating Mail-Followup-To:
> headers.  Is somebody planning to implement this?

I am.  I wasn't planning to do it as a plain hook function because I
figured it should be on by default, but I have the impression hook
variables ought to be nil by default.  That will make it a bit
hairier, but still doable.

I'm thinking something in gnus-msg.el, during initialization of a new
message buffer, can detect when there is a to-list or to-address
parameter for the current group; if so, it'll add a header field like
"X-Gnus-Generate-MFT: yes" (by default; it could be disabled by
setting some variable).  Then when we send the message, if that field
is present, we remove it, and if there is also no existing MFT, then
we add one based on To+Cc.

If you want to have a go at it, feel free.  I'm not sure when I'd get
around to it.


paul

Re: Generating Mail-Followup-To: headers

[Matt Armstrong]

prj@po.cwru.edu (Paul Jarc) writes:

> Matt Armstrong <matt@lickey.com> wrote:
>> I forget the status of Gnus support for generating Mail-Followup-To:
>> headers.  Is somebody planning to implement this?
> 
> I am.  I wasn't planning to do it as a plain hook function because I
> figured it should be on by default, but I have the impression hook
> variables ought to be nil by default.  That will make it a bit
> hairier, but still doable.
> 
> I'm thinking something in gnus-msg.el, during initialization of a
> new message buffer, can detect when there is a to-list or to-address
> parameter for the current group; if so, it'll add a header field
> like "X-Gnus-Generate-MFT: yes" (by default; it could be disabled by
> setting some variable).  Then when we send the message, if that
> field is present, we remove it, and if there is also no existing
> MFT, then we add one based on To+Cc.
> 
> If you want to have a go at it, feel free.  I'm not sure when I'd
> get around to it.

I think the hardest part is determining which lists the user is
subscribed to.  I don't think to-address is sufficient.

I have several groups into which multiple mailing lists get dumped.
For example, all my work e-mail gets dumped into a single group, but
there are 10-20 frequently used work mailing lists.  And very low
volume lists just end up in my main inbox group.  So the to-address
parameter is not sufficient to express all the lists I'm on.

And if we're not relying directly on to-address, I think this can be
put into the 'message' package.

I was thinking of a global variable holding all subscribed lists --
just a list of addresses:

     (setq message-subscribed-addresses '("ding" "postfix-users"))

There could even be utility functions that read ~/.lists (for Qmail
users) and that goes through all the Gnus group parameters looking for
to-address parameters, as well as extracting stuff from
gnus-parameter-to-address-alist.  This could be controlled by a list
of functions that produce additional addresses:

    (setq message-subscribed-addresses-functions
          '(message-subscribed-addresses-qmail
            gnus-get-subscribed-addresses))

With this list available, all Mail-Followup-To: generation can be done
right before the message is sent.

-- 
matt

Re: Generating Mail-Followup-To: headers

[Kai Großjohann]

Matt Armstrong <matt@lickey.com> writes:

> I think the hardest part is determining which lists the user is
> subscribed to.  I don't think to-address is sufficient.

MFT explicitly lists all addresses that should be on To/Cc.  So if MFT
is present, it's easy to DTRT.

And if MFT is not present, then the user probably does not mind to
receive a copy, so we just put them on the auto-generated MFT.

kai
-- 
GNU/Linux provides a nice `poweroff' command, but where is `poweron'?

Re: Generating Mail-Followup-To: headers

[Paul Jarc]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote:
> Matt Armstrong <matt@lickey.com> writes:
>> I think the hardest part is determining which lists the user is
>> subscribed to.  I don't think to-address is sufficient.
>
> MFT explicitly lists all addresses that should be on To/Cc.  So if MFT
> is present, it's easy to DTRT.

If MFT is present in the previous message, then yes, we use that to
construct To+Cc in our response.  But the question here is how to
determine whether to add MFT to our message as well.  It seems the
best way to determine that is to check whether any of the addressees
is a mailing list.

It might be useful to generate MFT whenever the previous message had
it, but that wouldn't cover all the cases we want.  Depending how we
cover other cases, it might not be necessary.


paul

Re: Generating Mail-Followup-To: headers

[Kai Großjohann]

prj@po.cwru.edu (Paul Jarc) writes:

> If MFT is present in the previous message, then yes, we use that to
> construct To+Cc in our response.  But the question here is how to
> determine whether to add MFT to our message as well.  It seems the
> best way to determine that is to check whether any of the addressees
> is a mailing list.

Ah, I see.  And we can assume that a to-list or to-address group
parameter means it's a mailing list.  Right.  But what to do in the
other cases?

Of course, the easy way out is an mft group parameter :-)

kai
-- 
GNU/Linux provides a nice `poweroff' command, but where is `poweron'?

Re: Generating Mail-Followup-To: headers

[Maciej Matysiak]

On the 18th of October 2001 at 20:17, Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote:

> And we can assume that a to-list or to-address group parameter means
> it's a mailing list.  Right.  But what to do in the other cases?

I don't use 'to-list' nor 'to-address' parameters at all (my mail is split
into groups named like group-year-month, it's a pain to add such parameters
to 30+ groups every month). I'd like the new procedure look as well for
headers added to mailinglists messages: 'Precedence: list', 'Mailing-List:'
and probably more. Is it doable?

 m.m. (very happy after adding mule-ucs patch for xemacs :))
-- 
 use gnus not guns!

Re: Generating Mail-Followup-To: headers

[Kai Großjohann]

Maciej Matysiak <phoner@blah.pl> writes:

> I don't use 'to-list' nor 'to-address' parameters at all (my mail is split
> into groups named like group-year-month, it's a pain to add such parameters
> to 30+ groups every month).

Only because you don't know about the variable gnus-parameters :-)
There, you can specify regular expressions and have the parameters
take effect for all group names matching that regular expression.

kai
-- 
GNU/Linux provides a nice `poweroff' command, but where is `poweron'?

Re: Generating Mail-Followup-To: headers

[Maciej Matysiak]

On the 19th of October 2001 at 11:03, Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote:

>> I don't use 'to-list' nor 'to-address' parameters at all (my mail is
>> split into groups named like group-year-month, it's a pain to add
>> such parameters to 30+ groups every month).
> Only because you don't know about the variable gnus-parameters :-)

right :) ok, my homework is done. now i have something like:

(setq gnus-parameters '(
	("ding-l-.*"
		(to-address . "ding@gnus.org")
		(to-list . "ding@gnus.org"))))

it works nice, but why the list address is not visible in 'gnus customize'
buffer (in fields 'to address' and 'to list')? (also, this buffer is not
killed after submiting the changes with 'done' button).

 m.m.
-- 
 use gnus not guns!

Re: Generating Mail-Followup-To: headers

[Matt Armstrong]

Maciej Matysiak <phoner@blah.pl> writes:

> On the 19th of October 2001 at 11:03, Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote:
>
>>> I don't use 'to-list' nor 'to-address' parameters at all (my mail is
>>> split into groups named like group-year-month, it's a pain to add
>>> such parameters to 30+ groups every month).
>> Only because you don't know about the variable gnus-parameters :-)
>
> right :) ok, my homework is done. now i have something like:
>
> (setq gnus-parameters '(
> 	("ding-l-.*"
> 		(to-address . "ding@gnus.org")
> 		(to-list . "ding@gnus.org"))))

I think using to-address for ding@gnus.org is not totally correct --
ding@gnus.org accepts mail from non list members.

> it works nice, but why the list address is not visible in 'gnus
> customize' buffer (in fields 'to address' and 'to list')?

That is a bummer -- I don't think customize has a way to express "this
value isn't set here, but it is effectively set to 'XYZ' by some other
mechanism."

> (also, this buffer is not killed after submiting the changes with
> 'done' button).

Yeah, I always wondered why customize did that (never enough to
investigate though).


-- 
matt

Re: Generating Mail-Followup-To: headers

[Samuel Padgett]

"Matt Armstrong" <matt+dated+1007244626.4ef141@lickey.com> writes:

> Maciej Matysiak <phoner@blah.pl> writes:
>
>> (also, this buffer is not killed after submiting the changes with
>> 'done' button).
>
> Yeah, I always wondered why customize did that (never enough to
> investigate though).

Have a look at custom-buffer-done-function.

Sam

Re: Generating Mail-Followup-To: headers

[Maciej Matysiak]

On the 2nd of November 2001 at 02:03, Samuel Padgett <spadgett1@nc.rr.com> wrote:

>>> (also, this buffer is not killed after submiting the changes with
>>> 'done' button).
>> Yeah, I always wondered why customize did that (never enough to
>> investigate though).
> Have a look at custom-buffer-done-function.

,---
| `custom-buffer-done-function' is a variable declared in Lisp.
|   -- loaded from "cus-edit"
| 
| Value: kill-buffer
| 
| Documentation:
| *Function to be used to remove the buffer when the user is done with it.
| Choices include `kill-buffer' (the default) and `bury-buffer'.
| The function will be called with one argument, the buffer to remove.
`----

and the customize buffer is still available after i commit changes.
a bug?

 m.m.
-- 
 use gnus not guns!

Re: Generating Mail-Followup-To: headers

[Maciej Matysiak]

On the 1st of November 2001 at 23:10, "Matt Armstrong" <matt+dated+1007244626.4ef141@lickey.com> wrote:

> I think using to-address for ding@gnus.org is not totally correct --
> ding@gnus.org accepts mail from non list members.

thank you for pointing this out.

>> (also, this buffer is not killed after submiting the changes with
>> 'done' button).
> Yeah, I always wondered why customize did that (never enough to
> investigate though).

is this gnus or [x]emacs issue?

btw., is the mft header generated before sending a message? i've just
upgraded gnus from pre-mft-stuff version. i have set to t the variable
message-generate-headers-first, and mft is not among the headers.

 m.m.
-- 
 use gnus not guns!

Re: Generating Mail-Followup-To: headers

[Per Abrahamsen]

Maciej Matysiak <phoner@blah.pl> writes:

> is this gnus or [x]emacs issue?

An [X]Emacs issue.

Re: Generating Mail-Followup-To: headers

[Didier Verna]

Per Abrahamsen wrote:

> An [X]Emacs issue.

        An \(X|GNU \)Emacs issue :-)

-- 
Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier

EPITA / LRDE, 14-16 rue Voltaire   Tel.+33 (1) 53 14 59 47
94276 Le Kremlin-Bicêtre, France   Fax.+33 (1) 53 14 59 22   didier@xemacs.org

Re: Generating Mail-Followup-To: headers

[Per Abrahamsen]

Didier Verna <didier@lrde.epita.fr> writes:

> Per Abrahamsen wrote:
>
>> An [X]Emacs issue.
>
>         An \(X|GNU \)Emacs issue :-)

A GNU [X]Emacs issue.

Re: Generating Mail-Followup-To: headers

[Josh Huber]

Maciej Matysiak <phoner@blah.pl> writes:

> btw., is the mft header generated before sending a message? i've
> just upgraded gnus from pre-mft-stuff version. i have set to t the
> variable message-generate-headers-first, and mft is not among the
> headers.

The MFT header can't be generated before sending the message. (well, I
guess it could, but the "spec" says that it must be generated after
you know the final list of recipients)

Currently (I think) you're going to need something like this in your
~/.gnus.el:

(setq gnus-parameters
      '(("^mail\\.lists\\." (subscribed . t))))

(setq message-subscribed-address-functions
      '(gnus-find-subscribed-addresses))

First, a regexp describing which groups you are subscribed to.  What
this does is if the regexp matches, gnus pulls a to-list/to-address
value from the group parameters.  gnus-find-subscribed-addresses does
this for all groups that match the regexp, and returns a regexp that
matches all of the to-list/to-address values that you are subscribed
to.

so, it still requires some configuration.

-- 
Josh Huber

Re: Generating Mail-Followup-To: headers

[Kai Großjohann]

Josh Huber <huber@alum.wpi.edu> writes:

> The MFT header can't be generated before sending the message.

It doesn't make sense to generate headers after sending the message,
for then it's gone already.

So MFT should be generated after the user hits C-c C-c but before the
message is actually sent.

kai
-- 
I like BOTH kinds of music.

Re: Generating Mail-Followup-To: headers

[Matt Armstrong]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Josh Huber <huber@alum.wpi.edu> writes:
>
>> The MFT header can't be generated before sending the message.
>
> It doesn't make sense to generate headers after sending the message,
> for then it's gone already.
>
> So MFT should be generated after the user hits C-c C-c but before the
> message is actually sent.

:-)  That's funny.  Of course, I'm sure that's what Josh meant.


-- 
matt

Re: Generating Mail-Followup-To: headers

[Kai Großjohann]

"Matt Armstrong" <matt@lickey.com> writes:

> :-)  That's funny.  Of course, I'm sure that's what Josh meant.

Ah, I'm happy that I don't _always_ need to add a smiley when I want
to make a joke!  ;-)

kai
-- 
I like BOTH kinds of music.

Re: Generating Mail-Followup-To: headers

[Josh Huber]

"Matt Armstrong" <matt+dated+1007741306.241146@lickey.com> writes:

> :-) That's funny.  Of course, I'm sure that's what Josh meant.

er...yes :)

heh.

-- 
Josh Huber

Re: Generating Mail-Followup-To: headers

[Kai Großjohann]

Maciej Matysiak <phoner@blah.pl> writes:

> right :) ok, my homework is done. now i have something like:
>
> (setq gnus-parameters '(
> 	("ding-l-.*"
> 		(to-address . "ding@gnus.org")
> 		(to-list . "ding@gnus.org"))))
>
> it works nice, but why the list address is not visible in 'gnus customize'
> buffer (in fields 'to address' and 'to list')? (also, this buffer is not
> killed after submiting the changes with 'done' button).

Well, suppose you have the above in gnus-parameters and then hit `G
c' on a group ding-l-foo, and change the parameter there.  What
should happen to the value of gnus-parameters?

And what should happen to the setq statement which asks the Oracle of
Delphi to compute the right gnus-parameters value for the current
phase of the moon?

kai
-- 
Lisp is kinda like tpircstsoP

Re: Generating Mail-Followup-To: headers

[Matt Armstrong]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Maciej Matysiak <phoner@blah.pl> writes:
>
>> right :) ok, my homework is done. now i have something like:
>>
>> (setq gnus-parameters '(
>> 	("ding-l-.*"
>> 		(to-address . "ding@gnus.org")
>> 		(to-list . "ding@gnus.org"))))
>>
>> it works nice, but why the list address is not visible in 'gnus customize'
>> buffer (in fields 'to address' and 'to list')? (also, this buffer is not
>> killed after submiting the changes with 'done' button).
>
> Well, suppose you have the above in gnus-parameters and then hit `G
> c' on a group ding-l-foo, and change the parameter there.  What
> should happen to the value of gnus-parameters?

It should be left unchanged.

> And what should happen to the setq statement which asks the Oracle
> of Delphi to compute the right gnus-parameters value for the current
> phase of the moon?

I'd say the real group parameters would have precedence over
gnus-parameters.

-- 
matt

OT: make bbdb shut up about different email addresses?

[Josh Huber]

I wonder, since Matt's email addresses are dated, is there a way to
get BBDB to not ask me:

"Would you like to add ...@... to so-and-so's BBDB record?"

every time I view a message from Matt?

thanks,

-- 
Josh Huber

Re: OT: make bbdb shut up about different email addresses?

[Matt Armstrong]

Josh Huber <huber@alum.wpi.edu> writes:

> I wonder, since Matt's email addresses are dated, is there a way to
> get BBDB to not ask me:
>
> "Would you like to add ...@... to so-and-so's BBDB record?"
>
> every time I view a message from Matt?

I set bbdb-always-add-addresses to 'never.

But you can also set it to a function that (I assume) gets the address
and returns 't, nil or 'never.  It could use some regexp magic to
avoid asking about the dated address.

-- 
matt

Re: OT: make bbdb shut up about different email addresses?

[Jason R. Mastaler]

"Matt Armstrong" <matt+dated+1007314672.bbf0af@lickey.com> writes:

> But you can also set it to a function that (I assume) gets the
> address and returns 't, nil or 'never.  It could use some regexp
> magic to avoid asking about the dated address.

Yes, BBDB provides a hook for filtering email addresses before adding
them to the database.

See <http://forums.my.gnus.org/viewtopic.php?topic=46&forum=7&0> for
the details.

I should probably add this to the TMDA FAQ as well.

-- 
(TMDA - http://tmda.sourceforge.net)

Re: OT: make bbdb shut up about different email addresses?

[Matt Armstrong]

"Jason R. Mastaler" <jason-dated-1005414502.d48a01@mastaler.com> writes:

> "Matt Armstrong" <matt+dated+1007314672.bbf0af@lickey.com> writes:
>
>> But you can also set it to a function that (I assume) gets the
>> address and returns 't, nil or 'never.  It could use some regexp
>> magic to avoid asking about the dated address.
>
> Yes, BBDB provides a hook for filtering email addresses before adding
> them to the database.
>
> See <http://forums.my.gnus.org/viewtopic.php?topic=46&forum=7&0> for
> the details.
>
> I should probably add this to the TMDA FAQ as well.

Yes, much better than using bbdb-always-add-addresses as I suggested
earlier.

My version below deals only with "dated" addresses; deals with those
that use any recipient delimiter (not just -); and is a tighter regexp
to minimize risk of false simplifications.

P.S., please let me know if there is any standard emacs function
equivalent to

(defun extract-match (str index)
  (substring str (match-beginning index) (match-end index)))


(defun my-bbdb-canonicalize-net-hook (addr)
  (cond
   ;; take care of TMDA dated addresses
   ((string-match
     "^\\(.+?\\)\\(.\\)dated\\2[0-9]+\\.[0-9a-fA-F]+\\(@.*\\)" addr)
    (concat (substring addr (match-beginning 1) (match-end 1))
	    (substring addr (match-beginning 3) (match-end 3))))
   ;; by default, leave it alone
   (t addr)))

(setq bbdb-canonicalize-net-hook 'my-bbdb-canonicalize-net-hook)

-- 
matt

Re: OT: make bbdb shut up about different email addresses?

[Paul Jarc]

"Matt Armstrong" <matt+dated+1007322243.f870a5@lickey.com> wrote:
> P.S., please let me know if there is any standard emacs function
> equivalent to
>
> (defun extract-match (str index)
>   (substring str (match-beginning index) (match-end index)))

match-string


paul

Re: OT: make bbdb shut up about different email addresses?

[Matt Armstrong]

"Matt Armstrong" <matt+dated+1007314672.bbf0af@lickey.com> writes:

> Josh Huber <huber@alum.wpi.edu> writes:
>
>> I wonder, since Matt's email addresses are dated, is there a way to
>> get BBDB to not ask me:
>>
>> "Would you like to add ...@... to so-and-so's BBDB record?"
>>
>> every time I view a message from Matt?
>
> I set bbdb-always-add-addresses to 'never.
>
> But you can also set it to a function that (I assume) gets the address
> and returns 't, nil or 'never.  It could use some regexp magic to
> avoid asking about the dated address.

This works...

(defun my-bbdb-always-add-addresses-func ()
  (cond
   ((string-match ".\\(.\\)dated\\1[0-9]\\{9,10\\}\\.[0-9a-fA-F]\\{2,16\\}@"
		  net)
    'never)
   (t nil)))
   
(setq bbdb-always-add-addresses 'my-bbdb-always-add-addresses-func)




-- 
matt

Re: OT: make bbdb shut up about different email addresses?

[Jack Twilley]

>>>>> "Josh" == Josh Huber <huber@alum.wpi.edu> writes:

Josh> I wonder, since Matt's email addresses are dated, is there a way
Josh> to get BBDB to not ask me:

Josh> "Would you like to add ...@... to so-and-so's BBDB record?"

Josh> every time I view a message from Matt?

Matt just joined an elite list of folks in my
bbdb-canonicalize-net-hook.

Here's what the hook would look like if he were the only one in it:

(setq bbdb-canonicalize-net-hook
      '(lambda (addr)
         (cond ((string-match "matt+[^@]*@lickey.com" addr)
                "zngg@yvpxrl.pbz")
               (t addr))))

I've ROTted Matt's address out of courtesy.

Josh> thanks,

Josh> -- Josh Huber

Jack.
(took me forever to figure this out.)
-- 
Jack Twilley
jmt at twilley dot org
http colon slash slash www dot twilley dot org slash tilde jmt slash

Re: OT: make bbdb shut up about different email addresses?

[Matt Armstrong]

Jack Twilley <jmt+usenet@twilley.org> writes:

>>>>>> "Josh" == Josh Huber <huber@alum.wpi.edu> writes:
>
> Josh> I wonder, since Matt's email addresses are dated, is there a way
> Josh> to get BBDB to not ask me:
>
> Josh> "Would you like to add ...@... to so-and-so's BBDB record?"
>
> Josh> every time I view a message from Matt?
>
> Matt just joined an elite list of folks in my
> bbdb-canonicalize-net-hook.

I'm glad to cause trouble.  ;-)

> I've ROTted Matt's address out of courtesy.

<plug>
Thanks to TMDA (http://software.libertine.org/tmda), I don't care if
my raw address (matt@lickey.com) gets out there.
</plug>

The point of the +dated.. stuff is to make it easy for folks to reply
to my posts without going through a confirmation step proving that
they're a human.  The +dated.. addresses expire after a while.

Actually, some of the benefit is just having the + in the email
address.  Harvesters are often tripped up by it.  I imagine your
mailer may bounce mail to "usenet at twilley.org" quite a bit.

> Jack.
> (took me forever to figure this out.)

I think elisp is hard.  After 5 years of insignificant tinkering, I'm
approaching a novice skill level.

-- 
matt

thoughts on spam

[Bill White]

On Fri Nov 02 2001 at 17:54, "Matt Armstrong" <matt+dated+1007337284.9e618d@lickey.com> said:

>> I've ROTted Matt's address out of courtesy.
>
> <plug>
> Thanks to TMDA (http://software.libertine.org/tmda), I don't care if
> my raw address (matt@lickey.com) gets out there.
> </plug>

Nowadays spam is pretty easy to filter - nearly everything that lands
in my mail.misc is spam.  Here's my low-tech method of deleting it.

I filter my mail through a huge nnmail-split-methods to grab and store
all but messages addressed only to me.  When I open my mail.misc
Summary buffer, this

   (setq gnus-summary-line-format 
   "%U%R|%(%uy%)|%4L|%ub|%-30,30f| %B%s\n")
                     ^^^   

marks (with a "+") all the folks who are recorded in my bbdb.  Then I
get ready to lean on the # key and quickly scan the from addresses and
subjects that aren't marked with a "+", process-marking them if
they're spam, which is now easier to recognize.

Hm - I need a way to sort the Summary buffer based on whether a "+"
appears at a specific column in each line so "+" messages could float
to the top.

Some weekends I get over a hundred spams, and it's pretty easy to
delete them quickly.  The drawback is that marking bbdb-known posters
is pretty slow.

bw
-- 
Bill White
"No, ma'am, we're musicians."

Re: thoughts on spam

[Jason R. Mastaler]

"Bill White" <billw@wolfram.com> writes:

> Some weekends I get over a hundred spams, and it's pretty easy to
> delete them quickly.  The drawback is that marking bbdb-known
> posters is pretty slow.

The real drawback IMHO is that the spam is still wasting your time, so
it is still a problem.  As you mentioned, spam is generally easy to
recognize, but hand deletion is subject to human error, and again is
time-consuming.

I hate to brag, but I used to get 800-1000 pieces of spam every month.
Now I see 1-2 every six weeks or so.  And my system requires
practically no maintenance - it runs itself.  I can't tell you how
much time this has saved me.  But more importantly, it has restored my
love of e-mail.  I once again look forward to opening my mailbox each
morning.

SPAM? What SPAM? (was: thoughts on spam)

[Robin S. Socha]

* Jason R Mastaler <jason-dated-1005460420.45cb81@mastaler.com> writes:
> "Bill White" <billw@wolfram.com> writes:

>> Some weekends I get over a hundred spams, and it's pretty easy to
>> delete them quickly.  The drawback is that marking bbdb-known posters
>> is pretty slow.

[...]

> I hate to brag, but I used to get 800-1000 pieces of spam every month.
> Now I see 1-2 every six weeks or so.  

Same here.

> And my system requires practically no maintenance - it runs itself.  I
> can't tell you how much time this has saved me.  

Bragging's no good without mentioning the product itself, D00d3...
http://tmda.sourceforge.net/ rocks more than words can describe. And it
comes free with your free @my.gnus.org accounts :-)

Re: SPAM? What SPAM? (was: thoughts on spam)

[Harry Putnam]

"Robin S. Socha" <robin-dated-1005031068.78ccba@socha.net> writes:

> Bragging's no good without mentioning the product itself, D00d3...
> http://tmda.sourceforge.net/ rocks more than words can describe. And it
> comes free with your free @my.gnus.org accounts :-)

Doesn't support sendmail.... egad.  Only supports kook fringe mta's.
(Any one else ever wondered what Robin would do if kicked in shin...
 I guess we'll find out.... he he)

Re: SPAM? What SPAM? (was: thoughts on spam)

[Jason R. Mastaler]

Harry Putnam <reader@newsguy.com> writes:

> Doesn't support sendmail.... egad.  Only supports kook fringe mta's.

TMDA currently supports the most widely used opensource/unix MTAs
other than Sendmail (qmail, Postfix, and Exim).  There is a chance
that Sendmail will be supported in the future, but it will really be
some sort of hack.  Sendmail makes things very difficult for me.

TMDA (which is invoked from .forward/.qmail) needs full access to the
message envelope to operate (envelope recipient address, envelope
sender address, etc.).  Believe it or not, Sendmail has thrown away
the entire envelope by the time it reaches .forward.

The requirements for e-mail applications today are different than they
were a decade ago, but Sendmail has made little effort to keep up.  In
my book, Sendmail wins the "pioneer" award for being the first to
market, but that is no reason to continue using it today when there
are several *superior* alternatives available.

Re: SPAM? What SPAM? (was: thoughts on spam)

[Karl Kleinpaste]

"Jason R. Mastaler" <jason-dated-1005503980.ed5948@mastaler.com> writes:
> Believe it or not, Sendmail has thrown away
> the entire envelope by the time it reaches .forward.

No, the sender envelope address is present, as can be seen by sending
oneself a test message while "|cat > /tmp/junk" is in one's .forward.
The first line of the message in /tmp/junk is the "UNIX From_ line",
containing the sender envelope (plus timestamp).

I don't find the recipient envelope address very useful, because it is
seldom more informative than user@host.name.

Re: SPAM? What SPAM? (was: thoughts on spam)

[Jason R. Mastaler]

Karl Kleinpaste <karl@charcoal.com> writes:

> No, the sender envelope address is present, as can be seen by
> sending oneself a test message while "|cat > /tmp/junk" is in one's
> .forward.  The first line of the message in /tmp/junk is the "UNIX
> From_ line", containing the sender envelope (plus timestamp).

Right, that was a typo on my part.  What I meant was that I need the
envelope recipient address, and Sendmail does not provide that.

> I don't find the recipient envelope address very useful, because it
> is seldom more informative than user@host.name.

But as you can imagine, it is necessary for TMDA which needs to be
able to process recipients like user-dated-1005505559.fc6798@host.name.

Re: SPAM? What SPAM? (was: thoughts on spam)

[Harry Putnam]

Karl Kleinpaste <karl@charcoal.com> writes:

> "Jason R. Mastaler" <jason-dated-1005503980.ed5948@mastaler.com> writes:
>> Believe it or not, Sendmail has thrown away
>> the entire envelope by the time it reaches .forward.
>
> No, the sender envelope address is present, as can be seen by sending
> oneself a test message while "|cat > /tmp/junk" is in one's .forward.
> The first line of the message in /tmp/junk is the "UNIX From_ line",
> containing the sender envelope (plus timestamp).

Karl,  What might this mean?  Maybe there is something else I'm
supposed to know to do...

cat ~/.forward 
|cat > /tmp/junk

 $ mail -s TEST reader < .bashrc
[209 reader]~
 $ /home/reader/.forward: line 1: Unbalanced '>'
<and there it hangs>

Re: SPAM? What SPAM? (was: thoughts on spam)

[Karl Kleinpaste]

Harry Putnam <reader@newsguy.com> writes:
> Karl,  What might this mean?  Maybe there is something else I'm
> supposed to know to do...

> cat ~/.forward 
> |cat > /tmp/junk

>  $ mail -s TEST reader < .bashrc
> [209 reader]~
>  $ /home/reader/.forward: line 1: Unbalanced '>'
> <and there it hangs>

Not hanging, it just didn't deliver successfully.

Piped (programmatic) destinations need to have the entire thing quoted
in .forward.  My personal .forward contains:

   [1366] [01:59pm] cinnamon:~> cat .forward 
   "|/home/karl/bin/zrcvalert karl", karl@gw.vanillaknot.com

Re: thoughts on spam

[Bill White]

On Sat Nov 03 2001 at 00:33, "Jason R. Mastaler" <jason-dated-1005460420.45cb81@mastaler.com> said:

> I hate to brag, but I used to get 800-1000 pieces of spam every
> month.  Now I see 1-2 every six weeks or so.  And my system requires
> practically no maintenance - it runs itself.  I can't tell you how
> much time this has saved me.  But more importantly, it has restored
> my love of e-mail.  I once again look forward to opening my mailbox
> each morning.

On Sat Nov 03 2001 at 01:29, "Robin S. Socha" <robin-dated-1005031068.78ccba@socha.net> said:

> Same here.
>
>> And my system requires practically no maintenance - it runs itself.
>> I can't tell you how much time this has saved me.

[...]

> http://tmda.sourceforge.net/ rocks more than words can describe. And it

Nice testimonials - I'm downloading now...

bw
-- 
Bill White                                               Office: 5E-Z15
Documentation Programmer                      Phone: 217-398-0700 x 234
Wolfram Research		                      Fax: 217-398-0747
http://members.wri.com/billw    [currently working from home most days]

Re: thoughts on spam

[Stainless Steel Rat]

* "Bill White" <billw@wolfram.com>  on Sat, 03 Nov 2001
| Nice testimonials - I'm downloading now...

I've started using spambouncer recently.
<URL:http://www.spambouncer.org/>
-- 
Rat <ratinox@peorth.gweep.net>    \ Ingredients of Happy Fun Ball include an
Minion of Nathan - Nathan says Hi! \ unknown glowing substance which fell to
PGP Key: at a key server near you!  \ Earth, presumably from outer space.

Re: thoughts on spam

[Jason R. Mastaler]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> I've started using spambouncer recently.
> <URL:http://www.spambouncer.org/>

Programs like spambouncer are exactly why I wrote TMDA.  The reason is
explained under ``Traditional Blacklist-centric Strategy'' at
http://tmda.sf.net/

Re: thoughts on spam

[Stainless Steel Rat]

* "Jason R. Mastaler" <jason-dated-1005503050.85ff2f@mastaler.com>  on Sat, 03 Nov 2001
| Programs like spambouncer are exactly why I wrote TMDA.  The reason is
| explained under ``Traditional Blacklist-centric Strategy'' at
| http://tmda.sf.net/

Whitelists have their own risks that I would rather not have to deal with
at the delivery level.  For example, I post something to a mailing list,
someone wants clarification about that thing and would prefer not to
discuss it on the list.  His mail bounces because he is not in my
whitelist.  Sure, he gets a note saying, "here is how to get on Rat's
whitelist."  That is a pain in the ass, plain and simple.

Whitelists do not scale well at all, which is why SpamCop is moving away
from a whitelist/blacklist scheme to an heuristic scheme that they have
found blocks more spam with fewer false positives than the combined white
and black lists.

Just FYI.
-- 
Rat <ratinox@peorth.gweep.net>    \ Caution: Happy Fun Ball may suddenly
Minion of Nathan - Nathan says Hi! \ accelerate to dangerous speeds.
PGP Key: at a key server near you!  \ 

Re: thoughts on spam

[Jason R. Mastaler]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> Whitelists have their own risks that I would rather not have to deal
> with at the delivery level.  For example, I post something to a
> mailing list, someone wants clarification about that thing and would
> prefer not to discuss it on the list.  His mail bounces because he
> is not in my whitelist.  Sure, he gets a note saying, "here is how
> to get on Rat's whitelist."  That is a pain in the ass, plain and
> simple.

This is exactly what TMDA's 'dated' addresses are for.  You control
when they expire, and within that interval, anyone can contact you at
that address.  I've found that with my whitelist and using 'dated'
addresses on mailing lists and USENET, very few people actually end up
having to confirm messages.  Confirmation involves the 2-click/key
sequence of replying to a message, and it's only a one time ordeal for
them anyway.  Hardly a pain in the ass IMO.

> Whitelists do not scale well at all, which is why SpamCop is moving
> away from a whitelist/blacklist scheme to an heuristic scheme that
> they have found blocks more spam with fewer false positives than the
> combined white and black lists.

First, SpamCop is different in that they use global lists which end up
much larger than TMDA's per-user lists.  With wildcard expressions and
DBM/CDB support, scalability is not much of a problem anyway, even
with fairly large lists.  Second, as explained on the homepage, TMDA
is "whitelist-centric" which means use of a blacklist is downplayed in
favour of the whitelist.  Whitelists are generally much smaller than
blacklists.

I don't know all the details about the SpamCop decision, but I really
don't see how any heuristic could be more effective than what I'm
doing now.  (I've already mentioned how many SPAMs I now get).  Using
heuristics puts you right back into that "race condition" with the
spammers.  Spam software implementors are just as clever and motivated
as we are.

As far as false positives, I've not had yet (in over 6 months) had
one, and I'm sure any TMDA will tell you the same.  Unnecessary
complexity is what gets you into trouble in that area.  TMDA's
methodology is very simple, which I think is its greatest strength.

Re: thoughts on spam

[Stainless Steel Rat]

* "Jason R. Mastaler" <jason-dated-1005548417.48bbb7@mastaler.com>  on Sun, 04 Nov 2001
| As far as false positives, I've not had yet (in over 6 months) had one,
| and I'm sure any TMDA will tell you the same.  Unnecessary complexity is
| what gets you into trouble in that area.  TMDA's methodology is very
| simple, which I think is its greatest strength.

TDMA and puts the onus on the sender.  I think this is bad because for
every "power user" like me there are hundreds if not thousands who are
utterly confused when they get a warning, "unable to deliver, will try
again in N hours" and want to know if their mail was delivered.  These
people Just Don't Get It, and they -never- will.  These are the people who
will generate false positives against TDMA.  They will be confused by
TDMA's "do this to get on my whitelist" response because it is not the
nothingness they expect, and most of them will simply ignore it and never
send you anything again.

And then there are those like me.  If I am in a pissy mood and I get
something like that from TDMA, I could very well say "fuck that," delete
it, and killfile you so that I never have to deal with a fundamentally
brain-damaged mail system.

The RISK here is that you will never know that this has happened.  Your
idea of "no way my whitelist will ever generate a false positive" seems to
me to be woefully vulnerable to false positives without any feedback.  That
seems to me to be a bad system, and I am one of the most rabidly anti-spam
people I know.  If the choice is between a little bit of spam getting past
spambouncer and losing legitimate mail, I will take the spam, let Gnus drop
it into my spambucket, and run it through SpamCop manually.

SpamCop is abandoning their whitelist/blacklist system because the
whitelist system does not work well for everyone, and the blacklist system
has proven not to scale up to the load being placed on it.  Their new
heuristic system works because they have -the- largest database of spam and
spammers in the world from which to derive them, and that database is
constantly being updated.
-- 
Rat <ratinox@peorth.gweep.net>    \ Caution: Happy Fun Ball may suddenly
Minion of Nathan - Nathan says Hi! \ accelerate to dangerous speeds.
PGP Key: at a key server near you!  \ 

Re: thoughts on spam

[Jason R. Mastaler]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> TDMA and puts the onus on the sender.  I think this is bad because
> for every "power user" like me there are hundreds if not thousands
> who are utterly confused when they get a warning, "unable to
> deliver, will try again in N hours" and want to know if their mail
> was delivered.  These people Just Don't Get It, and they -never-
> will.  These are the people who will generate false positives
> against TDMA.

I think you are underestimating the intelligence of the average e-mail
user.  Confirming a message through TMDA requires less effort than
subscribing to a mailing list, and some of the least technical people
imaginable (my landlord, my aunt, etc.) were not confused by the
process.

Also, e-mail awareness/competence will continue to increase as time
goes on making this less and less of an issue.

> They will be confused by TDMA's "do this to get on my whitelist"
> response because it is not the nothingness they expect, and most of
> them will simply ignore it and never send you anything again.

In practice, this isn't the case.  TMDA allows you to save a copy of
the confirmed message before storing it for confirmation, so you can
check for these cases if you want, but I've found it isn't necessary.

> And then there are those like me.  If I am in a pissy mood and I get
> something like that from TDMA, I could very well say "fuck that," delete
> it, and killfile you so that I never have to deal with a fundamentally
> brain-damaged mail system.

So be it.  If you are too lazy to reply to a one-time confirmation
message, it tells me your message probably isn't worth reading.  And
the confirmation is for a good cause, it doesn't indicate a
"brain-damaged mail system".

> The RISK here is that you will never know that this has happened.

Again, this isn't true.  You can save the message before confirming as
I mentioned, scan the pending queue periodically, etc.

> Their new heuristic system works because they have -the- largest
> database of spam and spammers in the world from which to derive
> them, and that database is constantly being updated.

Updated yes, but after the fact.  This strategy is old-hat and simply
doesn't work well enough for my tastes.  Use what makes you most
comfortable.  Enough said.

Re: thoughts on spam

[Stainless Steel Rat]

* "Jason R. Mastaler" <jason-dated-1005681899.034438@mastaler.com>  on Mon, 05 Nov 2001
| I think you are underestimating the intelligence of the average e-mail
| user.  Confirming a message through TMDA requires less effort than
| subscribing to a mailing list, and some of the least technical people
| imaginable (my landlord, my aunt, etc.) were not confused by the process.

No, I'm not.  I honestly wish I were, but I get two or three stupid user
questions a week about mail that you would think is totally
self-explanatory.  I get mail from users, sometimes the -same- users,
asking about mail that tells them that they don't have to do anything at
all.

| Also, e-mail awareness/competence will continue to increase as time
| goes on making this less and less of an issue.

Call me a pessimist, then.

[...]
| In practice, this isn't the case.  TMDA allows you to save a copy of
| the confirmed message before storing it for confirmation, so you can
| check for these cases if you want, but I've found it isn't necessary.

Ummm... I am confused.  What confirmed message?  If you the user hasn't
confirmed anything then you don't get a confirmed message to sort or store.
Maybe I'm missing something here?

[...]
| So be it.  If you are too lazy to reply to a one-time confirmation
| message, it tells me your message probably isn't worth reading.

Actually, it tells you nothing at all.  See, that is my point.  You, the
TDMA user, never know this has happened.

| And the confirmation is for a good cause, it doesn't indicate a
| "brain-damaged mail system".

In my rather extreme opinion, anything that knowingly interferes with the
delivery of legitimate mail without informing the recipient of that
interference is brain-damaged.

| > The RISK here is that you will never know that this has happened.
| Again, this isn't true.  You can save the message before confirming as
| I mentioned, scan the pending queue periodically, etc.

Sounds a bit backwards to me.  Knowing that I got bad mail and dealing with
it makes more sense to me than scanning a trap full of bad mail for one or
two good messages that may or may not be there.

[...]
| Updated yes, but after the fact.  This strategy is old-hat and simply
| doesn't work well enough for my tastes.  Use what makes you most
| comfortable.  Enough said.

You'd be suprised at how well it can work.  The trick is to use a scoring
method, grepping for words and phrases common to various types of spam and
setting the spam flag if the score exceeds a threshold.  This works because
most of the spam out there are basically form letters.
-- 
Rat <ratinox@peorth.gweep.net>    \ Do not taunt Happy Fun Ball.
Minion of Nathan - Nathan says Hi! \ 
PGP Key: at a key server near you!  \ 

Re: thoughts on spam

[Jason R. Mastaler]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> Ummm... I am confused.  What confirmed message?  If you the user
> hasn't confirmed anything then you don't get a confirmed message to
> sort or store.  Maybe I'm missing something here?

[...]

> Actually, it tells you nothing at all.  See, that is my point.  You,
> the TDMA user, never know this has happened.

[...]

> In my rather extreme opinion, anything that knowingly interferes
> with the delivery of legitimate mail without informing the recipient
> of that interference is brain-damaged.

[...]

> Sounds a bit backwards to me.  Knowing that I got bad mail and
> dealing with it makes more sense to me than scanning a trap full of
> bad mail for one or two good messages that may or may not be there.

Each of these assumptions is erroneous, but I don't have the energy to
argue any more, and I'm sure lots of Gnus users wish I would shut my
hole, so if you want to discuss this further, take it to one of the
TMDA lists please.

> You'd be suprised at how well it can work.  The trick is to use a
> scoring method, grepping for words and phrases common to various
> types of spam and setting the spam flag if the score exceeds a
> threshold.  This works because most of the spam out there are
> basically form letters.

Yup.  That works until the spammers figure this out and start to use
different words and phrases.  This is an time-wasting infinite loop.

Re: thoughts on spam

[Stainless Steel Rat]

* "Jason R. Mastaler" <jason-dated-1005692781.f201f7@mastaler.com>  on Mon, 05 Nov 2001
| Yup.  That works until the spammers figure this out and start to use
| different words and phrases.  This is an time-wasting infinite loop.

No, it isn't.  Watch.

Take a well-known spam-friendly but otherwise legitimate mail service like
mail.ru.  Yes, they really should lock things down, but they do not, and my
company has several customers who use mail.ru as their mail service.
Sucks, but we're stuck with it.  Add spam for "Super Pheromones" which was
originated there, or at least appears to be.  Here is how it is dealt with
heuristically using a scoring system.

The spam-friendly ISP gives the message a base score of 1000.  The first
instance of the word "pheromone" is worth 500 points and each additional
occourance is worth 100 points (the message I am using as an example has
four occourances).  The HTML-only message, no text part, is worth 500
points.  There are additional checks that can be applied, but I am keeping
this example simple.

We decide to set our threshold to 2200.  This will cause any message that
orginates from mail.ru or another known spam-friendly source (1000), is
HMTL only (500), and contains the word "pheromone" three times or more
(700) to be marked as spam.  No matter how much the spammer changes his
form letter, the product he is advertising is going to be mentioned several
times, if he doesn't mention his product and what it does then his
advertising is going to fail.  That is what you scan for.

This also works for "You gotta see this", which dubiously advertises
unsecured credit cards, sattelite descramblers, long distance telephone
theft, water and electric theft, X-Ray envelope spray, internet sleuth,
radar jammers, anonymous mail relaying, some kind of test cheat scam,
another credit scam, how to pass drug tests, cable TV theft, lie detector
fakout, and lockpicking tricks.

The actual scores and threshold values are arbitrary, and there are some
useful formulae for calculating keyword weights depending on how agressive
you wish to be.

Now, this message would get a score of absurdly high because of the 14 "you
gotta see this" products (for only $19.95!), which is why a better keyword
weighting system might be to start small and increase by some scaling
factor.  So the first instance of "pheromone" would be 50 points, the
second 250 points and the third 500 points, for a total of 800 points.
I'll let you know what spambouncer says the score of this message is once I
get it back from the list :).
-- 
Rat <ratinox@peorth.gweep.net>    \ Warning: pregnant women, the elderly, and
Minion of Nathan - Nathan says Hi! \ children under 10 should avoid prolonged
PGP Key: at a key server near you!  \ exposure to Happy Fun Ball.

Re: thoughts on spam

[Stainless Steel Rat]

* Stainless Steel Rat <ratinox@peorth.gweep.net>  on Mon, 05 Nov 2001
| I'll let you know what spambouncer says the score of this message is once I
| get it back from the list :).

Actually, none, since it came from a known good list.  Yes, spambouncer
also uses a white list so mailing lists don't get clobbered.
-- 
Rat <ratinox@peorth.gweep.net>    \ If Happy Fun Ball begins to smoke, get
Minion of Nathan - Nathan says Hi! \ away immediately. Seek shelter and cover
PGP Key: at a key server near you!  \ head.

Re: thoughts on spam

[Paul Jarc]

Stainless Steel Rat <ratinox@peorth.gweep.net> wrote:
> Yes, spambouncer also uses a white list so mailing lists don't get
> clobbered.

Which is nice, since spam never comes through mailing lists.

Can this *please* be taken off this list now?


paul

Re: thoughts on spam

[Harry Putnam]

prj@po.cwru.edu (Paul Jarc) writes:

> Can this *please* be taken off this list now?

Paul, can't you just avoid the thread?  I mean it is about
mail/newsreading. It's not as if we've had a surfeit of interesting
topics here lately.

Re: thoughts on spam

[Stainless Steel Rat]

* prj@po.cwru.edu (Paul Jarc)  on Mon, 05 Nov 2001
| Which is nice, since spam never comes through mailing lists.

| Can this *please* be taken off this list now?

Since I seem to have misrepresented spambouncer here, no, at least not
yet.  My mistake is the implication that the whitelist for mailing lists
will allow all spam through.  It won't.  It will be marked "Bulk" in the
headers, which may or may not be useful for split methods.

How to pull this back on topic for Gnus?  spambouncer creates X-SBClass and
X-SBRule headers for all messages that it processes.  SBClass can be OK,
Bulk, Blocked, Admin or Spam.  OK means it passed without any spammish
content.  Bulk comes from mailing lists.  Blocked is something that
triggerd a pattern match such as disclaimers; the associated X-SBRule
header can be checked for details in a fancy split.  Admin is stuff that
appears to have come from an automated source, mailer-daemon, cron, etc.
Spam is any message that is obviously from a known spammer or spam house,
sent by a known spam mailer, achieves a sufficiently high pattern match
score, etc.  Spam includes mail that originates from an easilly configured
list of blackholes and DULs.

Huzzah, full circle!  spambouncer makes filtering with Gnus easy!
-- 
Rat <ratinox@peorth.gweep.net>    \ If Happy Fun Ball begins to smoke, get
Minion of Nathan - Nathan says Hi! \ away immediately. Seek shelter and cover
PGP Key: at a key server near you!  \ head.

Re: thoughts on spam

[Chris Shenton]

This discussion has finally motivated me to try TMDA.  Just built and
installed it but I'm having trouble figuring the best way to use it
with all the mailing lists I'm already on.

Naturally, the second I enabled it in .qmail[-default] it started
pumping msgs to ~/.tmda/pending.  

The FAQ indicates that I can add stuff to "whitelist" which TMDA
should compare with Envelope-Sender, and the body From: and Reply-To:
headers.

I don't see anything in my qmail logs which tells me the envelope
sender; any suggestions how I can capture this?  For mailing lists,
the From: is usually not what I want, since that just gets the
originating human's address. Most the lists I'm on do not have a
Reply-To: either.

So all I can match on is what qmail-smtpd records as the connecting
host, not a full envelope from. This is way too broad.

Sounds like the best thing is to unsubscribe from all my lists then
resubscribe with one of the username-extensions like "sender", right?

That's gonna take some time, so I'm looking for clues to help me make
the transition less painful.  Suggestions welcomed.

Thanks.

PS: To keep it on topic, I'm using the Gnus that came with Emacs21.

Re: thoughts on spam

[Matt Armstrong]

Note: I've set the Mail-Followup-To: to tmda-users@libertine.org since
this is off topic for ding@gnus.org

Chris Shenton <chris@shenton.org> writes:

> This discussion has finally motivated me to try TMDA.  Just built
> and installed it but I'm having trouble figuring the best way to use
> it with all the mailing lists I'm already on.
>
> Naturally, the second I enabled it in .qmail[-default] it started
> pumping msgs to ~/.tmda/pending.  
>
> I don't see anything in my qmail logs which tells me the envelope
> sender; any suggestions how I can capture this?  For mailing lists,
> the From: is usually not what I want, since that just gets the
> originating human's address. Most the lists I'm on do not have a
> Reply-To: either.

Stick something like this in your .tmdarc:

    import time
    localtime = time.localtime(time.time())
    YYYYmm = time.strftime('%Y-%m',localtime)
    LOGFILE = os.path.expanduser("/home/matt/.tmda/log/tmdalog." + YYYYmm)

This'll give stuff like this in your ~/.tmda/log/tmdalog.2001-11 file:

    Date: Thu Nov  1 08:33:03 2001
    From: c379sb1@caramail.com
      To: matt+bmi@lickey.com
    Subj: Sales leads for your business.
    Actn: CONFIRM pending 1004628783.24166.msg                       (693)

Note the Actn: line shows that tmda sent a confirmation mail for this
one -- you didn't get it in your inbox.

The envelope sender will be in the Sndr: line.  In this case, the
envelope sender was the same as the From: line, so TMDA omitted it.

> Sounds like the best thing is to unsubscribe from all my lists then
> resubscribe with one of the username-extensions like "sender", right?

I eventually ended up doing that, rather than whitelist them.

I use the recently added "keyword" style addresses.  For example, I
subscribed to ding@gnus.org as matt+ding.e75467@lickey.com.  TMDA will
accept this address regardless of who sends it, which can sometimes be
helpful with dealing with lists.  E.g. if you get mail from
majordomo@wherever.com, you'll get it.  If you just whitelist
"list-owner@wherever.com" you may miss such mails.

Then, if the list requires that you be subscribed to post, you can add
something like this to your ~/.tmda/lists/keyword file:

    ding@gnus.org ding
    
and tmda-inject will munge your From address to be
user+ding.e75467@yourdomain.com.

If this address ever starts getting spam, stick it in your
~/.tmda/lists/revoked file and start using ding2 as your keyword.  ;-)

> That's gonna take some time, so I'm looking for clues to help me
> make the transition less painful.  Suggestions welcomed.

You might also set BOUNCE_CONFIRM_CC to be something like
chris-bounces@shenton.org -- and have .qmail-bounces deliver to a mail
folder that you check periodically, until you've got all your mailing
lists accounted for.

-- 
matt

Re: thoughts on spam

[Robin S. Socha]

* Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
>* "Bill White" <billw@wolfram.com>  on Sat, 03 Nov 2001

> | Nice testimonials - I'm downloading now...

> I've started using spambouncer recently.  <URL:http://www.spambouncer.org/>

procmail. Blech. Urgh. Begone! Ickickick. *shudder*

You aware of the fact, though, that spambouncer has nothing to do
with tmda whatsoever and is just another futile attempt at using
cleverer heuristics than the spammers? I mean, yeah, I know you do,
but, eh, procmail sucks and spammers are eerily cunning. tmda doesn't
need heuristics. It just works. And it does not need procmail. Did I
mention already that procmail sucks? Listen and repeat, boys and girls:
"qmail, qmail, tatataaa, mailfilter, mailfilter, dumdidum..."

Damn, that booze *is* heavy...

Re: thoughts on spam

[Jason R. Mastaler]

"Robin S. Socha" <robin-dated-1005070923.208cb9@socha.net> writes:

> procmail. Blech. Urgh. Begone! Ickickick. *shudder*
> 
> You aware of the fact, though, that spambouncer has nothing to do
> with tmda whatsoever and is just another futile attempt at using
> cleverer heuristics than the spammers? I mean, yeah, I know you do,
> but, eh, procmail sucks and spammers are eerily cunning. tmda doesn't
> need heuristics. It just works. And it does not need procmail. Did I
> mention already that procmail sucks? Listen and repeat, boys and girls:
> "qmail, qmail, tatataaa, mailfilter, mailfilter, dumdidum..."
> 
> Damn, that booze *is* heavy...

With friends like Robin, who needs enemies.  :-)

Re: thoughts on spam

[Fabien Penso]

[-- Attachment #1: Type: text/plain, Size: 807 bytes --]


Robin on Sat, 03 Nov 2001 13:26:51 -0500 wrote:

 > You aware of the fact, though, that spambouncer has nothing to do
 > with tmda whatsoever and is just another futile attempt at using
 > cleverer heuristics than the spammers? I mean, yeah, I know you do,
 > but, eh, procmail sucks and spammers are eerily cunning. tmda doesn't
 > need heuristics. It just works. And it does not need procmail. Did I
 > mention already that procmail sucks? Listen and repeat, boys and girls:
 > "qmail, qmail, tatataaa, mailfilter, mailfilter, dumdidum..."

Qmail sux, his license is the kind you can throw away. Use Postfix. Also
procmail is a great piece of software. Would you be nice enough to tell
why you don't like procmail ?

-- 
Fabien Penso <penso@linuxfr.org>
http://perso.LinuxFR.org/penso/

[-- Attachment #2: Type: application/pgp-signature, Size: 239 bytes --]

Re: thoughts on spam

[Robin S. Socha]

* Fabien Penso <penso@linuxfr.org> writes:
> Robin on Sat, 03 Nov 2001 13:26:51 -0500 wrote:

>> You aware of the fact, though, that spambouncer has nothing to do
>> with tmda whatsoever and is just another futile attempt at using
>> cleverer heuristics than the spammers?

> Qmail sux, his license is the kind you can throw away. 

Fabien sux, his reading ability is the kind you can throw away. qmail
does not have a licence. Duh ;-)

> Use Postfix. 

Get a shovel, you'll need a *deep* hole:
http://software.libertine.org/tmda/requirements.html

> Also procmail is a great piece of software. 

Procmail is a great pain in the arse. Its syntax is as sexually exciting
as hacking sendmail.cf with vi.

> Would you be nice enough to tell why you don't like procmail ?

I'm not nice. But I strongly recommend your reading
http://www.flounder.net/~mrsam/maildrop/ - procmail is to maildrop what
sendmail is to qmail: bloated, arcane, unsafe.

Re: thoughts on spam

[Stainless Steel Rat]

* "Robin S. Socha" <robin-dated-1005074278.269a25@socha.net>  on Sat, 03 Nov 2001
| I'm not nice. But I strongly recommend your reading
| http://www.flounder.net/~mrsam/maildrop/ - procmail is to maildrop what
| sendmail is to qmail: bloated, arcane, unsafe.

Yeah, but you know, not using qmail has one really, really important benfit
to me: I don't use qmail.  Whether or not qmail sucks is not the issue.
Dan Bernstein is the issue.  I simply refuse to voluntarilly use an of his
software, and there is absolutely nothing that anyone can say that will get
me to change my mind, simple as that.
-- 
Rat <ratinox@peorth.gweep.net>    \ Do not use Happy Fun Ball on concrete.
Minion of Nathan - Nathan says Hi! \ 
PGP Key: at a key server near you!  \ 

Re: thoughts on spam

[Jason R. Mastaler]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> Dan Bernstein is the issue.  I simply refuse to voluntarilly use an
> of his software, and there is absolutely nothing that anyone can say
> that will get me to change my mind, simple as that.

That's interesting, but I'm fairly sure it won't bother him much.

I'm the first to admit DJB has a god-complex and the social graces of
a water buffalo.  I use this software because it's brilliant, not
because of his personality or lack thereof.  I do what's best for me,
and can leave my ego at the door to achieve that.

Anyway, Postfix and Exim are reasonable Sendmail-alternatives as well.

Re: thoughts on spam

[Stainless Steel Rat]

* "Jason R. Mastaler" <jason-dated-1005548826.22b028@mastaler.com>  on Sun, 04 Nov 2001
| Anyway, Postfix and Exim are reasonable Sendmail-alternatives as well.

They are -not- reasonable for -all- cases.  I have seen Postfix's
parallelization totally cripple my network at work.  As far as we could
figure, Postfix did not ratchet down fast enough and the end result was a
crashed firewall MTA and an unknown quantity of lost mail.  We reset
everything and Postfix did it again.  I have little doubt that qmail would
achieve the same results, only faster.

Before you say anything like, "but, you can configure foo to do bar," no,
we cannot.  No matter what tweaking we might do there is always the slim
possibility that Postfix will do that again.  The only way we can guarantee
that it will not happen is not to use Postfix at all.  sendmail works.
That made our choice of MTA a no-brainer.
-- 
Rat <ratinox@peorth.gweep.net>    \ Ingredients of Happy Fun Ball include an
Minion of Nathan - Nathan says Hi! \ unknown glowing substance which fell to
PGP Key: at a key server near you!  \ Earth, presumably from outer space.

Re: thoughts on spam

[Matt Armstrong]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> * "Jason R. Mastaler" <jason-dated-1005548826.22b028@mastaler.com>  on Sun, 04 Nov 2001
> | Anyway, Postfix and Exim are reasonable Sendmail-alternatives as well.
>
> They are -not- reasonable for -all- cases.  I have seen Postfix's
> parallelization totally cripple my network at work.  As far as we
> could figure, Postfix did not ratchet down fast enough and the end
> result was a crashed firewall MTA and an unknown quantity of lost
> mail.  We reset everything and Postfix did it again.  I have little
> doubt that qmail would achieve the same results, only faster.
>
> Before you say anything like, "but, you can configure foo to do
> bar," no, we cannot.  No matter what tweaking we might do there is
> always the slim possibility that Postfix will do that again.  The
> only way we can guarantee that it will not happen is not to use
> Postfix at all.  sendmail works.  That made our choice of MTA a
> no-brainer.

FUD -- you can configure postfix such that there is zero possibility
that it'll flood your network.


-- 
matt

Re: thoughts on spam

[Stainless Steel Rat]

* "Matt Armstrong" <matt+dated+1007488665.146847@lickey.com>  on Sun, 04 Nov 2001
| FUD -- you can configure postfix such that there is zero possibility
| that it'll flood your network.

Your -assertion- does not make it so.

The fact that it -has- happened is sufficient reason to be wary of it,
because there is a non-zero possibility of it happening again, no matter
what you say.
-- 
Rat <ratinox@peorth.gweep.net>    \ Ingredients of Happy Fun Ball include an
Minion of Nathan - Nathan says Hi! \ unknown glowing substance which fell to
PGP Key: at a key server near you!  \ Earth, presumably from outer space.

Re: thoughts on spam

[Paul Jarc]

Stainless Steel Rat <ratinox@peorth.gweep.net> wrote:
> * "Matt Armstrong" <matt+dated+1007488665.146847@lickey.com>  on Sun, 04 Nov 2001
>| Stainless Steel Rat <ratinox@peorth.gweep.net> wrote:
>|> I have seen Postfix's parallelization totally cripple my network
>|> at work.  As far as we could figure, Postfix did not ratchet down
>|> fast enough and the end result was a crashed firewall MTA and an
>|> unknown quantity of lost mail.  We reset everything and Postfix
>|> did it again.  I have little doubt that qmail would achieve the
>|> same results, only faster.

qmail doesn't lose mail.  (Nor does it "ratchet down"; you give it a
limit, and it stays within that limit.)

>| FUD -- you can configure postfix such that there is zero possibility
>| that it'll flood your network.
>
> Your -assertion- does not make it so.

Nor does your assertion make it not so.

> The fact that it -has- happened is sufficient reason to be wary of it,
> because there is a non-zero possibility of it happening again, no matter
> what you say.

IOW, as long as it's possible to configure it to hose your network,
you're not interested in whether it can be configured not to do so?

This is very, very OT.  Can those interested in it take it off-list,
please?


paul

Re: thoughts on spam

[Stainless Steel Rat]

* prj@po.cwru.edu (Paul Jarc)  on Sun, 04 Nov 2001
| Nor does your assertion make it not so.

My first-hand experience makes it so.

| IOW, as long as it's possible to configure it to hose your network,
| you're not interested in whether it can be configured not to do so?

Exactly.  Because some day someone is going to come along and accidentaly
use the default settings and more mail will be lost.  If it has the
-capability- of hosing the network and losing mail we are absolutely not
interested.  That goes for qmail as well as Postfix.  Simple as that.

| This is very, very OT.  Can those interested in it take it off-list,
| please?

Pot, kettle, etc.
-- 
Rat <ratinox@peorth.gweep.net>    \ Warning: pregnant women, the elderly, and
Minion of Nathan - Nathan says Hi! \ children under 10 should avoid prolonged
PGP Key: at a key server near you!  \ exposure to Happy Fun Ball.

Re: thoughts on spam

[Harry Putnam]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> | Nor does your assertion make it not so.
>
> My first-hand experience makes it so.

Jeez Rat, could you try not to be so wishy washy on this.. .   So do you
dislike qmail and every thing about it or what?  I can't tell from
your timid fence straddling ... he he.

Another thing about qmail at least when I tried it out about 2 years
ago, is that its only semi-documented.  Ditto for postfix back then.

Sendmail may be complicated and I don't pretend to know much about it
but there are acres of documentation, and even an illiterate hillbilly
like me has been able to configure it to work.

Re: thoughts on spam

[Matt Armstrong]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> * "Matt Armstrong" <matt+dated+1007488665.146847@lickey.com>  on Sun, 04 Nov 2001
> | FUD -- you can configure postfix such that there is zero possibility
> | that it'll flood your network.
>
> Your -assertion- does not make it so.
>
> The fact that it -has- happened is sufficient reason to be wary of it,
> because there is a non-zero possibility of it happening again, no matter
> what you say.

Of course, if I dumped every software package that ever screwed me
over due to a mis-configuration, I'd have dumped Gnus years ago.  ;-)


-- 
matt

Re: thoughts on spam

[Stainless Steel Rat]

* "Matt Armstrong" <matt+dated+1007567947.77c13d@lickey.com>  on Mon, 05 Nov 2001
| Of course, if I dumped every software package that ever screwed me
| over due to a mis-configuration, I'd have dumped Gnus years ago.  ;-)

Let's just say that there is a difference between oneself being reamed by a
bug and an entire company of some 350 employees being reamed by a feature.
-- 
Rat <ratinox@peorth.gweep.net>    \ Do not use Happy Fun Ball on concrete.
Minion of Nathan - Nathan says Hi! \ 
PGP Key: at a key server near you!  \ 

[OT] Re: thoughts on spam

[Fabien Penso]

Stainless on 05 Nov 2001 11:57:16 -0500 wrote:

 > * "Matt Armstrong" <matt+dated+1007567947.77c13d@lickey.com>  on Mon, 05 Nov 2001
 > | Of course, if I dumped every software package that ever screwed me
 > | over due to a mis-configuration, I'd have dumped Gnus years ago.  ;-)

 > Let's just say that there is a difference between oneself being reamed by a
 > bug and an entire company of some 350 employees being reamed by a feature.

You mean Postfix can't handle 350 accounts ? :) Damned...

-- 
Fabien Penso <penso@linuxfr.org>
http://perso.LinuxFR.org/penso/

Re: [OT] Re: thoughts on spam

[Stainless Steel Rat]

* Fabien Penso <penso@linuxfr.org>  on Mon, 05 Nov 2001
| You mean Postfix can't handle 350 accounts ? :) Damned...

Umm... read the thread, please.
-- 
Rat <ratinox@peorth.gweep.net>    \ Do not use Happy Fun Ball on concrete.
Minion of Nathan - Nathan says Hi! \ 
PGP Key: at a key server near you!  \ 

Re: thoughts on spam

[Harry Putnam]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> * "Matt Armstrong" <matt+dated+1007567947.77c13d@lickey.com>  on Mon, 05 Nov 2001
> | Of course, if I dumped every software package that ever screwed me
> | over due to a mis-configuration, I'd have dumped Gnus years ago.  ;-)
>
> Let's just say that there is a difference between oneself being reamed by a
> bug and an entire company of some 350 employees being reamed by a feature.

Matt, has gnus actually ever lost mail for you... I've never heard any
one say that?

I have never lost mail with it since my first usages around quassia-15
or so, and I am probably one of the most sloppy and least informed of
its users.

The only time I remember actually losing mail while using gnus, it was
from unleashing a really stupid rogue `rm -rf' that leveled News Mail
and every other non-dot file in ~/

Re: thoughts on spam

[Stainless Steel Rat]

* Harry Putnam <reader@newsguy.com>  on Mon, 05 Nov 2001
| I have never lost mail with it since my first usages around quassia-15
| or so, and I am probably one of the most sloppy and least informed of
| its users.

I think the only time I have lost anything with GNUS (not Gnus) was while
working on GNUS-expire, my attempt at backporting Gnus' expiry code for
GNUS 3 and 4.  This was ca 1984.
-- 
Rat <ratinox@peorth.gweep.net>    \ Warning: pregnant women, the elderly, and
Minion of Nathan - Nathan says Hi! \ children under 10 should avoid prolonged
PGP Key: at a key server near you!  \ exposure to Happy Fun Ball.

Re: thoughts on spam

[Karl Kleinpaste]

Harry Putnam <reader@newsguy.com> writes:
> Matt, has gnus actually ever lost mail for you... I've never heard any
> one say that?

There have been bugs at some times in the past.  Notably, when Lars
was re-working mail source in pGnus around the 0.40 time frame, there
was some serious damage done and some folks actually lost mail.

Re: thoughts on spam

[Matt Armstrong]

Harry Putnam <reader@newsguy.com> writes:

> Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
>
>> * "Matt Armstrong" <matt+dated+1007567947.77c13d@lickey.com>  on Mon, 05 Nov 2001
>> | Of course, if I dumped every software package that ever screwed me
>> | over due to a mis-configuration, I'd have dumped Gnus years ago.  ;-)
>>
>> Let's just say that there is a difference between oneself being reamed by a
>> bug and an entire company of some 350 employees being reamed by a feature.
>
> Matt, has gnus actually ever lost mail for you... I've never heard any
> one say that?

Gnus has certainly lost mail on me.  Just recently mail was
disappearing on me when my servers/mail-sources were all screwed up
through no fault of my own.  Mind you I've always been running the
development versions since September Gnus, so I do invite this kind of
risk (and I backup all mail before it ever gets to Gnus, so no real
harm has ever been done).

But Gnus is currently broken in its default configuration.  If you
follow the instructions in the manual, you'll have an "archive" group
and your default nnml group living in ~/Mail.

Then if you subsequently do a gnus-server-regenerate-server ('g' from
the server buffer) of your nnml server, it'll troll through all of
~/Mail, including your archive dirs, and try to make groups out of
them.  Insanity ensues.  Things get broken.

If you do a "B c nnfolder:foo" and create a group that way, the 'foo'
folder will end up in ~/Mail.  ~/Mail/active will have a foo entry put
into it, and nnml will start thinking it is an nnml group.  Things get
broken.

Neither of the above actions elicit any warnings when I do them, yet
they leave stuff horribly broken.  It was when I was trying these
things out that I was losing mail (stuff was in the Incoming... files,
but in none of the mail groups).

Recent threads suggested a way that Gnus can detect when mail backends
start sharing the same directories and issue an error.  I hope it gets
implemented someday -- my elisp isn't good enough to do it myself.
;-)


> I have never lost mail with it since my first usages around
> quassia-15 or so, and I am probably one of the most sloppy and least
> informed of its users.

Admittedly, I was *trying* to break things when doing what I describe
above.  Still, I wasn't doing anything that wasn't easily doable with
a few key strokes, or off a menu.  I wasn't doing anything that
obscure.


> The only time I remember actually losing mail while using gnus, it
> was from unleashing a really stupid rogue `rm -rf' that leveled News
> Mail and every other non-dot file in ~/

Who hasn't?  :-)


-- 
matt

Re: thoughts on spam

[Harry Putnam]

"Matt Armstrong" <matt+dated+1007584536.5875f3@lickey.com> writes:

> Neither of the above actions elicit any warnings when I do them, yet
> they leave stuff horribly broken.  It was when I was trying these
> things out that I was losing mail (stuff was in the Incoming... files,
> but in none of the mail groups).

"Stuff was in the Incoming..."  Says it all.  I think you've led
us a little astray.  So no mail was lost then?

Re: thoughts on spam

[Matt Armstrong]

Harry Putnam <reader@newsguy.com> writes:

> "Matt Armstrong" <matt+dated+1007584536.5875f3@lickey.com> writes:
>
>> Neither of the above actions elicit any warnings when I do them, yet
>> they leave stuff horribly broken.  It was when I was trying these
>> things out that I was losing mail (stuff was in the Incoming... files,
>> but in none of the mail groups).
>
> "Stuff was in the Incoming..."  Says it all.  I think you've led
> us a little astray.  So no mail was lost then?

The mail was preserved in the IncomingXXX files, yes, thanks to my
having mail-source-delete-incoming set to nil.

Gnus isn't off the hook though -- this is still a catastrophic failure
on its part.

-- 
matt

Re: thoughts on spam

[Harry Putnam]

"Matt Armstrong" <matt+dated+1007657726.8b578c@lickey.com> writes:

[...]

> The mail was preserved in the IncomingXXX files, yes, thanks to my
> having mail-source-delete-incoming set to nil.

`mail-source-delete-incoming' is set to nil by default in alpha
gnus.  Has been for years.  You are thanking the wrong party.

There was a short time a few mnths ago when that got set to t by
accident in a tarball (or maybe it was on cvs for a few days). It was
duly noted here and quickly changed.

Gnus authors, contibutors etc have taken actual `mail loss' very
seriously right along.  I missed the short lived mess Karl
K. mentioned. And I think he said it was fairly short lived too.

The reason I kept on with this discussion is because you made a point
in counter to `Rat' that if we/you dropped software because it screwed
us we would drop gnus. 

However, if I understood `Rat' correctly he was taling about mail
being thoroughly trashed, not surviving in special backupfiles
provided by the software in question.

Lost Mail (was thoughts on spam)

[Stainless Steel Rat]

* Harry Putnam <reader@newsguy.com>  on Tue, 06 Nov 2001
| However, if I understood `Rat' correctly he was taling about mail
| being thoroughly trashed, not surviving in special backupfiles
| provided by the software in question.

Indeed, lost as in irrecoverably gone forever.  Not a fun situation at all.
-- 
Rat <ratinox@peorth.gweep.net>    \ Happy Fun Ball may stick to certain types
Minion of Nathan - Nathan says Hi! \ of skin.
PGP Key: at a key server near you!  \ 

Re: thoughts on spam

[Matt Armstrong]

Harry Putnam <reader@newsguy.com> writes:

> "Matt Armstrong" <matt+dated+1007657726.8b578c@lickey.com> writes:
>
> [...]
>
>> The mail was preserved in the IncomingXXX files, yes, thanks to my
>> having mail-source-delete-incoming set to nil.
>
> `mail-source-delete-incoming' is set to nil by default in alpha
> gnus.  Has been for years.  You are thanking the wrong party.
>
> There was a short time a few mnths ago when that got set to t by
> accident in a tarball (or maybe it was on cvs for a few days). It
> was duly noted here and quickly changed.
>
> Gnus authors, contibutors etc have taken actual `mail loss' very
> seriously right along.  I missed the short lived mess Karl
> K. mentioned. And I think he said it was fairly short lived too.
>
> The reason I kept on with this discussion is because you made a
> point in counter to `Rat' that if we/you dropped software because it
> screwed us we would drop gnus.
>
> However, if I understood `Rat' correctly he was taling about mail
> being thoroughly trashed, not surviving in special backupfiles
> provided by the software in question.

I'm no longer entirely sure what we're talking about here.

Right now I'm merely pointing out what I did to get Gnus to lose mail
for me just the other week, and that those bugs should probably get
fixed before Oort can "ship."

-- 
matt

Re: thoughts on spam

[Harry Putnam]

"Matt Armstrong" <matt+dated+1007668931.c8f542@lickey.com> writes:

>> The reason I kept on with this discussion is because you made a
>> point in counter to `Rat' that if we/you dropped software because it
>> screwed us we would drop gnus.
>>
>> However, if I understood `Rat' correctly he was taling about mail
>> being thoroughly trashed, not surviving in special backupfiles
>> provided by the software in question.
>
> I'm no longer entirely sure what we're talking about here.

Let me refresh your memory.. You can review the relevant sections
below..

You've made a strong statement here concerning gnus screwing you over:

Rat was clearly talking about a real calamity of *LOST* mail. You were
talking about a situation were you `lost mail' as if comparable.  Then
it turned out you lost no mail at all, and further that the software
screwing you over, saved it in backup files for you.  Something
designed into it for just such an event.

That was what piqued my interest.  
========================================

Message-ID: <87n122s9k8.fsf@squeaker.lickey.com>

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> * "Jason R. Mastaler" <jason-dated-1005548826.22b028@mastaler.com>  on Sun, 04 Nov 2001
> | Anyway, Postfix and Exim are reasonable Sendmail-alternatives as well.
>
> They are -not- reasonable for -all- cases.  I have seen Postfix's
> parallelization totally cripple my network at work.  As far as we
> could figure, Postfix did not ratchet down fast enough and the end
> result was a crashed firewall MTA and an unknown quantity of lost
> mail.  We reset everything and Postfix did it again.  I have little

[...]

========================================

Matt writes:
Message-ID: <87n122s9k8.fsf@squeaker.lickey.com>
FUD -- you can configure postfix such that there is zero possibility
that it'll flood your network.

========================================
Rat writes:
Message-ID: <m3y9lmqn5t.fsf@peorth.gweep.net>

* "Matt Armstrong" <matt+dated+1007488665.146847@lickey.com>  on Sun, 04 Nov 2001
| FUD -- you can configure postfix such that there is zero possibility
| that it'll flood your network.

Your -assertion- does not make it so.

The fact that it -has- happened is sufficient reason to be wary of it,
because there is a non-zero possibility of it happening again, no matter
what you say.
========================================

Matt Writes
Message-ID: <87g07tgqeu.fsf@squeaker.lickey.com>

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> * "Matt Armstrong" <matt+dated+1007488665.146847@lickey.com>  on Sun, 04 Nov 2001
> | FUD -- you can configure postfix such that there is zero possibility
> | that it'll flood your network.
>
> Your -assertion- does not make it so.
>
> The fact that it -has- happened is sufficient reason to be wary of it,
> because there is a non-zero possibility of it happening again, no matter
> what you say.

Of course, if I dumped every software package that ever screwed me
over due to a mis-configuration, I'd have dumped Gnus years ago.  ;-)
========================================

Re: thoughts on spam

[Steinar Bang]

>>>>> Harry Putnam <reader@newsguy.com>:

> Matt, has gnus actually ever lost mail for you... I've never heard
> any one say that?

I've lost mail to an expiry bug, back in 1997 or thereabouts.

Note: not new incoming mail though.  It just expired all my ticked
articles in nnml groups.

Re: thoughts on spam

[François Pinard]

[Jason R. Mastaler]

> I'm the first to admit DJB has a god-complex and the social graces of a
> water buffalo.  I use this software because it's brilliant, not because
> of his personality or lack thereof.  I do what's best for me, and can
> leave my ego at the door to achieve that.

It all depends on what's is best for you.  If someone is ready to accept
or even caution anything as long as he makes some profit of it, he is the
least of Ferrengis :-), and becomes a bit despisable himself.

I do not question Daniel competence.  But his software is not free despite
what's written, and as such, I would not accept the ambiguity nor the lie.
What is best for me is fresh air, freedom, and pleasurable people.  Lars gave
me that, and I tried to return the favour.  These are human values, and also
where my values stand.  For me at least, software is not an end in itself.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: thoughts on spam

[François Pinard]

[Stainless Steel Rat]

> Yeah, but you know, not using qmail has one really, really important benfit
> to me: I don't use qmail.  Whether or not qmail sucks is not the issue.
> Dan Bernstein is the issue.  I simply refuse to voluntarilly use any of
> his software, and there is absolutely nothing that anyone can say that
> will get me to change my mind, simple as that.

I heartedly agree.  Daniel has beaten all known records for the rate at
which one may create own enemies.  He kept silent and quiet for many years,
maybe so people may forget him, but I've no proof the guy is different.
Note that I never had problems personally with him, but seeing how he
behaved with many, many others, I just do not want that guy in my life.

Besides, whatever the license is, however competent is the writer, haughtily
maintained software is never as free as it appears to be.  When someone is
spitting on you and you may not easily run away, you just can't feel free.
The best way to not become dependent on Qmail is to never start using it.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: thoughts on spam

[Russ Allbery]

Fabien Penso <penso@linuxfr.org> writes:

> Would you be nice enough to tell why you don't like procmail ?

Have you ever looked at the procmail source code?

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: thoughts on spam

[Harry Putnam]

"Bill White" <billw@wolfram.com> writes:

> On Sat Nov 03 2001 at 00:33, "Jason R. Mastaler"
> <jason-dated-1005460420.45cb81@mastaler.com> said:


>> I hate to brag, but I used to get 800-1000 pieces of spam every
[...]

Robin says:
> Bragging's no good without mentioning the product itself, D00d3...
> http://tmda.sourceforge.net/ rocks more than words can describe. And
> it comes free with your free @my.gnus.org accounts :-)

Bill Says:
> Nice testimonials - I'm downloading now...

I guess Bill really does hate to brag... He never did outline what he does...

Re: thoughts on spam

[Bill White]

On Sat Nov 03 2001 at 12:15, Harry Putnam <reader@newsguy.com> said:

> "Bill White" <billw@wolfram.com> writes:
>
>> On Sat Nov 03 2001 at 00:33, "Jason R. Mastaler"
>> <jason-dated-1005460420.45cb81@mastaler.com> said:
>
>
>>> I hate to brag, but I used to get 800-1000 pieces of spam every
> [...]
>
> Robin says:
> > Bragging's no good without mentioning the product itself, D00d3...
>> http://tmda.sourceforge.net/ rocks more than words can describe. And
>> it comes free with your free @my.gnus.org accounts :-)
>
> Bill Says:
> > Nice testimonials - I'm downloading now...
>
> I guess Bill really does hate to brag... He never did outline what
> he does...

Eh?  My low-tech approach is in <m34rocwi27.fsf_-_@wolfram.com>.  Must
have been snipped in some quotes.

I (Joe Q. Luser) am now attempting to enter the strange new world of
qmail on a standard-issue redhat box whilst a 4-year-old boy and a
3-year-old girl watch Thomas the Tank Engine videos two feet away.
Whee!  Saints Ignucious and Isidore of Seville, ora pro me.

bw
-- 
Bill White                                               Office: 5E-Z15
Documentation Programmer                      Phone: 217-398-0700 x 234
Wolfram Research		                      Fax: 217-398-0747
http://members.wri.com/billw    [currently working from home most days]

Re: thoughts on spam

[Harry Putnam]

"Bill White" <billw@wolfram.com> writes:

>> I guess Bill really does hate to brag... He never did outline what
>> he does...
>
> Eh?  My low-tech approach is in <m34rocwi27.fsf_-_@wolfram.com>.  Must
> have been snipped in some quotes.

Sorry Bill, I saw that.. I guess I was expecting some kind of
scripting or something.  Or maybe just a senior moment or rolling blackout
or maybe a meterorite hit me, I had four flat tires, my glasses broke,
there was a DNS glitch in Mae-west, gnus broke wind, Twiggy was on tv,
lunar eclipse, my DSL line got tangled up with my stereo wiring and
all my mail was turned into .wav files...... It wasn't my fault.

Re: thoughts on spam

[Harry Putnam]

"Bill White" <billw@wolfram.com> writes:

> Hm - I need a way to sort the Summary buffer based on whether a "+"
> appears at a specific column in each line so "+" messages could float
> to the top.

Doesn't that + just represent an above default score?
If so you can limit according to score.

Re: thoughts on spam

[Bill White]

On Sat Nov 03 2001 at 22:07, Harry Putnam <reader@newsguy.com> said:

> "Bill White" <billw@wolfram.com> writes:
>
>> Hm - I need a way to sort the Summary buffer based on whether a "+"
>> appears at a specific column in each line so "+" messages could
>> float to the top.
>
> Doesn't that + just represent an above default score?  If so you can
> limit according to score.

Well, I tried scoring seriously for a few months but I found that
scoring and I just don't get along.  What I'm doing with the "+" is in
the bbdb info file at <info://bbdb/Reader-specific+Features/Gnus-speci
fic+Features/Gnus+Summary+Buffer+Enhancements> (I hope that url thingy
works right - does it work when broken across lines like <url:>
does?).

I guess I could use scoring *only* to increase the score of bbdb-known
posters (somehow) and then limit... hmm... 

Jason's tmda sounds awfully good, though (if it weren't for the scary
qmail hoops of fire).

Bill "gnus: where even my goofy ideas work, sometimes"
-- 
Bill White                                               Office: 5E-Z15
Documentation Programmer                      Phone: 217-398-0700 x 234
Wolfram Research		                      Fax: 217-398-0747
http://members.wri.com/billw    [currently working from home most days]

Re: thoughts on spam

[Jason R. Mastaler]

"Bill White" <billw@wolfram.com> writes:

> Jason's tmda sounds awfully good, though (if it weren't for the
> scary qmail hoops of fire).

:-) Well, I think qmail is worth the initial cognitive distortion,
but if the fire gets too hot, Postfix and Exim are alternatives as I
mentioned.

Re: thoughts on spam

[Harry Putnam]

"Bill White" <billw@wolfram.com> writes:

>> Doesn't that + just represent an above default score?  If so you can
>> limit according to score.
>
> Well, I tried scoring seriously for a few months but I found that
> scoring and I just don't get along.  What I'm doing with the "+" is in
> the bbdb info file at:
> <info://bbdb/Reader-specific+Features/Gnus-specific+Features/
> Gnus+Summary+Buffer+Enhancements> 

Oh, I see that it has nothing to do with a higher score.  Sorry.
Here, when a message has above default score a + sign appears.  And
has for ages.  Not bbdb related but some default indicating a scored
message.  I thought it might be related.

Incidently, at the info page you cited, an incremental `i' search
finds not one instance of `+'

>
> (I hope that url thingy works right - does it work when broken across
> lines like <url:> does?).

It didn't for me, no.  However I edited it so it wasn't wrapped and
then it did.  I've been noticing something with those URL that will
appear shortly in a separate post...  


But I've noticed this on a few of those URL.  Instead of
being swept away to that formatted info section, I get swept away to
the top of the raw bbdb.info 

This is bbdb.info, produced by makeinfo version 4.0 from bbdb.texinfo.

INFO-DIR-SECTION Emacs
START-INFO-DIR-ENTRY
* BBDB: (bbdb).             The Insidious Big Brother Database.
END-INFO-DIR-ENTRY

bbdb arcana

[Bill White]

On Sun Nov 04 2001 at 07:47, Harry Putnam <reader@newsguy.com> said:

> Incidently, at the info page you cited, an incremental `i' search
> finds not one instance of `+'

Ah - "+" is the value of bbdb/gnus-summary-known-poster-mark, and it's
used in my gnus-summary-line-format via %ub:

(setq gnus-summary-line-format 
"%U%R|%(%uy%)|%4L|%ub|%-30,30f| %B%s\n")

so I get things like

  |Sun 11/04/01 07:17|  25|+|NAGY Andras                   | Re: possible gnus-sieve bug
  |Sun 11/04/01 08:29|  42|+|Harry Putnam                  | Info URLS
  |Sun 11/04/01 08:33|  14|+|ShengHuo ZHU                  | Re: [PATCH] Bug fix for mail-followup-to
  |Sun 11/04/01 08:49|  15|+|Steinar Bang                  | Re: Sieve support?

and

  |Sat 10/20/01 09:11| 172| |"ewuhe@mail-online.dk" <ewuhe@| FW: Inst antly+Att ract+Women+Sexually!
  |Sun 10/21/01 14:01| 307| |harleyrags@aol.com            | Anti-Aging Is Here !               2063
  |Sun 10/21/01 05:45|  14| |ptodorgh9899@gofree.co.uk     | Anthrax Info                                                   bilab
  |Sun 10/21/01 11:51| 117| |e25717@mail.ru                | $5000 Approvals Guaranteed! Complete Credit Source,
  |Sun 10/21/01 12:21| 186| |JKJMVHVAY@yahoo.com           | Reach The Worlds Rich And Famous                         26146

,----[ <info://bbdb/Reader-specific+Features/Gnus-specific+Features/Gnus+Summary+Buffer+Enhancements> ]
| Marking Posters
|
| [...]
| 
| If no such field is present, the value of
| `bbdb/gnus-summary-known-poster-mark' will be used instead.  If the
| author is not in the BBDB, a space will be used as the mark character.
`----

,----[ C-h v bbdb/gnus-summary-known-poster-mark RET ]
| bbdb/gnus-summary-known-poster-mark's value is "+"
| 
| Documentation:
| This is the default character to prefix author names with if
| bbdb/gnus-summary-mark-known-posters is t.  If the poster's record has
| an entry in the field named by bbdb-message-marker-field, then that will
| be used instead.
| 
| You can customize this variable.
| 
| Defined in `bbdb-gnus'.
`----

Cheers -

bw
-- 
Bill White                                               Office: 5E-Z15
Documentation Programmer                      Phone: 217-398-0700 x 234
Wolfram Research		                      Fax: 217-398-0747
http://members.wri.com/billw    [currently working from home most days]

Re: Generating Mail-Followup-To: headers

[Maciej Matysiak]

On the 2nd of November 2001 at 09:31, Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote:

>> (setq gnus-parameters '(
>> 	("ding-l-.*"
>> 		(to-address . "ding@gnus.org")
>> 		(to-list . "ding@gnus.org"))))
>> it works nice, but why the list address is not visible in 'gnus customize'
>> buffer (in fields 'to address' and 'to list')?
> Well, suppose you have the above in gnus-parameters and then hit `G
> c' on a group ding-l-foo, and change the parameter there.  What
> should happen to the value of gnus-parameters?

it should be overridden by customized value, imho.

> And what should happen to the setq statement which asks the Oracle
> of Delphi to compute the right gnus-parameters value for the current
> phase of the moon?

sorry, i have a terrible headache today ;)

 m.m.
-- 
 use gnus not guns!

Re: Generating Mail-Followup-To: headers

[Per Abrahamsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Ah, I see.  And we can assume that a to-list or to-address group
> parameter means it's a mailing list. 

No we can't at least not "to-list".  I set that for all my "people"
folders, so I can send mail to each person just by pressing "a" while
one their folder.

Maybe "to-address" is safe, but otherwise we need an additional
indication that something is a mailing list.

> Of course, the easy way out is an mft group parameter :-)

A mft boolean plus to-list or to-address (I don't want to edit the
address in two places).

Re: Generating Mail-Followup-To: headers

[Josh Huber]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> No we can't at least not "to-list".  I set that for all my "people"
> folders, so I can send mail to each person just by pressing "a"
> while one their folder.

Ok, so maybe my idea of turning on mft in certain groups was a good
idea after all?

> A mft boolean plus to-list or to-address (I don't want to edit the
> address in two places).

So, we could have a group parameter gnus-use-mft, and to set it for
many groups we could use gnus-parameters?

(setq gnus-parameters
      '(("^mail\\.lists\\..*" (gnus-use-mft . t))))

So, what would be the best way to use this flag?  A meta header like

X-Gnus-Use-MFT: true

that is inserted into the message buffer?

(I forget who suggested this...)

ttyl,

-- 
Josh Huber

Re: Generating Mail-Followup-To: headers

[Per Abrahamsen]

Josh Huber <huber@alum.wpi.edu> writes:

> Ok, so maybe my idea of turning on mft in certain groups was a good
> idea after all?

Yes,

>> A mft boolean plus to-list or to-address (I don't want to edit the
>> address in two places).
> 
> So, we could have a group parameter gnus-use-mft, and to set it for
> many groups we could use gnus-parameters?
> 
> (setq gnus-parameters
>       '(("^mail\\.lists\\..*" (gnus-use-mft . t))))

Yes, except I'd rather call it 'mailing-list' instead 'gnus-use-mft'.
'gnus-' is redundant, and using a generic name for the flag might open
it for other use.

> So, what would be the best way to use this flag?  A meta header like
> 
> X-Gnus-Use-MFT: true

Why not just insert: 

Mail-Followup-To: <(or to-address to-list "")>

?

Re: Generating Mail-Followup-To: headers

[Paul Jarc]

Per Abrahamsen <abraham@dina.kvl.dk> wrote:
> Why not just insert: 
> 
> Mail-Followup-To: <(or to-address to-list "")>

The content of an automatically generated MFT is always copied from
To+Cc just before sending (after editing).  It's like with news: no
Followup-To means "follow up to the same set of recipients".  Mail has
a different default (same recipients+sender), so automatic MFT
provides a default-news-like meaning.  (If you want a different MFT,
you specify it yourself.)  <URL:http://cr.yp.to/proto/replyto.html>


paul

Re: Generating Mail-Followup-To: headers

[Matt Armstrong]

Josh Huber <huber@alum.wpi.edu> writes:

> Per Abrahamsen <abraham@dina.kvl.dk> writes:
> 
>> No we can't at least not "to-list".  I set that for all my "people"
>> folders, so I can send mail to each person just by pressing "a"
>> while one their folder.

I had a lingering suspicion that neither to-list nor to-address always
implied the user was subscribed.

> Ok, so maybe my idea of turning on mft in certain groups was a good
> idea after all?

To be specific, "turning on mft" for a group should only mean that the
to-address or to-list parameters in that group are considered
"subscribed."  I.e. e-mail sent to those addresses will get to you.

>> A mft boolean plus to-list or to-address (I don't want to edit the
>> address in two places).
> 
> So, we could have a group parameter gnus-use-mft, and to set it for
> many groups we could use gnus-parameters?
> 
> (setq gnus-parameters
>       '(("^mail\\.lists\\..*" (gnus-use-mft . t))))

Instead of gnus-use-mft, it should be 'subscribed' or
'is-subscribed'.  Then the description for the parameter can be
something like:

    If subscribed set to t, then the to-address parameter in this
    group is considered to "subscribed" (i.e. mail sent to these
    addresses gets to you).  If to-address is unset, then to-list is
    consulted.

    This parameter makes it a little easier for you to maintain the
    list of groups you are subscribed to.  This list is used in the
    generation of the Mail-Followup-To: header.  See <link:
    Mail-Followup-To generation>.

Can we ignore the to-list parameter?  If set, it should always be
equal to to-address, right?


> So, what would be the best way to use this flag?

This flag replaces your original idea of using a regexp to specify the
list of groups which contain "subscribed" addresses.  Now, we go
through all the groups and ignore those that don't have the
'subscribed' parameter set.


-- 
matt

Re: Generating Mail-Followup-To: headers

[Paul Jarc]

Matt Armstrong <matt@lickey.com> wrote:
> Instead of gnus-use-mft, it should be 'subscribed' or
> 'is-subscribed'.  Then the description for the parameter can be
> something like:
> 
>     If subscribed set to t, then the to-address parameter in this
>     group is considered to "subscribed" (i.e. mail sent to these
>     addresses gets to you).  If to-address is unset, then to-list is
>     consulted.

to-list should be consulted in any case.  There's no reason we can't
use both.

> Can we ignore the to-list parameter?  If set, it should always be
> equal to to-address, right?

to-address is not always set.  to-address is a wrong-side kluge that
attempts to solve the problem that MFT really does solve.  I always
use to-list, and never to-address.  As MFT becomes more widely
supported, to-address will become less useful.

>> So, what would be the best way to use this flag?
> 
> This flag replaces your original idea of using a regexp to specify the
> list of groups which contain "subscribed" addresses.  Now, we go
> through all the groups and ignore those that don't have the
> 'subscribed' parameter set.

Sounds good to me.


paul

Re: Generating Mail-Followup-To: headers

[Matt Armstrong]

prj@po.cwru.edu (Paul Jarc) writes:

> to-address is not always set.  to-address is a wrong-side kluge that
> attempts to solve the problem that MFT really does solve.  I always
> use to-list, and never to-address.  As MFT becomes more widely
> supported, to-address will become less useful.

You're right -- I my understanding was backwards.

I wonder why to-address isn't just a boolean meaning "use to-list for
all followups."


-- 
matt

Re: Generating Mail-Followup-To: headers

[Josh Huber]

Matt Armstrong <matt@lickey.com> writes:

> I wonder why to-address isn't just a boolean meaning "use to-list
> for all followups."

good question...

-- 
Josh Huber

Re: Generating Mail-Followup-To: headers

[Kai Großjohann]

Matt Armstrong <matt@lickey.com> writes:

> I wonder why to-address isn't just a boolean meaning "use to-list for
> all followups."

That's a very good suggestion.  Why not allow `t' as a value in the
meantime?  Then the current semantics could be phased out gradually.

My guess as to why the feature isn't there is hysterical raisins.
Maybe to-address was there first, but then to-list was added because
to-address did too much.

kai
-- 
GNU/Linux provides a nice `poweroff' command, but where is `poweron'?

Re: Generating Mail-Followup-To: headers

[Paul Jarc]

Josh Huber <huber@alum.wpi.edu> wrote:
> Per Abrahamsen <abraham@dina.kvl.dk> writes:
>> No we can't at least not "to-list".  I set that for all my "people"
>> folders, so I can send mail to each person just by pressing "a"
>> while one their folder.
> 
> Ok, so maybe my idea of turning on mft in certain groups was a good
> idea after all?

It should still be determined according to some set of addresses.  We
just shouldn't force all to-list addresses into that set.

The previous idea of having a list of addresses, dynamically augmented
when we send a message, will still work.  Per just won't include all
to-list addresses in his list.

> So, what would be the best way to use this flag?  A meta header like
> 
> X-Gnus-Use-MFT: true
> 
> that is inserted into the message buffer?
> 
> (I forget who suggested this...)

I did, but that was before Matt suggested the list of addresses.  I
don't think it's a good idea anymore.  An automatically generated MFT
is used to prevent followups being copied to the sender, because the
sender will already get a copy through one of the other addresses.  So
MFT generation should always be controlled by the To+Cc list at the
time of [C-c C-c]/[C-c C-s], not beforehand.


paul

Re: Generating Mail-Followup-To: headers

[Per Abrahamsen]

I think Paul Jarc is right:

1. Ignore folders.  
2. No magic headers.
3. A single variable:

(defcustom message-subscribed-lists nil
   "A list of regexps matching mailing list you are subscribed to.

Automatically set the Mail-Followup-To header to the combined content
of the To and CC headers when sending a mail message where an adress
in the To or CC header matches one or more of the entries in this
list.

The effect is that you won't recieve private copies of answers to the
message from users of mail clients that implements the
Mail-Followup-To header."
  :type '(repeat (regexp :tag "List address"))
  :group 'message)

The Mail-Followup-To header is inserted only after the user have
called message-send.

I'd have prefered to do something smart with folders, since I use
folders for everything.  But given the intented content of MFT (= To + Cc),
I don't think that would be robust.

A side advantage of this is that it can be implemented entirely in
Message, with no Gnus knowledge.

Re: Generating Mail-Followup-To: headers

[Paul Jarc]

Per Abrahamsen <abraham@dina.kvl.dk> wrote:
> I think Paul Jarc is right:

I think you may have misunderstood me a bit, or you may be agreeing
with ideas that I don't like anymore. :)

> 1. Ignore folders.  

I would say we should *allow* to-list and to-address to help make the
decision, but not require it.

> 2. No magic headers.

Right.

> 3. A single variable:
> 
> (defcustom message-subscribed-lists nil
>    "A list of regexps matching mailing list you are subscribed to.

This is good as long as it's possible to dynamically augment it from
to-list/to-address during message-send.  I don't want to have to
maintain two copies of the same information.

> I'd have prefered to do something smart with folders, since I use
> folders for everything.  But given the intented content of MFT (= To + Cc),
> I don't think that would be robust.

The content is easy; it's the presence that's tricky.  Using group
parameters is a useful tool here, if not exhaustive.


paul

Re: Generating Mail-Followup-To: headers

[Josh Huber]

prj@po.cwru.edu (Paul Jarc) writes:

[snip]

Okay, I've put together a preliminary patch to message.el against cvs
gnus.  Here it is:

Index: message.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/message.el,v
retrieving revision 6.131
diff -u -r6.131 message.el
--- message.el	2001/10/17 17:53:42	6.131
+++ message.el	2001/10/19 16:52:24
@@ -424,6 +424,24 @@
 		 (const use)
 		 (const ask)))
 
+(defcustom message-mft-address-functions nil
+  "*Specifies functions for determining list subscription.
+If nil, do not attempt to determine list subscribtion with functions.
+If non-nil, this variable contains a list of functions which return
+regular expressions to match lists.  One such useful function might be
+`gnus-get-subscribed-addresses'.  These functions can be used in
+conjunction with `message-mft-regexps'."
+  :group 'message-interface
+  :type '(repeat sexp))
+
+(defcustom message-mft-regexps nil
+  "*Specifies a list of addresses the user is subscribed to.
+If nil, do not use any predefined list subscriptions.  This list of
+regular expressions can be used in conjuction with
+`message-mft-address-functions'."
+  :group 'message-interface
+  :type '(repeat regexp))
+
 (defcustom message-sendmail-f-is-evil nil
   "*Non-nil means don't add \"-f username\" to the sendmail command line.
 Doing so would be even more evil than leaving it out."
@@ -1468,6 +1486,7 @@
   (define-key message-mode-map "\C-c\C-f\C-n" 'message-goto-newsgroups)
   (define-key message-mode-map "\C-c\C-f\C-d" 'message-goto-distribution)
   (define-key message-mode-map "\C-c\C-f\C-f" 'message-goto-followup-to)
+  (define-key message-mode-map "\C-c\C-f\C-m" 'message-goto-mail-followup-to)
   (define-key message-mode-map "\C-c\C-f\C-k" 'message-goto-keywords)
   (define-key message-mode-map "\C-c\C-f\C-u" 'message-goto-summary)
   (define-key message-mode-map "\C-c\C-b" 'message-goto-body)
@@ -1547,6 +1566,7 @@
     ["Keywords" message-goto-keywords t]
     ["Newsgroups" message-goto-newsgroups t]
     ["Followup-To" message-goto-followup-to t]
+    ["Mail-Followup-To" message-goto-mail-followup-to t]
     ["Distribution" message-goto-distribution t]
     ["Body" message-goto-body t]
     ["Signature" message-goto-signature t]))
@@ -1570,6 +1590,7 @@
 	 C-c C-f C-u  move to Summary	C-c C-f C-n  move to Newsgroups
 	 C-c C-f C-k  move to Keywords	C-c C-f C-d  move to Distribution
 	 C-c C-f C-f  move to Followup-To
+         C-c C-f C-m  move to Mail-Followup-To
 C-c C-t  `message-insert-to' (add a To header to a news followup)
 C-c C-n  `message-insert-newsgroups' (add a Newsgroup header to a news reply)
 C-c C-b  `message-goto-body' (move to beginning of message text).
@@ -1714,6 +1735,11 @@
   (interactive)
   (message-position-on-field "Followup-To" "Newsgroups"))
 
+(defun message-goto-mail-followup-to ()
+  "Move point to the Mail-Followup-To header."
+  (interactive)
+  (message-position-on-field "Mail-Followup-To" "From"))
+
 (defun message-goto-keywords ()
   "Move point to the Keywords header."
   (interactive)
@@ -2514,6 +2540,15 @@
       (let ((message-deletable-headers
 	     (if news nil message-deletable-headers)))
 	(message-generate-headers message-required-mail-headers))
+      ;; Generate the Mail-Followup-To header...
+      ;; only if the header doesn't exist.
+      (when (and (or message-mft-regexps message-mft-address-functions)
+		 (not (message-fetch-field "mail-followup-to")))
+	(let ((Mail-Followup-To (message-make-mft)))
+	  (message-generate-headers '((optional . Mail-Followup-To)))))
+      ;; otherwise, delete the MFT header if the value is "off"
+      (and (string= "off" (message-fetch-field "mail-followup-to"))
+	   (message-remove-header "Mail-Followup-To"))
       ;; Let the user do all of the above.
       (run-hooks 'message-header-hook))
     (unwind-protect
@@ -3523,6 +3558,17 @@
   "Return the domain name."
   (or mail-host-address
       (message-make-fqdn)))
+
+(defun message-make-mft ()
+  "Return the Mail-Followup-To header."
+  (let ((recipients (message-options-get 'message-recipients))
+	(mft-regexps (apply 'append message-mft-regexps
+			    (mapcar '(lambda (func) (funcall func))
+				    message-mft-address-functions))))
+    (and (eval `(or ,@(mapcar '(lambda (regexp)
+				 (and regexp (string-match regexp recipients)))
+			      mft-regexps)))
+	 recipients)))
 
 (defun message-generate-headers (headers)
   "Prepare article HEADERS.

Now, there is more to do.  A function which does what we've been
discussing (pulling to-list/to-address from group parameters under
certain cases) has yet to be written -- but, this does allow you to
set message-mft-regexps and have it behave like people want it to.  (I
*THINK*)

There are a couple things I don't like about what I've done so far:

1) is this the proper way to generate the header?  see
   message-send-mail changes.  It just looks a little funny,
2) the macro in message-make-mft is only to get around the fact that
   you can't seem to (apply 'or (nil nil nil nil)) -- elisp won't let
   you use apply on or.  is there a better way to do what I want to
   do?  suggestions about the overall logic there would be good -- I'm
   way out of practice with lisp/scheme.

This code expects the functions called from
message-mft-address-functions to return lists of regular expressions,
and expects message-mft-regexps to be a list of regular expressions.

Who's going to write gnus-subscribed-addresses now? :)

ttyl,

-- 
Josh Huber

Re: Generating Mail-Followup-To: headers

[Josh Huber]

Josh Huber <huber@alum.wpi.edu> writes:

> +      (and (string= "off" (message-fetch-field "mail-followup-to"))
> +	   (message-remove-header "Mail-Followup-To"))

Ah, one more thing.  message-fetch-field returns nil even if the
header is there, but empty, so I've resorted to this hack to disable
MFT generation on a case-by-case basis.  Thoughts?

-- 
Josh Huber

Re: Generating Mail-Followup-To: headers

[Paul Jarc]

Josh Huber <huber@alum.wpi.edu> wrote:
> Josh Huber <huber@alum.wpi.edu> writes:
>> +      (and (string= "off" (message-fetch-field "mail-followup-to"))
>> +	   (message-remove-header "Mail-Followup-To"))
> 
> Ah, one more thing.  message-fetch-field returns nil even if the
> header is there, but empty, so I've resorted to this hack to disable
> MFT generation on a case-by-case basis.  Thoughts?

mail-fetch-field is willing to return "".  We could check for that,
and then use message-fetch-field to get a cleaner string.  That might
be a bit less ugly.  Or maybe it's a bug that message-fetch-field
isn't willing to return ""?


paul

Re: Generating Mail-Followup-To: headers

[Paul Jarc]

I wrote:
> Josh Huber <huber@alum.wpi.edu> wrote:
>> Josh Huber <huber@alum.wpi.edu> writes:
>>> +      (and (string= "off" (message-fetch-field "mail-followup-to"))
>>> +	   (message-remove-header "Mail-Followup-To"))
...
> mail-fetch-field is willing to return "".  We could check for that,
> and then use message-fetch-field to get a cleaner string.

And I just noticed that we don't actually need to get a cleaner string
at all.  So mail-fetch-field alone should work.


paul

Re: Generating Mail-Followup-To: headers

[Josh Huber]

prj@po.cwru.edu (Paul Jarc) writes:

> And I just noticed that we don't actually need to get a cleaner
> string at all.  So mail-fetch-field alone should work.

Indeed...

here's the new version:

Index: message.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/message.el,v
retrieving revision 6.131
diff -u -r6.131 message.el
--- message.el	2001/10/17 17:53:42	6.131
+++ message.el	2001/10/19 20:01:31
@@ -424,6 +424,24 @@
 		 (const use)
 		 (const ask)))
 
+(defcustom message-mft-address-functions nil
+  "*Specifies functions for determining list subscription.
+If nil, do not attempt to determine list subscribtion with functions.
+If non-nil, this variable contains a list of functions which return
+regular expressions to match lists.  One such useful function might be
+`gnus-get-subscribed-addresses'.  These functions can be used in
+conjunction with `message-mft-regexps'."
+  :group 'message-interface
+  :type '(repeat sexp))
+
+(defcustom message-mft-regexps nil
+  "*Specifies a list of addresses the user is subscribed to.
+If nil, do not use any predefined list subscriptions.  This list of
+regular expressions can be used in conjuction with
+`message-mft-address-functions'."
+  :group 'message-interface
+  :type '(repeat regexp))
+
 (defcustom message-sendmail-f-is-evil nil
   "*Non-nil means don't add \"-f username\" to the sendmail command line.
 Doing so would be even more evil than leaving it out."
@@ -1468,6 +1486,7 @@
   (define-key message-mode-map "\C-c\C-f\C-n" 'message-goto-newsgroups)
   (define-key message-mode-map "\C-c\C-f\C-d" 'message-goto-distribution)
   (define-key message-mode-map "\C-c\C-f\C-f" 'message-goto-followup-to)
+  (define-key message-mode-map "\C-c\C-f\C-m" 'message-goto-mail-followup-to)
   (define-key message-mode-map "\C-c\C-f\C-k" 'message-goto-keywords)
   (define-key message-mode-map "\C-c\C-f\C-u" 'message-goto-summary)
   (define-key message-mode-map "\C-c\C-b" 'message-goto-body)
@@ -1547,6 +1566,7 @@
     ["Keywords" message-goto-keywords t]
     ["Newsgroups" message-goto-newsgroups t]
     ["Followup-To" message-goto-followup-to t]
+    ["Mail-Followup-To" message-goto-mail-followup-to t]
     ["Distribution" message-goto-distribution t]
     ["Body" message-goto-body t]
     ["Signature" message-goto-signature t]))
@@ -1570,6 +1590,7 @@
 	 C-c C-f C-u  move to Summary	C-c C-f C-n  move to Newsgroups
 	 C-c C-f C-k  move to Keywords	C-c C-f C-d  move to Distribution
 	 C-c C-f C-f  move to Followup-To
+         C-c C-f C-m  move to Mail-Followup-To
 C-c C-t  `message-insert-to' (add a To header to a news followup)
 C-c C-n  `message-insert-newsgroups' (add a Newsgroup header to a news reply)
 C-c C-b  `message-goto-body' (move to beginning of message text).
@@ -1714,6 +1735,11 @@
   (interactive)
   (message-position-on-field "Followup-To" "Newsgroups"))
 
+(defun message-goto-mail-followup-to ()
+  "Move point to the Mail-Followup-To header."
+  (interactive)
+  (message-position-on-field "Mail-Followup-To" "From"))
+
 (defun message-goto-keywords ()
   "Move point to the Keywords header."
   (interactive)
@@ -2514,6 +2540,15 @@
       (let ((message-deletable-headers
 	     (if news nil message-deletable-headers)))
 	(message-generate-headers message-required-mail-headers))
+      ;; Generate the Mail-Followup-To header...
+      ;; only if the header doesn't exist.
+      (when (and (or message-mft-regexps message-mft-address-functions)
+		 (not (message-fetch-field "mail-followup-to")))
+	(let ((Mail-Followup-To (message-make-mft)))
+	  (message-generate-headers '((optional . Mail-Followup-To)))))
+      ;; otherwise, delete the MFT header if the field is empty
+      (and (string= "" (mail-fetch-field "mail-followup-to"))
+	   (message-remove-header "Mail-Followup-To"))
       ;; Let the user do all of the above.
       (run-hooks 'message-header-hook))
     (unwind-protect
@@ -3523,6 +3558,17 @@
   "Return the domain name."
   (or mail-host-address
       (message-make-fqdn)))
+
+(defun message-make-mft ()
+  "Return the Mail-Followup-To header."
+  (let ((recipients (message-options-get 'message-recipients))
+	(mft-regexps (apply 'append message-mft-regexps
+			    (mapcar '(lambda (func) (funcall func))
+				    message-mft-address-functions))))
+    (and (eval `(or ,@(mapcar '(lambda (regexp)
+				 (and regexp (string-match regexp recipients)))
+			      mft-regexps)))
+	 recipients)))
 
 (defun message-generate-headers (headers)
   "Prepare article HEADERS.


here's a little support code for enabling it look at the group
parameters:

;;*===========================
;;* Mail-Followup-To settings

(setq gnus-parameters
      '(("^mail\\.lists\\." (subscribed . t))))

(defun jmh-find-subscribed-addresses ()
  (delete-if
   nil (mapcar '(lambda (group)
		  (or (gnus-group-find-parameter group 'to-address)
		      (gnus-group-find-parameter group 'to-list)))
	       (delete-if-not '(lambda (group)
				 (gnus-group-find-parameter
				  group 'subscribed))
			      (mapcar '(lambda (item) (car item))
				      gnus-newsrc-alist)))))

(add-to-list 'message-mft-address-functions
	     (lambda ()
	       (mapcar 'regexp-quote (jmh-find-subscribed-addresses))))



Does anyone have any suggestions?

Running the -find-subscribed-addresses just once as a utility function
and storing those values in the message-mft-regexps variable would be
a good idea, especially since, at least my version, seems to run
pretty slow. (.5 second pause)

ttyl,

-- 
Josh Huber

Re: Generating Mail-Followup-To: headers

[Matt Armstrong]

Josh Huber <huber@alum.wpi.edu> writes:

> +(defcustom message-mft-address-functions nil
> +  "*Specifies functions for determining list subscription.
> +If nil, do not attempt to determine list subscribtion with functions.
> +If non-nil, this variable contains a list of functions which return
> +regular expressions to match lists.  One such useful function might be
> +`gnus-get-subscribed-addresses'.  These functions can be used in
> +conjunction with `message-mft-regexps'."
> +  :group 'message-interface
> +  :type '(repeat sexp))
> +
> +(defcustom message-mft-regexps nil
> +  "*Specifies a list of addresses the user is subscribed to.
> +If nil, do not use any predefined list subscriptions.  This list of
> +regular expressions can be used in conjuction with
> +`message-mft-address-functions'."
> +  :group 'message-interface
> +  :type '(repeat regexp))

This is getting pretty cool!

Since these are specifying a list of subscribed addresses, can the
variables be message-subscribed-* instead of message-mft-*?

Also, I don't think they should be regexps.  I can't think of a case
where I could described more than one list I'm subscribed to with a
regexp.  Even if I could I won't like having to explicitly escape all
the '.' and other characters in the list addresses.

I suppose in a contrived example, you could specify
"topic-.*@list\\.example\\.com" to get topic-devel, topic-user,
etc. but these cases are rare and people can just explicitly list all
of them.

So if we really want regexps, maybe:

   message-subscribed-address-functions
   message-subscribed-address-regexps
   message-subscribed-addresses

I notice the code is doing regexp matches with strings pulled out of
to-address and to-list -- technically incorrect since those aren't
regexps.

-- 
matt

Re: Generating Mail-Followup-To: headers

[Paul Jarc]

Matt Armstrong <matt@lickey.com> wrote:
> Also, I don't think they should be regexps.

I'm on the fence.

> I can't think of a case where I could described more than one list
> I'm subscribed to with a regexp.

I can: ".*@list\.cr\.yp\.to".  But I still wouldn't necessarily use
this; I'd probably generate the list from my to-list parameters.

> Even if I could I won't like having to explicitly escape all the '.'
> and other characters in the list addresses.

Do you know about regexp-quote?

> I suppose in a contrived example, you could specify
> "topic-.*@list\\.example\\.com" to get topic-devel, topic-user,
> etc. but these cases are rare and people can just explicitly list all
> of them.

I don't think they're very rare.  But they are certainly finite, so
specifying them individually could still work.

> So if we really want regexps, maybe:
> 
>    message-subscribed-address-functions
>    message-subscribed-address-regexps
>    message-subscribed-addresses

Maybe.  The Gnus way is typically to just do regexps, though.

> I notice the code is doing regexp matches with strings pulled out of
> to-address and to-list -- technically incorrect since those aren't
> regexps.

You didn't notice the use of regexp-quote, then.  Of course, the use
of it suggests that perhaps regexps should not be used.


paul

Re: Generating Mail-Followup-To: headers

[Josh Huber]

prj@po.cwru.edu (Paul Jarc) writes:

> Matt Armstrong <matt@lickey.com> wrote:
>> Also, I don't think they should be regexps.
> 
> I'm on the fence.

I think they should be regexps.  As you say below, the user can just
use regexp-quote to get something that matches exactly, and I'd like
the ability to use a regexp.  (debian-.*@lists.debian.org for example)

> Maybe.  The Gnus way is typically to just do regexps, though.

I agree

-- 
Josh Huber

Re: Generating Mail-Followup-To: headers

[Per Abrahamsen]

prj@po.cwru.edu (Paul Jarc) writes:

> Matt Armstrong <matt@lickey.com> wrote:
>
>> Even if I could I won't like having to explicitly escape all the '.'
>> and other characters in the list addresses.
> 
> Do you know about regexp-quote?

It doesn't help when setting the variable though customize, which is
the most likely case for a user uncomfortable with regexps.

>> I suppose in a contrived example, you could specify
>> "topic-.*@list\\.example\\.com" to get topic-devel, topic-user,
>> etc. but these cases are rare and people can just explicitly list all
>> of them.
> 
> I don't think they're very rare.  But they are certainly finite, so
> specifying them individually could still work.

I think they are uncommon enough that even for the experienced user,
listing them all explicitly would be easier

Re: Generating Mail-Followup-To: headers

[Matt Armstrong]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> prj@po.cwru.edu (Paul Jarc) writes:
> 
>> Matt Armstrong <matt@lickey.com> wrote:
>>
>>> Even if I could I won't like having to explicitly escape all the '.'
>>> and other characters in the list addresses.
>> 
>> Do you know about regexp-quote?
> 
> It doesn't help when setting the variable though customize, which is
> the most likely case for a user uncomfortable with regexps.

The customize argument is a good point.


>>> I suppose in a contrived example, you could specify
>>> "topic-.*@list\\.example\\.com" to get topic-devel, topic-user,
>>> etc. but these cases are rare and people can just explicitly list all
>>> of them.
>> 
>> I don't think they're very rare.  But they are certainly finite, so
>> specifying them individually could still work.
> 
> I think they are uncommon enough that even for the experienced user,
> listing them all explicitly would be easier

It would not hurt to have one variable for a list of addresses and one
variable that is a list of regexp.  This satisfies experts without
burdening newbies.

Not that any emacs newbie would ever be successful at using Gnus
without serious effort.  ;-)


-- 
matt

Re: Generating Mail-Followup-To: headers

[Paul Jarc]

Josh Huber <huber@alum.wpi.edu> wrote:
> +      ;; Generate the Mail-Followup-To header...
> +      ;; only if the header doesn't exist.
> +      (when (and (or message-mft-regexps message-mft-address-functions)
> +		 (not (message-fetch-field "mail-followup-to")))
> +	(let ((Mail-Followup-To (message-make-mft)))
> +	  (message-generate-headers '((optional . Mail-Followup-To)))))

That will use the symbol 'Mail-Followup-To, not its variable value.
We want this:
      (message-generate-headers `((optional . ,Mail-Followup-To)))))
Or this:
      (message-generate-headers (list (cons 'optional Mail-Followup-To)))))

We should also check that this is a mail message, not news.

> +      ;; otherwise, delete the MFT header if the value is "off"
> +      (and (string= "off" (message-fetch-field "mail-followup-to"))
> +	   (message-remove-header "Mail-Followup-To"))

I'd use equal, not string=, or else restructure the logic so that when
we reach this point, we already know that there is an MFT field.  It
happens that string= will interpret the value nil as the string "nil",
and so this will still work as-is, but relying on that just scares me.

> +(defun message-make-mft ()
> +  "Return the Mail-Followup-To header."
> +  (let ((recipients (message-options-get 'message-recipients))
> +	(mft-regexps (apply 'append message-mft-regexps
> +			    (mapcar '(lambda (func) (funcall func))
> +				    message-mft-address-functions))))
> +    (and (eval `(or ,@(mapcar '(lambda (regexp)
> +				 (and regexp (string-match regexp recipients)))
> +			      mft-regexps)))
> +	 recipients)))

Rather than match all regexps against the recipients, and then look
for a non-nil result, we could iterate through the regexp list and
stop as soon as we find a match.  It'd also be better to match
each regexp against each recipient address individually, using only
the address itself and not the name part, instead of against the whole
recipient string.

> Who's going to write gnus-subscribed-addresses now? :)

I volunteer to intend to do it until someone actually does it.  (Hey,
it worked once.)


paul

Re: Generating Mail-Followup-To: headers

[Josh Huber]

prj@po.cwru.edu (Paul Jarc) writes:

> That will use the symbol 'Mail-Followup-To, not its variable value.
> We want this:
>       (message-generate-headers `((optional . ,Mail-Followup-To)))))
> Or this:
>       (message-generate-headers (list (cons 'optional Mail-Followup-To)))))

Okay, my cluelessness about macros, etc is showing.

Notice my hack above:

(let ((Mail-Followup-To (message-make-mft)))
     (message-generate-headers '(optional . Mail-Followup-To))))

This works, but I think because message-generate-headers uses the
symbol name for the header name, and the variable value for the value
of the header.

if I did `((optional . ,Mail-Followup-To)), what would it use for the
header name?  Wouldn't the value be spliced in, so how would it know
what to use?

hmm... that function is confusing anyway.  what I really want to do is
pass in the equivilant of this information:

1. the header is optional (this way it won't ask the user for it if it's
   empty)
2. the header name is "Mail-Followup-To"
3. the header value is "..."

Can someone enlighten me as to how this is supposed to be done?  Am I
supposed to set the symbol Mail-Followup-To to the contents of the
header?  Is there another way?

> We should also check that this is a mail message, not news.

I'm confused.  At the top, inside the first let there is a
(message-this-is-mail t), but below there are checks to see if this is
news...for example:

... (if news nil message-deletable-headers) ...

so...what is this?  message-send-mail, but sometimes it's used for
news?

> I'd use equal, not string=, or else restructure the logic so that
> when we reach this point, we already know that there is an MFT
> field.  It happens that string= will interpret the value nil as the
> string "nil", and so this will still work as-is, but relying on that
> just scares me.

Okay, I changed it around and use equal instead.

> Rather than match all regexps against the recipients, and then look
> for a non-nil result, we could iterate through the regexp list and
> stop as soon as we find a match.  It'd also be better to match each
> regexp against each recipient address individually, using only the
> address itself and not the name part, instead of against the whole
> recipient string.

Yeah, that would be better, but extracting the address part might be
hard. (have you seen the regexp in the Mastering Regular Expressions
book for matching an email address?)

I can see splitting the string up by ',' and interatively checking
each one of those with each of the regular expressions.

Of course, if your regex's are exact enough, then it should work :P

(btw, this setup seems to work for me with the utility function I
posted for reading all the to-address/list values from group
parameters)

ttyl,

-- 
Josh Huber

Re: Generating Mail-Followup-To: headers

[Paul Jarc]

Josh Huber <huber@alum.wpi.edu> wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
>>       (message-generate-headers `((optional . ,Mail-Followup-To)))))
> 
> Okay, my cluelessness about macros, etc is showing.

Heh.  A macro looks like (defmacro name (args) body).  I forget what
`(,these) forms are called, but they're not "macros".

> Notice my hack above:
> 
> (let ((Mail-Followup-To (message-make-mft)))
>      (message-generate-headers '(optional . Mail-Followup-To))))
> 
> This works, but I think because message-generate-headers uses the
> symbol name for the header name, and the variable value for the value
> of the header.

Oops, I missed that.  We would want the symbol here, then.

> hmm... that function is confusing anyway.  what I really want to do is
> pass in the equivilant of this information:
> 
> 1. the header is optional (this way it won't ask the user for it if it's
>    empty)
> 2. the header name is "Mail-Followup-To"
> 3. the header value is "..."

A quick test says this should work:
  (message-generate-headers `(("Mail-Followup-To" . ,(message-make-mft))))
We're giving it a non-empty value, so 'optional shouldn't matter.  And
the code in message-generate-headers that doesn't use 'optional is
less confusing that the code that does, so I'm more confident than I
would be if I had tried to use 'optional.

> Yeah, that would be better, but extracting the address part might be
> hard. (have you seen the regexp in the Mastering Regular Expressions
> book for matching an email address?)

Fortunately, it's already done.  This is from
message-get-reply-headers (with my patch from yesterday):
      ;; Convert string to a list of (("foo@bar" . "Name <foo@bar>") ...).
      (setq recipients
	    (mapcar
	     (lambda (addr)
	       (cons (mail-strip-quoted-names addr) addr))
	     (message-tokenize-header recipients)))


paul

Re: Generating Mail-Followup-To: headers

[Josh Huber]

prj@po.cwru.edu (Paul Jarc) writes:

> Heh.  A macro looks like (defmacro name (args) body).  I forget what
> `(,these) forms are called, but they're not "macros".

Okay, you're right, but they're very often used in macros
(right?)...they're templates, and C-h f backquote tells me things
about them.

> A quick test says this should work:
>   (message-generate-headers `(("Mail-Followup-To" . ,(message-make-mft))))
> We're giving it a non-empty value, so 'optional shouldn't matter.
> And the code in message-generate-headers that doesn't use 'optional
> is less confusing that the code that does, so I'm more confident
> than I would be if I had tried to use 'optional.

Okay, this looks good.  Thanks for figuring this one out :)

> Fortunately, it's already done.  This is from
> message-get-reply-headers (with my patch from yesterday):
>       ;; Convert string to a list of (("foo@bar" . "Name <foo@bar>") ...).
>       (setq recipients
> 	    (mapcar
> 	     (lambda (addr)
> 	       (cons (mail-strip-quoted-names addr) addr))
> 	     (message-tokenize-header recipients)))

ok, cool.  I'll post a new version soon.

-- 
Josh Huber

Re: Generating Mail-Followup-To: headers

[Kai Großjohann]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> 3. A single variable:
> 
> (defcustom message-subscribed-lists nil
>    "A list of regexps matching mailing list you are subscribed to.

What's so bad about using group parameters for this?

There is already more machinery in Gnus than most people will ever
need for setting group parameters: by group name regexp (variable
gnus-parameters), by topic hierarchy, separately for each group.

Oh, one difference would be that my suggestion goes by the group name,
but your suggestion goes by the mail address.  Hm.  Why is it
necessary to do it by mail address?

kai
-- 
GNU/Linux provides a nice `poweroff' command, but where is `poweron'?

Re: Generating Mail-Followup-To: headers

[Josh Huber]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> What's so bad about using group parameters for this?
> 
> There is already more machinery in Gnus than most people will ever
> need for setting group parameters: by group name regexp (variable
> gnus-parameters), by topic hierarchy, separately for each group.
> 
> Oh, one difference would be that my suggestion goes by the group
> name, but your suggestion goes by the mail address.  Hm.  Why is it
> necessary to do it by mail address?

I think it's nice to use the group parameters for this, in addition to
having a list of additional regular expressions to use. (just for
flexibility & completeness...

take a look at this function I just whipped up:

(defun gnus-find-subscribed-addresses ()
  (delete-if
   nil (mapcar '(lambda (group)
		  (or (gnus-group-find-parameter group 'to-address)
		      (gnus-group-find-parameter group 'to-list)))
	       (delete-if-not '(lambda (group)
				 (gnus-group-find-parameter
				  group 'subscribed))
			      (mapcar '(lambda (item) (car item))
				      gnus-newsrc-alist)))))

I'm pretty sure that I shouldn't be just accessing gnus-newsrc-alist
directly -- someone tell me what I should be doing.

oh, and you'll need something like this:

(setq gnus-parameters
      '(("^mail\\.lists\\." (subscribed . t))))

otherwise none of the groups will have the "subscribed" parameter set.

ttyl,

-- 
Josh Huber

Re: Generating Mail-Followup-To: headers

[Matt Armstrong]

Josh Huber <huber@alum.wpi.edu> writes:

> take a look at this function I just whipped up:
> 
> (defun gnus-find-subscribed-addresses ()
>   (delete-if
>    nil (mapcar '(lambda (group)
> 		  (or (gnus-group-find-parameter group 'to-address)
> 		      (gnus-group-find-parameter group 'to-list)))
> 	       (delete-if-not '(lambda (group)
> 				 (gnus-group-find-parameter
> 				  group 'subscribed))
> 			      (mapcar '(lambda (item) (car item))
> 				      gnus-newsrc-alist)))))
> 
> I'm pretty sure that I shouldn't be just accessing gnus-newsrc-alist
> directly -- someone tell me what I should be doing.
>
> oh, and you'll need something like this:
> 
> (setq gnus-parameters
>       '(("^mail\\.lists\\." (subscribed . t))))

Way cool!

gnus-group-prepare-flat skips the first element of gnus-newsrc-alist
(which appears to always be a dummy group).  Besides that, it looks
like that is the best way to get at all the group names.

Here is the same thing in a procedural style that I can actually
understand.  :-)

(defun gnus-find-subscribed-addresses ()
  (let ((newsrc (cdr gnus-newsrc-alist))
	group address list)
    (while newsrc
      (setq group (car (car newsrc))
	    newsrc (cdr newsrc))
      (if (and (gnus-group-find-parameter group 'subscribed)
	       (setq address (or (gnus-group-find-parameter group 'to-address)
				 (gnus-group-find-parameter group 'to-list))))
	  (setq list (cons address list))))
    list))

-- 
matt

Re: Generating Mail-Followup-To: headers

[Josh Huber]

Matt Armstrong <matt@lickey.com> writes:

> Here is the same thing in a procedural style that I can actually
> understand.  :-)

Hehe...hmm.  I guess I never learned to use iteration much in lisp,
since I learned scheme first...for a class.  Everything was
recursive.  For some reason it just looks bad (I know it's probably
not, though) when I see procedural lisp.... :P

[snip new version]

ttyl,

-- 
Josh Huber

Re: Generating Mail-Followup-To: headers

[Kai Großjohann]

Matt Armstrong <matt@lickey.com> writes:

> Here is the same thing in a procedural style that I can actually
> understand.  :-)

I like Josh's version.  Just look at code like this for a while, and
you will see.  It takes some training to see the beauty.  Once you see
the light, you'll never want to miss this kind of stuff.

Sadly, delete-if and its ilk are in CL, and RMS wants us to write code
which does not require CL.  :-(

kai (great fan of `map' and `grep' in Perl)
-- 
GNU/Linux provides a nice `poweroff' command, but where is `poweron'?

Re: Generating Mail-Followup-To: headers

[Matt Armstrong]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Matt Armstrong <matt@lickey.com> writes:
> 
>> Here is the same thing in a procedural style that I can actually
>> understand.  :-)
> 
> I like Josh's version.  Just look at code like this for a while, and
> you will see.  It takes some training to see the beauty.  Once you see
> the light, you'll never want to miss this kind of stuff.

I agree that there is a certain elegance to the functional version.


> Sadly, delete-if and its ilk are in CL, and RMS wants us to write code
> which does not require CL.  :-(

message.el already does (require 'cl).  It is all over the Gnus code
base.


-- 
matt

Re: Generating Mail-Followup-To: headers

[Kai Großjohann]

Matt Armstrong <matt@lickey.com> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> 
>> Sadly, delete-if and its ilk are in CL, and RMS wants us to write code
>> which does not require CL.  :-(
> 
> message.el already does (require 'cl).  It is all over the Gnus code
> base.

Oh.

kai
-- 
Lisp is kinda like tpircstsoP

Re: Generating Mail-Followup-To: headers

[ShengHuo ZHU]

Matt Armstrong <matt@lickey.com> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

[...]

>> Sadly, delete-if and its ilk are in CL, and RMS wants us to write code
>> which does not require CL.  :-(
> 
> message.el already does (require 'cl).  It is all over the Gnus code
> base.

Gnus requires CL during compiling time, not running time.  For this
reason, gnus-delete-if exists.

ShengHuo

Re: Generating Mail-Followup-To: headers

[Paul Jarc]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote:
> RMS wants us to write code which does not require CL.  :-(

Why?


paul

Re: Generating Mail-Followup-To: headers

[Kai Großjohann]

prj@po.cwru.edu (Paul Jarc) writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote:
>> RMS wants us to write code which does not require CL.  :-(
> 
> Why?

I think he says something about overhead.  My guess is that he wants
to move to Scheme, so using too many CL features in Emacs Lisp is not
good for that move.  But this is just a guess.

kai
-- 
Lisp is kinda like tpircstsoP

Re: Generating Mail-Followup-To: headers

[Josh Huber]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> I like Josh's version.  Just look at code like this for a while, and
> you will see.  It takes some training to see the beauty.  Once you
> see the light, you'll never want to miss this kind of stuff.

:)

You know, the amazing thing is, I never learned lisp -- but only
scheme.  Emacs' amazingly useful ways to lookup functions makes it
pretty easy for me to learn:

"okay, I want a function that deletes elements under certain
conditions...

C-h f delete <tab><tab>

ah hah, delete-if(-not)?

or M-x apropos"

etc etc etc

very nice! :)  It really is a nice development environment...

> Sadly, delete-if and its ilk are in CL, and RMS wants us to write
> code which does not require CL.  :-(

why is that?

> kai (great fan of `map' and `grep' in Perl)

mmm, me too :)

-- 
Josh Huber

Re: Generating Mail-Followup-To: headers

[Matt Armstrong]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Per Abrahamsen <abraham@dina.kvl.dk> writes:
> 
>> 3. A single variable:
>> 
>> (defcustom message-subscribed-lists nil
>>    "A list of regexps matching mailing list you are subscribed to.
> 
> What's so bad about using group parameters for this?

1) to-address and to-list do not necessarily imply that you're
   subscribed to those addresses (see Per's mail).

2) Not every list you're subscribed to has its own group (see one of
   my early posts in this thread).

3) Group parameters are supposed to apply to the current group.  The
   list of groups you're subscribed to is a global thing and does not
   change when you change groups.

It is perfectly okay to optionally seed the list of subscribed e-mail
addresses from group parameters (to-address), but it won't be
exhaustive or necessarily correct.  That's why I think there should be
a group parameter "subscribed" that, when present, indicates that
to-address is a list you're subscribed to.  Code can go through the
parameters for all the groups doing "use to-address if subscribed."

> Oh, one difference would be that my suggestion goes by the group
> name, but your suggestion goes by the mail address.  Hm.  Why is it
> necessary to do it by mail address?

It should become clear upon reading the spec for Mail-Followup-To:

	http://cr.yp.to/proto/replyto.html


-- 
matt

Re: Generating Mail-Followup-To: headers

[Kai Großjohann]

Matt Armstrong <matt@lickey.com> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> 
>> Per Abrahamsen <abraham@dina.kvl.dk> writes:
>> 
>>> 3. A single variable:
>>> 
>>> (defcustom message-subscribed-lists nil
>>>    "A list of regexps matching mailing list you are subscribed to.
>> 
>> What's so bad about using group parameters for this?
> 
> 1) to-address and to-list do not necessarily imply that you're
>    subscribed to those addresses (see Per's mail).

I'm sorry for not making it clear that I meant a _new_ group
parameter.

I thought that the only thing we need is to say `don't include me in
the list of addresses in MFT'.  All the rest follows, right?  (If the
original message has MFT, then we don't want to frob it, except maybe
delete ourselves from it.  I think.)

But I shall read the spec to make sure I'm not misunderstanding anything.

> 2) Not every list you're subscribed to has its own group (see one of
>    my early posts in this thread).

This is a valid point.  Hm.

kai
-- 
GNU/Linux provides a nice `poweroff' command, but where is `poweron'?

Re: Generating Mail-Followup-To: headers

[Kai Großjohann]

Matt Armstrong <matt@lickey.com> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>
>> Oh, one difference would be that my suggestion goes by the group
>> name, but your suggestion goes by the mail address.  Hm.  Why is it
>> necessary to do it by mail address?
> 
> It should become clear upon reading the spec for Mail-Followup-To:
> 
> 	http://cr.yp.to/proto/replyto.html

Okay, I have now read that spec.  It seems the intention is mainly to
prevent authors to get two copies.  So I think a useful implementation
makes this intention easy, and the rest possible.

Now let's talk about how to prevent the author from getting two
copies.  This can be done by either taking the MFT that's present in
the original message, or by taking the default from To/Cc/Reply-to.
And then we just delete all addresses matching
gnus-ignored-from-addresses from the thusly generated MFT.

Hm.  Of course, this potentially suffers from
gnus-ignored-from-addresses being the wrong variable.

Hm.

Ah, _now_ I see the point: all you need is a list of addresses that
reaches you, and then you can do the MFT generation from that.  As I
described above.

Okay, I think I'm convinced now.

I'm also convinced that pre-initialization of this list can be done
from all the to-list/to-addresses parameters of all groups.

Sorry to be such a bone-head.

kai
-- 
GNU/Linux provides a nice `poweroff' command, but where is `poweron'?

Re: Generating Mail-Followup-To: headers

[Per Abrahamsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> What's so bad about using group parameters for this?

When I have been talking about group parameters, I have always been
imagining sending the mail from inside some folder (or with C-u a from
the *Groups* buffer), and looking at the group parameters for the
current group.  In that case it is not robust, since you may send
messages from outside folders, or from other folders than the one
associated with the list.

However, if we are talking about code that iterate through all the
groups and note the (to-list / to-address), and compare that list with
the to/cc in order to decide whether to generate mft header, that is
an entirely different and much cooler case.

Re: Generating Mail-Followup-To: headers

[Kai Großjohann]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> 
>> What's so bad about using group parameters for this?
> 
> When I have been talking about group parameters, I have always been
> imagining sending the mail from inside some folder (or with C-u a from
> the *Groups* buffer), and looking at the group parameters for the
> current group.  In that case it is not robust, since you may send
> messages from outside folders, or from other folders than the one
> associated with the list.

Well, after some thinking I now see why a single list of all addresses
which send mail to me is better than doing it per-group.

> However, if we are talking about code that iterate through all the
> groups and note the (to-list / to-address), and compare that list with
> the to/cc in order to decide whether to generate mft header, that is
> an entirely different and much cooler case.

:-)  Yes, the list of addresses could be initialized/augmented from
the group parameters on startup.

kai
-- 
Lisp is kinda like tpircstsoP

Re: Generating Mail-Followup-To: headers

[Kai Großjohann]

Josh Huber <huber@alum.wpi.edu> writes:

> So, what would be the best way to use this flag?  A meta header like
> 
> X-Gnus-Use-MFT: true
> 
> that is inserted into the message buffer?

There is already the X-Draft-From header which can be used to locate
the group parameter, so I think the extra header is not necessary.

kai
-- 
GNU/Linux provides a nice `poweroff' command, but where is `poweron'?

Re: Generating Mail-Followup-To: headers

[Paul Jarc]

Matt Armstrong <matt@lickey.com> wrote:
> I was thinking of a global variable holding all subscribed lists --
> just a list of addresses:
>
>      (setq message-subscribed-addresses '("ding" "postfix-users"))

Those should definitely be complete addresses (or regexps), not just
the local parts.  Aside from that, this could be a useful: if any of
the addressees matches one of these, then we generate MFT based on all
of To+Cc.  I'd call the variable message-mft-addresses or
message-mft-regexps, though.

> There could even be utility functions that read ~/.lists (for Qmail
> users) and that goes through all the Gnus group parameters looking for
> to-address parameters, as well as extracting stuff from
> gnus-parameter-to-address-alist.

I'm not sure how useful the ~/.lists function would be - qmail users
already get MFT from qmail-inject with ~/.lists.  But yes, it should
definitely be possible to maintain message-mft-regexps automatically.

> This could be controlled by a list of functions that produce
> additional addresses:
>
>     (setq message-subscribed-addresses-functions
>           '(message-subscribed-addresses-qmail
>             gnus-get-subscribed-addresses))
>
> With this list available, all Mail-Followup-To: generation can be done
> right before the message is sent.

Ok, so when sending a message, we do something like this:
if there is an existing MFT:
  if it's empty:
    remove it ;; this lets the user turn off MFT for a single message
              ;; when it would otherwise be added automatically
  else: leave it as-is
else:
  (let ((message-mft-regexps message-mft-regexps))
    (when message-mft-addresses-functions
      call each function, adding its returned regexps to m-m-r
      )
    check each address in To+Cc against each pattern in m-m-r
    if any match is found, put all To+Cc addresses in a new MFT
  )
Sound good?  People who don't want to call all those functions for
evey message can construct m-m-r once and leave m-m-a-f as nil.


paul

Re: Generating Mail-Followup-To: headers

[Josh Huber]

prj@po.cwru.edu (Paul Jarc) writes:

> I'm thinking something in gnus-msg.el, during initialization of a
> new message buffer, can detect when there is a to-list or to-address
> parameter for the current group; if so, it'll add a header field
> like "X-Gnus-Generate-MFT: yes" (by default; it could be disabled by
> setting some variable).  Then when we send the message, if that
> field is present, we remove it, and if there is also no existing
> MFT, then we add one based on To+Cc.

I was just thinking about this as well.

It would be nice to have a list of regexs that specify which groups
mft header generation should be turned on for:

(setq gnus-mail-followup-to-matches
      '(("^mail.lists" 'subscribe)
        (".*" 'list)))

...just for example.  if a regex matches, the rule is used.

the names here are just from mutt (subscribe, and lists are the two
commands.  If a list is marked as "subscribe" you are not added to the
Mail-Followup-To header, if it's marked as "list" you are added to the
header)

I was just thinking about starting work on this...

it seems other people want this feature as well? :)

-- 
Josh Huber

Re: Generating Mail-Followup-To: headers

[Paul Jarc]

Josh Huber <huber@alum.wpi.edu> wrote:
> (setq gnus-mail-followup-to-matches
>       '(("^mail.lists" 'subscribe)
>         (".*" 'list)))
>
> ...just for example.  if a regex matches, the rule is used.
>
> the names here are just from mutt (subscribe, and lists are the two
> commands.  If a list is marked as "subscribe" you are not added to the
> Mail-Followup-To header, if it's marked as "list" you are added to the
> header)

MFT consisting of To+Cc+(From/Reply-To/Mail-Reply-To) is equivalent to
no MFT at all; we don't need to generate MFT for such a case.

As far as determining whether to include the sender (equivalently,
whether to generate MFT), I think I like Matt's idea better.  Certain
addressees are better determinants than certain groups.

> it seems other people want this feature as well? :)

Quite.  I'm tired of having to maintain my list-address file for
qmail-inject separately from my to-list parameters.


paul

Re: Generating Mail-Followup-To: headers

[Josh Huber]

prj@po.cwru.edu (Paul Jarc) writes:

> As far as determining whether to include the sender (equivalently,
> whether to generate MFT), I think I like Matt's idea better.
> Certain addressees are better determinants than certain groups.

True.  I agree.

I was trying to think of a way to not have to specify duplicate
address to the ones I've already listed in the group configuration.

How about

(setq gnus-mft-use-group-address
      "^mail.lists")

In addition to specifying the specific address?  That way, when Gnus
went through and looked at the message-subscribed-addresses variable
we could do something like...

(let message-subscribed-addresses
     (append message-subscribed-addresses
             (mapcar '(lambda (group) (gnus-fetch-group-address
                                        group))
                     (gnus-group-find-groups
                                gnus-mft-use-group-address))))

using the theoretical gnus-fetch-group-address and
gnus-group-find-groups.

after a quick check there is gnus-group-apropos, but I couldn't find
anyting that returned a *list* of groups matched, rather than showing
a list in a buffer...perhaps I just missed it.

gnud-fetch-group-address should get either the to-address or the
to-list (whichever comes first?)

> Quite.  I'm tired of having to maintain my list-address file for
> qmail-inject separately from my to-list parameters.

Yes, and I'm tired of not having this feature after switching from
mutt a while back.  It hasn't been that annoying, but MFT is more
powerful/configuable than MCT, so I'd really like to have it in Gnus!

ttyl,
-- 
Josh Huber

Re: Generating Mail-Followup-To: headers

[Matt Armstrong]

Josh Huber <huber@alum.wpi.edu> writes:

> prj@po.cwru.edu (Paul Jarc) writes:
> 
>> As far as determining whether to include the sender (equivalently,
>> whether to generate MFT), I think I like Matt's idea better.
>> Certain addressees are better determinants than certain groups.
> 
> True.  I agree.
> 
> I was trying to think of a way to not have to specify duplicate
> address to the ones I've already listed in the group configuration.
> 
> How about
> 
> (setq gnus-mft-use-group-address
>       "^mail.lists")
> 
> In addition to specifying the specific address?  That way, when Gnus
> went through and looked at the message-subscribed-addresses variable
> we could do something like...
> 
> (let message-subscribed-addresses
>      (append message-subscribed-addresses
>              (mapcar '(lambda (group) (gnus-fetch-group-address
>                                         group))
>                      (gnus-group-find-groups
>                                 gnus-mft-use-group-address))))
> 
> using the theoretical gnus-fetch-group-address and
> gnus-group-find-groups.

Yes, your mapcar call is to how I was thinking
gnus-get-subscribed-addresses would be implemented in my earlier mail.
Implementing gnus-group-find-groups and gnus-fetch-group-address may
be the hardest part.

I am not sure gnus-mft-use-group-address has much point in being a
regexp.  I'd say it should at least traverse all groups when set to
't.

I still think there should be a list of functions (a hook) that the
user can set up to return additional subscribed addresses.  I maintain
a list outside of Gnus for the purpose of generating procmail
filtering rules.  Getting to-address and to-list addresses from group
parameters is just a special case of this.


But it sounds like we all have similar ideas.  My elisp is very weak,
so I would not mind if your or anybody else took the first stab at
implementation.  :-)

-- 
matt

Re: Generating Mail-Followup-To: headers

[Josh Huber]

Matt Armstrong <matt@lickey.com> writes:

> Yes, your mapcar call is to how I was thinking
> gnus-get-subscribed-addresses would be implemented in my earlier
> mail.  Implementing gnus-group-find-groups and
> gnus-fetch-group-address may be the hardest part.

Ok, I'll try and figure out what the best way to do this is...

> I am not sure gnus-mft-use-group-address has much point in being a
> regexp.  I'd say it should at least traverse all groups when set to
> 't.

Agreed.  I think we can assume that if a to-list or to-address value
is set for a group, it's a mailing list address.

> I still think there should be a list of functions (a hook) that the
> user can set up to return additional subscribed addresses.  I
> maintain a list outside of Gnus for the purpose of generating
> procmail filtering rules.  Getting to-address and to-list addresses
> from group parameters is just a special case of this.

Also agreed.

> But it sounds like we all have similar ideas.  My elisp is very
> weak, so I would not mind if your or anybody else took the first
> stab at implementation.  :-)

Ok, I'll try.  Someone else may get something done first though :)

ttyl,

-- 
Josh Huber

Re: Generating Mail-Followup-To: headers

[Matt Armstrong]

Josh Huber <huber@alum.wpi.edu> writes:

>> But it sounds like we all have similar ideas.  My elisp is very
>> weak, so I would not mind if your or anybody else took the first
>> stab at implementation.  :-)
> 
> Ok, I'll try.  Someone else may get something done first though :)

Let's agree that if you, Paul or myself ever implements something
useful on this front that we notify the list to avoid duplicate
efforts.  :-)


-- 
matt

Re: Generating Mail-Followup-To: headers

[Paul Jarc]

Josh Huber <huber@alum.wpi.edu> wrote:
> I was trying to think of a way to not have to specify duplicate
> address to the ones I've already listed in the group configuration.

Is there anything wrong with the pseudocode I posted earlier?  That
could be used to gather to-list and to-addresses automatically when
sending a message.  (Or not, if one prefers.)

> (let message-subscribed-addresses
>      (append message-subscribed-addresses
>              (mapcar '(lambda (group) (gnus-fetch-group-address
>                                         group))
>                      (gnus-group-find-groups
>                                 gnus-mft-use-group-address))))

So we would use the to-list and to-address parameters from only some
groups, instead of all?  I don't see the use for that.  Why would we
want to exclude any?


paul

Re: Generating Mail-Followup-To: headers

[Kai Großjohann]

Josh Huber <huber@alum.wpi.edu> writes:

> How about
> 
> (setq gnus-mft-use-group-address
>       "^mail.lists")
> 
> In addition to specifying the specific address?

If you want to specify a parameter for some groups, please use the
existing group parameters mechanism.  There is the variable
gnus-parameters which allows people to specify such a parameter by
regexp, so there is no functionality lost.

kai
-- 
GNU/Linux provides a nice `poweroff' command, but where is `poweron'?