Hi! Thanks for your detailed answer. In my configuration all users from the domain use one configuration. All mails pass the same filter. So only one person (secretary etc) could maintain the filter and look for unconfirmed urgent mails.
The mail with "postmaster" was created while testing with CONFIRM_ADDRESS parameter in the config file. Even with or without the mails will be not confirmed. For what situation I need this option CONRIRM_ADDRESS then? The documentation for this option is not realy telling me this. For testing: All TMDA needs to confirm a mail is, that a mail returns with the full code "[EMAIL PROTECTED]"? Nothing else is set in headers or somewhere? So if I send manually a mail to this address this should also be confirmed? I have tested this, but with the same result. so long, Andreas -----Urspr�ngliche Nachricht----- Von: Stephen Warren [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 21. Oktober 2004 06:32 An: Tom Wolfe Cc: [EMAIL PROTECTED] Betreff: Re: pending messages not released after confirmation - confirmationnotaccepted Tom Wolfe wrote: > Hi Tony & Stephen: > > Tony, isn't it be more like this: > > (1) Your MTA or filter program (procmail/maildrop) sends a new incoming > message from an unknown user. This message is given to tmda-filter for > processing. Yup, it starts out this way. > (2) tmda looks up the tmda settings for the recipient user (usually in > ~/.tmda/). [by this do you mean the ~/.tmda/config file? And what should > these settings be? - see my question to Stephen below] Yes, that's the main per-user config file. Note /etc/tmdarc is read befoer this. > (3) tmda checks the recipient address > a) if it's tagged as acceptable it passes > b) if it's tagged as a returned confirmation message, the sender's > email is added to the confirmed list > c) otherwise continue to step (4) > > (4) tmda checks the sender's email address: > a) if it's on the blacklist it's discarded > b) if it's on the confirmed list or whitelist it's released > c) otherwise, send the sender a confirmation notice The exact procesing of the above steps depends on the contents of the user's incoming filter. At a high level, this is what happens: (x) All rules in the incoming filter are followed as written in order, until a rule matches, at which point processing terminates for this message. (y) The address the email was sent to is checked to see if it's a valid confirmation address etc. (I believe this happens after step (x), not before it...). If it's a valid dated/keyword/sender tagged address, the email is delivered according to the configured delivery mechanism. If it's a valid confirmation address, the original email is looked up in the pending queue, and delivered to the recipient. (z) If no incoming filter rule matched the email, the default action is taken. Often, this default action is to send a confirmation request, and save the original message in the pending queue. > So what seems to be going wrong with my installation of tmda is that step > (3)b) is not being performed. Tmda is receiving the returned confirmation > messages but is not adding the sender to the confirmed list. Each TMDA user has a certain "crypt key". This is used to perform some mathematical processing (HMAC - Hashed Message Authentication Code) on outgoing tagged addresses. Only the original sending user ID of a message has access to this key, so only they can generate valid HMAC codes for their email address, and only they can verify whether received emails were sent to a valid e.g. confirmation address. So, if the user "[EMAIL PROTECTED]" receives an email, the challenge they send out will be from "[EMAIL PROTECTED]", where XXXXX is the HMAC code. This means that when the original sender receives the challenge and replies, the challenge's response will be sent back to the same recipient user, and processed with the same TMDA configuration and hence the same HMAC code - this is because [EMAIL PROTECTED] is just an extension address of [EMAIL PROTECTED] > Stephen Warren - you mentioned something about the users being an issue. I > have a single domain that I currently want filtered - sawback.com - that is > a virtual domain handled by dyyme.pair.com (a pair networks server). Do I > need to make configuration settings to handle different addresses on that > domain, e.g. [EMAIL PROTECTED], [EMAIL PROTECTED], etc.? If so, how do I do > this (is there any reference material, and if so where?) (Actually, in the response I wrote below, I'm more explaining my original reply... The simple answer to your question is to give each of info@ and gladys@ their own home and TMDA directory, don't over-ride email addresses in the TMDA config files, and things will probably just work the way you want...) If all mail to any address @sawback.com is routed to a single TMDA confuration, then it should all work fine - no matter what address is used to generate your challenges, the response will be processed by the same TMDA configuration and hence will validate OK. However, if you have multiple TMDA configurations (e.g. one for info@ and one for gladys@, then you need to make sure TMDA generates confirmation addresses that will get processed by the same TMDA configuration that generated them, so HMAC verification will work because the keys are the same. So, if I remember correctly, you were sending an initial mail to: [EMAIL PROTECTED] In a default TMDA configuration, the challenge would be generated with a reply to address of something like: [EMAIL PROTECTED] where XXXXX is a HMAC code. However, for some reason, your challenge was sent with a reply-to address of: [EMAIL PROTECTED] I'm guessing that [EMAIL PROTECTED] and [EMAIL PROTECTED] have different TMDA configurations, and hence have different crypt keys, and hence this is why the confirmation responses aren't accepted, because they don't validate. However, if [EMAIL PROTECTED] and [EMAIL PROTECTED] both used the same TMDA configuration and crypt keys, this would be fine (this could easily be achieved using a virtual users scheme) For some reason, it looks like [EMAIL PROTECTED]'s TMDA configuration is over-riding and hard-coding the user's own address with something such that email to that over-riding address doesn't get processed using the same TMDA configuration and crypt key. Hope this clears it all up - I know it's a bit long winded! -- Stephen Warren, Software Engineer, NVIDIA, Fort Collins, CO [EMAIL PROTECTED] http://www.wwwdotorg.org/pgp.html _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
