"Mitch \(WebCob\)" <[EMAIL PROTECTED]> writes:
> I object to the word stupid, particularly because I think you are missing
> something - there are valid reasons to process messages with no sender - but
> there ARE some that don't need to be processed... I think I see what you are
> saying...
No, you're giving him too much credit. He was incorrectly thinking that
every message that is piped into TMDA will cause a challenge to be sent.
This just isn't true, and before he calls people "stupid", he should
investigate what TMDA _really_ does.
For Roland and anyone else who doesn't know this: TMDA will _decide_
whether a challenge needs to be sent. And only if it's deemed
appropriate to send the challenge, it will do so. This decision is made
via TMDA's own heuristics as well as rules that each user can set up.
One of the rules that we can use is this one:
from <> drop
That means to drop (i.e., do not challenge, and in fact, do not
even deliver) messages that have an empty SENDER field.
We can also do things like this:
from <> accept # accept the message without a challenge
... or this:
from <> deliver=~/.garbage # store in a local file without
# a challenge
... and there are many other possibilities.
> Maybe I'm doing something DUMB here... maybe I'm running tmda when I don't
> need to in this case - I think I see what you are saying, but if I change it
> to not run for enpty SENDER, then a spammer sending mail from <> won't be
> processed - right?
> Neither would a bounce (generated by TMDA to a non-existant remote user)
>
> Here is the code at present:
> LOCKTMDA=$HOME/.tmda.lock
> flock $LOCKTMDA {
> SH_SENDER=escape($SENDER)
> cc "| env SENDER='$SENDER' /usr/local/tmda/bin/tmda-filter"
> if ($EXITCODE != "0")
> {
> EXITCODE=0
> exit
> }
> }
> #continue processing if TMDA approves message
>
> Currently, if EXITCODE !=0, then tdma-filter has done something with the
> message... I don't need to deliver, so I set my EXITCODE and exit
> If it IS 0, then I should continue to deliver it.
>
> Are you proposing I bypass TDMA when the SENDER is empty?
You could do that if you want to save machine cycles. Or you
could use the "from <> drop" rule from within TMDA to have the
same effect. It's up to you. In either case, no challenge will
be sent out.
> Would that allow bounces through?
>
> Would it allow UNWANTED bounces through?
>
> Currently TMDA eats bounces generated by it's confirmation messages, but I
> wonder if it won't also eat bounces that the user may want to see... I might
> have to try to force that to see...
>
> Thanks
>
> m/
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] Behalf Of Roland
>> Sent: Thursday, January 15, 2004 2:12 AM
>> To: [EMAIL PROTECTED]
>> Subject: Re: [courier-users] Re: Does courier / maildrop unset SENDER if
>> it's empty?
>>
>>
>> --On Mittwoch, 14. Januar 2004 10:08 -0500 Courier User
>> <[EMAIL PROTECTED]>
>> wrote:
>>
>> >> But the point is still there: TDMA is supposed to return challenges
>> >> to unknown senders which is just not possible with bounces.
>> >> And tdma especially trolls for bounces with exactly those challenges.
>> >>
>> >> The line in .mailfilter should be something like:
>> >>
>> >> cc "| test \"$SENDER\" && tdma-filter"
>> >
>> > TMDA functions properly if the SENDER variable is "" (empty string)
>> > as opposed to being completely unset. The "cc" command above works
>> > fine.
>>
>> What do you expect to achieve by sending a challenge for a received
>> bounce ?
>>
>> Doing such stupid things actually is typical for those sending back
>> challenges to everything received (preferably on a unfiltered catchall),
>> and they really deserve the 100% false positive rate...
>>
>> Roland
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Perforce Software.
>> Perforce is the Fast Software Configuration Management System offering
>> advanced branching capabilities and atomic changes on 50+ platforms.
>> Free Eval! http://www.perforce.com/perforce/loadprog.html
>> _______________________________________________
>> courier-users mailing list
>> [EMAIL PROTECTED]
>> Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
>>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> courier-users mailing list
> [EMAIL PROTECTED]
> Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
>
--
Courier User
[EMAIL PROTECTED]
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
