Andreas, The CONFIRM_ADDRESS parameter is most useful in situations where an email arrives in your mailbox via some mail forwarder that does not allow for the use of extension addresses, or whose extension address delimiter does not match the delimiter used by your TMDA enabled mail server. Without the CONFIRM_ADDRESS parameter confirmation addresses are generated using the address the mail was sent to, so if someone sent me an email at [EMAIL PROTECTED] the generated confirmation address would be [EMAIL PROTECTED] which would not work. Whereas if I define CONFIRM_ADDRESS = "[EMAIL PROTECTED]" then even though the original email was sent through bigfoot.com the confirmation address would be generated from bardicgrove.org e.g. [EMAIL PROTECTED]
HTH Dave Grimberg > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Andreas Plachy > Sent: Wednesday, October 20, 2004 11:12 PM > To: [EMAIL PROTECTED] > Subject: AW: pending messages not released after confirmation > -confirmationnotaccepted > > 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 > _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
