Hi Viktor, > > Yes, but this doesn't work if you need to adjust outgoing IP based on > > the sasl user (published solutions insist on using FILTER :-( [1]) > > Then perhaps we should provide a way of doing the same thing by > SASL login. Both the envelope address and the SASL login name are > really features of the sender. The original purpose of the feature > (in the form of a sender dependent relay host) was to allow users > to relay mail through the right email provider that hosts the > mailbox for the sender address, and might have DKIM, SPF, ... > > I don't think that we're going out of our way to facilitate snow-show > bulk-email (possibly legitimate, and just dealing with real obstacles, > or at times trying to flying under the radar with less legitimate > content). > > So there's a limit to how much effort in that direction is likely > in the mainstream Postfix distribution. > > What are the legitimate use-cases for transport for SASL id?
Ok, before explaining the use case, I would like to recall why this thread was started: to have the possibility to selectively discard recipients in a multi-recipient message. However, after sharing with you both the case, and reviewing the issue, we are starting to consider the problem not as such, but as a limitation which is somehow caused/activated by the way the email agent is sending content and, more over, and possibly, more important, sending content to accounts that will cause us problems (RBLs), which is something we cannot accept (obviously). Having said that, the use case follows. What we have now is a good balance where users are grouped into different outgoing IP, so we can reduce the impact of a compromised accounts ([1]), and at the same time we don't have to deal with different combinations of sender+sasl-user ([1]) so we do the routing using the SASL identifer, Even though mail sending is controlled by quotas and we also implement sender login mismatch (sasl identifier must much sender account), there's a set of "users" that have exceptions (for the complexity and commercial reasons), but not spammers (unless they got compromised, of course). Given all this, the big likelihood this can be used for bad things(tm) and the fact that, even implemented, we will not be able to take advantage of it in the short term, the reasonable conclusion for us is that we have to work out the problem by other means (which may include users' reeducation :-) > > > Postfix is not a one-stop-shopping solution for a snow-shoe spam > > > MTA. Removing pesky recipients like me who'll report the sender > > > to RBL maintainers and abuse departments needs to happen in the > > > upstream lists, not in the MTA. Turn-away customers with harvested > > > lists, or you'll find your outbound IPs on RBLs. > > > > :-) Hehe...I'd really like to (turn away those customers), but daily > > life reality is far from there... > > > > Anyway, certainly, that "FILTER" for transport selection we are doing is > > very disruptive (according to postfix way of doing things). I'll take me > > time to review this, > > > > [1] http://comments.gmane.org/gmane.mail.postfix.user/250046 > > Well, that works provided you don't also try to do any interesting > per-recipient routing (e.g. routing to discard(8)). > > There isn't at present a "DEFAULT ..." access(5) directive that > instead of "FILTER", which preempts routing, sets the default > transport. This would have to write a new record into the queue-file > that the queue-manager would then convey to trivial-rewrite(8) in > the "resolve" protocol request (which would need to change), so > that trivial-rewrite would return the per-message default transport. Ok, > Can't estimate the likelihood of this becoming an official feature. Looks reasonable to me, Thanks for all clarifications and comments Viktor, Best Regards, [1] The amount of users that care about its box, do not use wifi connections that shouldn't be used, do not install unrecommended software (thus compromising his/her equipment) and do not configure fancy combinations of my-yahoo-account+sasl_user_of_my_isp is function that nearly approximates to 0 -- Francis Brosnan Blázquez <fran...@aspl.es> ASPL 91 134 14 22 - 91 134 14 45 - 91 116 07 57 AVISO LEGAL En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal, le informamos de que sus datos de carácter personal, recogidos de fuentes accesibles al público o datos que usted nos ha facilitado previamente, proceden de bases de datos propiedad de Advanced Software Production Line, S.L. (ASPL). ASPL garantiza que los datos serán tratados con la finalidad de mantener las oportunas relaciones comerciales o promocionales con usted o la entidad que usted representa. No obstante, usted puede ejercitar sus derechos de acceso, rectificación, cancelación y oposición dispuestos en la mencionada Ley Orgánica, notificándolo por escrito a ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de Henares (Madrid).
