[EMAIL PROTECTED] (Barry A. Warsaw) writes:
> It probably would be best to add a method get_author() which
> returned a list of (From_, From:, Sender:) for comparison
Alright, I've added a get_author() method to Mailman.Message which
returns a list containing the From:, unixfrom, Reply-To:, and
> "SJT" == Stephen J Turnbull <[EMAIL PROTECTED]> writes:
> "BAW" == Barry A Warsaw <[EMAIL PROTECTED]> writes:
BAW> Mailman shall rule THE WORLD!
SJT> Take a number, man. (See .sig.)
| What are those straight lines for? "XEmacs rules."
Hard to argue with that, seein
> "BAW" == Barry A Warsaw <[EMAIL PROTECTED]> writes:
BAW>
BAW> Mailman shall rule THE WORLD!
BAW>
Take a number, man. (See .sig.)
--
University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (29
> "JRM" == Jason R Mastaler
> <[EMAIL PROTECTED]> writes:
JRM> Well, at least we are "fixing" this here.
Mailman shall rule THE WORLD!
>> If so, the order ought to go (I think)
>> 1. From: 2. From_ 3. Reply-To: 4. Sender:
JRM> Alrighty.
Cool, thanks.
-Barry
__
[EMAIL PROTECTED] (Barry A. Warsaw) writes:
> True. I wonder if Reply-To: ought to be added to the mix?
It wouldn't hurt. FWIW, TMDA checks Reply-To: in addition to From:
and the envelope sender.
> Note that all are easily spoofable, so that argument doesn't bother
> me much.
Exactly. Which
> "JRM" == Jason R Mastaler
> <[EMAIL PROTECTED]> writes:
>> When USE_ENVELOPE_SENDER was the default, it was next to
>> useless because it rarely matched the sender's membership
>> address. So that's why it was disabled.
JRM> Understandable. By the same token, there a
[EMAIL PROTECTED] (Barry A. Warsaw) writes:
> When USE_ENVELOPE_SENDER was the default, it was next to useless
> because it rarely matched the sender's membership address. So
> that's why it was disabled.
Understandable. By the same token, there are cases where From doesn't
match, but the enve
> "JRM" == Jason R Mastaler
> <[EMAIL PROTECTED]> writes:
JRM> For members-only lists like this one, USE_ENVELOPE_SENDER
JRM> currently allows the admin to determine membership by
JRM> checking either the From: header, OR the envelope sender
JRM> address.
JRM> I thin
For members-only lists like this one, USE_ENVELOPE_SENDER currently
allows the admin to determine membership by checking either the From:
header, OR the envelope sender address.
I think a more flexible alternative would be to first check the
envelope sender, and then the From: header for a match.
For members-only lists like this one, USE_ENVELOPE_SENDER currently
allows the admin to determine membership by checking either the From:
header, OR the envelope sender address.
I think a more flexible alternative would be to first check the
envelope sender, and then the From: header for a match.
10 matches
Mail list logo
