Re: Question about retaining mail authenticated user
I know there's a possibility of using smtpd sasl authenticated header but I don't really trust in that way... Oh, because the client might provide a fake one? On 20.05.21 22:41, ego...@ramattack.net wrote: Yep. We use dedicated ip addresses for each customer (just for providing a good service, of course not for allowing outgoing spam) and we do it with FILTER and the corresponding smtp client instance. So, we were using SASL auth domain for routing each customer mail properly. A standard header, could be faked by a MUA or script... so for this purpose, a standard known header, is not the best idea I assume... Thanks a lot for your time Wietse. I’ll check the possibility of using a custom header later removed. smtpd_sasl_authenticated_header should put the authenticated user to Received: header which at least spamassassin know when to trust and when not to. What is it you want to do when delivering mail from different users? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. LSD will make your ECS screen display 16.7 million colors
Re: Question about retaining mail authenticated user
On 21.05.21 14:43, ego...@ramattack.net wrote: I don't need Spamassassin to trust wether a mail comes from authenticated source or not. I provided an example of how to find out the authenticated user by using existing solution, e.g. smtpd_sasl_auth_enable=yes. I needed to know which one, is the authenticated user has sent an email in the smtpd instance returning from Amavis for being able to give that mail an action with a poilcy. I know this - you have already explained what you want to know. But you haven't answered my question, which is: what exactly you need it for? Maybe we'd have better tip for you. By the way, I would say that the fact of entering a very known header in an email as you know, is absolutely simple so I think it's not perhaps the best idea to trust only in that header. But I think Wietse put me in the correct way and now I think I have a good idea :) I wonder that you are willing to accept random header that can be faked by sending client, instead of using header that can be trusted. ...are you sure you will only match the first header in the mail? maybe you could use STRIP, IGNORE or REPLACE instead of PREPEND, or use both STRIP/IGNORE in header_checks and PREPEND in policy filter, which makes sure the header you use will be deleted from input stream. but still explaining what you want could lead to better solution for your problem. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Boost your system's speed by 500% - DEL C:\WINDOWS\*.*
Re: Question about retaining mail authenticated user
Hi Matus, I don't need Spamassassin to trust wether a mail comes from authenticated source or not. I needed to know which one, is the authenticated user has sent an email in the smtpd instance returning from Amavis for being able to give that mail an action with a poilcy. By the way, I would say that the fact of entering a very known header in an email as you know, is absolutely simple so I think it's not perhaps the best idea to trust only in that header. But I think Wietse put me in the correct way and now I think I have a good idea :) Thanks a lot! Best regards, El 2021-05-21 14:19, Matus UHLAR - fantomas escribió: > smtpd_sasl_authenticated_header should put the authenticated user to > Received: header which at least spamassassin know when to trust and when not > to. > > What is it you want to do when delivering mail from different users?
Question about service daemon man pages
Hello, I have a question about the man pages for the service daemons that are executed via master(8). A section that is shared in all of the service daemon man pages is "CONFIGURATION PARAMETERS". In bounce(8) there are parameters under this section that relate to delivery status notifications. For instance: delay_notice_recipient. This made me think that bounce(8) is solely responsible for DSN's. When I check cleanup(8) under "CONFIGURATION PARAMETERS" I see: delay_warning_time which also relates to DSN's. I understand that both of these parameters are configured in one place: main.cf but my questions are: 1. When a parameter is listed under "CONFIGURATION PARAMETERS" does that mean it _only_ applies to its' service daemon ? This would mean that: delay_notice_recipient is "owned" via bounce(8) and: delay_warning_time is "owned" via cleanup(8) 2. If question 1 is correct why does DSN functionality have it's implementation divided between 2 daemons ? 3. Do other service daemons subdivide responsibility for a function ? For clarity - questions 2 and 3 aren't a critique of the design; it's more to help my brain understand things (one functionality provided by one service daemon is currently more understandable to my confused brain!). Thanks, - J
Re: Question about service daemon man pages
J Doe: > Hello, > > I have a question about the man pages for the service daemons that are > executed via master(8). > > A section that is shared in all of the service daemon man pages is > "CONFIGURATION PARAMETERS". In bounce(8) there are parameters under > this section that relate to delivery status notifications. For > instance: delay_notice_recipient. This made me think that bounce(8) is > solely responsible for DSN's. No it's not. The bounce daemon *uses* the time to warn in notifications (your message could not be delivered for more than $delay_warning_time_hours hours). > When I check cleanup(8) under "CONFIGURATION PARAMETERS" I see: > delay_warning_time which also relates to DSN's. The cleanup daenon *stores* the time to warn in queue files. Additionally, the queue manager *enforces* the time to warn by requesting that a warning notification is sent. Wietse
Re: Question about service daemon man pages
On 2021-05-21 7:34 p.m., Wietse Venema wrote: J Doe: Hello, I have a question about the man pages for the service daemons that are executed via master(8). A section that is shared in all of the service daemon man pages is "CONFIGURATION PARAMETERS". In bounce(8) there are parameters under this section that relate to delivery status notifications. For instance: delay_notice_recipient. This made me think that bounce(8) is solely responsible for DSN's. No it's not. The bounce daemon *uses* the time to warn in notifications (your message could not be delivered for more than $delay_warning_time_hours hours). When I check cleanup(8) under "CONFIGURATION PARAMETERS" I see: delay_warning_time which also relates to DSN's. The cleanup daenon *stores* the time to warn in queue files. Additionally, the queue manager *enforces* the time to warn by requesting that a warning notification is sent. Wietse Hi Wietse, Thanks for your reply. Ok, would the more accurate takeaway be that more than one daemon can consult/consume a parameter in main.cf and the fact that a parameter is listed in a service daemon man page does _not_ mean that that one daemon "owns" the parameter ? Thanks again, - J
