Re: Don't filter the users\
Jordi Espasa Clofent a écrit : That is easy. Have your users connect to the submission port, and let everyone else connnect to the smtp port. Then, specify =o content_filter=whatever for the smtp port and not for the submission port. Yes Wietse, I've considered this simple and clean option, but we're a hosting company and the costumers are to lazy to understand and accept an approach like this. If you are taking in all mail on port 25 then you are making mail handling more complicated than it needs to be. I agree... but ¿is there no more alternatives? there are, but using the submission port is the way to go. anyway, you can use the FILTER action in smtpd access checks. for example: smtpd_sender_restrictions = check_client_access pcre:/etc/postfix/filter_trusted.pcre permit_mynetworks permit_sals_authenticated check_client_access pcre:/etc/postfix/filter_default.pcre filter_trusted.pcre: #virus scan, but no spam filtering /./ FILTER filter:[127.0.0.1]:10586 filter_default.pcre: #virus and spam filtering... /./ FILTER filter:[127.0.0.1]:10024 Maybe if I want all mail on port 25, I have to hack the Perl filter code and working on this level, not in Postfix level.
Re: Don't filter the users
You can tell the users that the submission port gets a better level of service than port 25, because they share that port with spammers. As you pointed out in your original email, they would be subject to less filtering, and therefore there would be less delay, less false positives, and so on. I agree. That's the best option and it's a good solution in technical and commercial terms. -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear.
Re: Don't filter the users\
Stan Hoeppner wrote: Why bother? This is an ISP scenario, correct? The 587 command set is standard SMTP right? Just iptables (verb) TCP 25 to TCP 587 for any IP ranges within the ISP's MUA customer range. This is assuming said customers already have to submit auth over TCP 25 to relay mail. Simple solution. Done. Or, have I missed something? Submission on port 587 implies STARTTLS (I think). In that case perhaps stunnel magic is needed too. Mikael
Re: Don't filter the users\
Mikael Bak schrieb: Submission on port 587 implies STARTTLS (I think). Well, only if you configure it that way. (OK, it *really* makes sense to encrypt transfer, if you do authentication...) But: jan...@kohni ~ $ telnet smtp.web.de 587 Trying 217.72.192.157... Connected to smtp.web.de. Escape character is '^]'. 220 smtp06.web.de ESMTP WEB.DE V4.110#314 Wed, 25 Nov 2009 15:58:37 +0100 ehlo smtp.web.de 250-smtp06.web.de Hello XXX 250-SIZE 69920427 250-PIPELINING 250-AUTH PLAIN LOGIN 250-STARTTLS 250 HELP quit 221 smtp06.web.de closing connection Connection closed by foreign host. jan...@kohni ~ $ -- MfG Jan signature.asc Description: This is a digitally signed message part.
Re: Don't filter the users\
Jordi Espasa Clofent: Hi all, I've a Postfix working with Perl-based filter. All works fine, but I don't want filter the legitimate users (who are authenticated using SASL) when they want to do massive mailing using their e-mail client (ThunderBird, Outlook... and so on). That is easy. Have your users connect to the submission port, and let everyone else connnect to the smtp port. Then, specify =o content_filter=whatever for the smtp port and not for the submission port. If you are taking in all mail on port 25 then you are making mail handling more complicated than it needs to be. Wietse
Re: Don't filter the users\
That is easy. Have your users connect to the submission port, and let everyone else connnect to the smtp port. Then, specify =o content_filter=whatever for the smtp port and not for the submission port. Yes Wietse, I've considered this simple and clean option, but we're a hosting company and the costumers are to lazy to understand and accept an approach like this. If you are taking in all mail on port 25 then you are making mail handling more complicated than it needs to be. I agree... but ¿is there no more alternatives? Maybe if I want all mail on port 25, I have to hack the Perl filter code and working on this level, not in Postfix level. -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear.
Re: Don't filter the users\
On Nov 24, 2009, at 12:39 PM, Jordi Espasa Clofent jespa...@minibofh.org wrote: That is easy. Have your users connect to the submission port, and let everyone else connnect to the smtp port. Then, specify =o content_filter=whatever for the smtp port and not for the submission port. Yes Wietse, I've considered this simple and clean option, but we're a hosting company and the costumers are to lazy to understand and accept an approach like this. If you are taking in all mail on port 25 then you are making mail handling more complicated than it needs to be. I agree... but ¿is there no more alternatives? An untested idea: try not specfying a content_filter anywhere in main.cf or master.cf. Then place a policy service (like postfwd) that checks whether clients connecting on port 25 authenticate (determined by whether Postfix passes a non-empty sasl_* attribute to the policy service). Make the policy service respond with a suitable FILTER action only for clients that do NOT authenticate.
Re: Don't filter the users\
On 24-Nov-2009, at 10:39, Jordi Espasa Clofent wrote: That is easy. Have your users connect to the submission port Yes Wietse, I've considered this simple and clean option, but we're a hosting company and the costumers are to lazy to understand and accept an approach like this. Force them by making 587 the ONLY way to send mail. Tell them it's for security reasons and make sure you enforce it. -- What if there were no hypothetical questions?
Re: Don't filter the users\
On Nov 24, 2009, at 3:07 PM, LuKreme krem...@kreme.com wrote: On 24-Nov-2009, at 10:39, Jordi Espasa Clofent wrote: That is easy. Have your users connect to the submission port Yes Wietse, I've considered this simple and clean option, but we're a hosting company and the costumers are to lazy to understand and accept an approach like this. Force them by making 587 the ONLY way to send mail. Tell them it's for security reasons and make sure you enforce it. That's all fine and well for small sites, but hardly a solution for larger environments where such draconian measures are impractical. A more reasonable solution is for the OP to push users toward submission via 587, and in the (very long) meantime, find other ways to bifurcate SASL vs. non-SASL traffic on port 25.
Re: Don't filter the users\
On Tue, Nov 24, 2009 at 1:25 PM, Sahil Tandon sa...@tandon.net wrote: On Nov 24, 2009, at 3:07 PM, LuKreme krem...@kreme.com wrote: On 24-Nov-2009, at 10:39, Jordi Espasa Clofent wrote: That is easy. Have your users connect to the submission port Yes Wietse, I've considered this simple and clean option, but we're a hosting company and the costumers are to lazy to understand and accept an approach like this. Force them by making 587 the ONLY way to send mail. Tell them it's for security reasons and make sure you enforce it. That's all fine and well for small sites, but hardly a solution for larger environments where such draconian measures are impractical. A more reasonable solution is for the OP to push users toward submission via 587, and in the (very long) meantime, find other ways to bifurcate SASL vs. non-SASL traffic on port 25. Small sites like Google, where they force their customers to use specific ports for e-mail submission? http://mail.google.com/support/bin/answer.py?answer=77689 What's good for the Google is good for the Gander, eh? You could even copy Google's help docs when writing your own. -Mike
Re: Don't filter the users
Jordi Espasa Clofent: That is easy. Have your users connect to the submission port, and let everyone else connnect to the smtp port. Then, specify =o content_filter=whatever for the smtp port and not for the submission port. Yes Wietse, I've considered this simple and clean option, but we're a hosting company and the costumers are to lazy to understand and accept an approach like this. You can tell the users that the submission port gets a better level of service than port 25, because they share that port with spammers. As you pointed out in your original email, they would be subject to less filtering, and therefore there would be less delay, less false positives, and so on. Wietse
Re: Don't filter the users\
On Nov 24, 2009, at 3:48 PM, Michael Saldivar mike.saldi...@advocatecreditrepair.com wrote: On Tue, Nov 24, 2009 at 1:25 PM, Sahil Tandon sa...@tandon.net wrote: On Nov 24, 2009, at 3:07 PM, LuKreme krem...@kreme.com wrote: On 24-Nov-2009, at 10:39, Jordi Espasa Clofent wrote: That is easy. Have your users connect to the submission port Yes Wietse, I've considered this simple and clean option, but we're a hosting company and the costumers are to lazy to understand and accept an approach like this. Force them by making 587 the ONLY way to send mail. Tell them it's for security reasons and make sure you enforce it. That's all fine and well for small sites, but hardly a solution for larger environments where such draconian measures are impractical. A more reasonable solution is for the OP to push users toward submission via 587, and in the (very long) meantime, find other ways to bifurcate SASL vs. non-SASL traffic on port 25. Small sites like Google, where they force their customers to use specific ports for e-mail submission? Small sites like Google? Sarcasm is adorable but rarely helps make your point. http://mail.google.com/support/bin/answer.py?answer=77689 What's good for the Google is good for the Gander, eh? If only it were so. Think company that decides caters to thousands (insert a larger number of your liking here to avoid another sarcastic response that misses the point) of users on port 25 and can't one day just STOP accepting all mail on that port, no matter how useful and nicely worded the REJECT is that directs them to 587. The OP has already stated he understands the merits of using the submission port but needs another solution given his REAL WORLD constraints. Let me be clear: I'm totally on board with using a separate submission port for trusted users, but that is not always immediately feasible and the OP asked for alternatives on a technical mailing list. Hopefully he can convince users to eventually migrate, but the point is that he needs an interim solution to avoid filtering authenticated clients on port 25.
Re: Don't filter the users\
On 11/24/2009 3:06 PM, Sahil Tandon wrote: If only it were so. Think company that decides caters to thousands (insert a larger number of your liking here to avoid another sarcastic response that misses the point) of users on port 25 and can't one day just STOP accepting all mail on that port, no matter how useful and nicely worded the REJECT is that directs them to 587. The OP has already stated he understands the merits of using the submission port but needs another solution given his REAL WORLD constraints. Let me be clear: I'm totally on board with using a separate submission port for trusted users, but that is not always immediately feasible and the OP asked for alternatives on a technical mailing list. Hopefully he can convince users to eventually migrate, but the point is that he needs an interim solution to avoid filtering authenticated clients on port 25. OP can probably exploit the fact that end-user mail clients send to an A record, MTAs send to an MX. Set smtp.example.com's A record to some IP that only accepts authenticated mail, and point the MX to a different IP. ... and then plan a 6 month migration to using port 587. -- Noel Jones
Re: Don't filter the users\
Noel Jones put forth on 11/24/2009 3:37 PM: OP can probably exploit the fact that end-user mail clients send to an A record, MTAs send to an MX. Set smtp.example.com's A record to some IP that only accepts authenticated mail, and point the MX to a different IP. ... and then plan a 6 month migration to using port 587. Why bother? This is an ISP scenario, correct? The 587 command set is standard SMTP right? Just iptables (verb) TCP 25 to TCP 587 for any IP ranges within the ISP's MUA customer range. This is assuming said customers already have to submit auth over TCP 25 to relay mail. Simple solution. Done. Or, have I missed something? -- Stan
Re: Don't filter the users\
On Tue, 24 Nov 2009 13:48:02 -0700 Michael Saldivar mike.saldi...@advocatecreditrepair.com replied: On Tue, Nov 24, 2009 at 1:25 PM, Sahil Tandon sa...@tandon.net wrote: On Nov 24, 2009, at 3:07 PM, LuKreme krem...@kreme.com wrote: On 24-Nov-2009, at 10:39, Jordi Espasa Clofent wrote: That is easy. Have your users connect to the submission port Yes Wietse, I've considered this simple and clean option, but we're a hosting company and the costumers are to lazy to understand and accept an approach like this. Force them by making 587 the ONLY way to send mail. Tell them it's for security reasons and make sure you enforce it. That's all fine and well for small sites, but hardly a solution for larger environments where such draconian measures are impractical. A more reasonable solution is for the OP to push users toward submission via 587, and in the (very long) meantime, find other ways to bifurcate SASL vs. non-SASL traffic on port 25. Small sites like Google, where they force their customers to use specific ports for e-mail submission? http://mail.google.com/support/bin/answer.py?answer=77689 What's good for the Google is good for the Gander, eh? You could even copy Google's help docs when writing your own. -Mike Google's documentation, as usual, is in error. You can connect to SMTP via port 25; however, you will need to use TLS if sending from your own account. -- Jerry postfix.u...@yahoo.com TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html For some reason, this fortune reminds everyone of Marvin Zelkowitz.
Re: Don't filter the users\
On Tue, 24 Nov 2009 16:06:44 -0500 Sahil Tandon sa...@tandon.net replied: On Nov 24, 2009, at 3:48 PM, Michael Saldivar mike.saldi...@advocatecreditrepair.com wrote: On Tue, Nov 24, 2009 at 1:25 PM, Sahil Tandon sa...@tandon.net wrote: On Nov 24, 2009, at 3:07 PM, LuKreme krem...@kreme.com wrote: On 24-Nov-2009, at 10:39, Jordi Espasa Clofent wrote: That is easy. Have your users connect to the submission port Yes Wietse, I've considered this simple and clean option, but we're a hosting company and the costumers are to lazy to understand and accept an approach like this. Force them by making 587 the ONLY way to send mail. Tell them it's for security reasons and make sure you enforce it. That's all fine and well for small sites, but hardly a solution for larger environments where such draconian measures are impractical. A more reasonable solution is for the OP to push users toward submission via 587, and in the (very long) meantime, find other ways to bifurcate SASL vs. non-SASL traffic on port 25. Small sites like Google, where they force their customers to use specific ports for e-mail submission? Small sites like Google? Sarcasm is adorable but rarely helps make your point. http://mail.google.com/support/bin/answer.py?answer=77689 What's good for the Google is good for the Gander, eh? If only it were so. Think company that decides caters to thousands (insert a larger number of your liking here to avoid another sarcastic response that misses the point) of users on port 25 and can't one day just STOP accepting all mail on that port, no matter how useful and nicely worded the REJECT is that directs them to 587. Excuse me, but does the name 'Comcast' ring a familiar note. They only rescinded that decision when their support lines were over taxed by calls. Personally, IMHO, they should have weathered it out. Their customers would have smartened up eventually. In the long run, forcing users to employ SMTP authentication, etc. does decrease the amount of SPAM. The OP has already stated he understands the merits of using the submission port but needs another solution given his REAL WORLD constraints. The real problem is that he is enabling a user base to control his actions. He has to determine who is in charge. If he is, then he makes the final decisions. If not, then 'quite bitchin'. Let me be clear: I'm totally on board with using a separate submission port for trusted users, but that is not always immediately feasible and the OP asked for alternatives on a technical mailing list. Hopefully he can convince users to eventually migrate, but the point is that he needs an interim solution to avoid filtering authenticated clients on port 25. -- Jerry postfix.u...@yahoo.com TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html Klingon phaser attack from front! 100% Damage to life support
Re: Don't filter the users\
On Tue, 24 Nov 2009, Jerry wrote: Sahil Tandon sa...@tandon.net replied: If only it were so. Think company that decides caters to thousands (insert a larger number of your liking here to avoid another sarcastic response that misses the point) of users on port 25 and can't one day just STOP accepting all mail on that port, no matter how useful and nicely worded the REJECT is that directs them to 587. Excuse me, but does the name 'Comcast' ring a familiar note. They only rescinded that decision when their support lines were over taxed by calls. Personally, IMHO, they should have weathered it out. Their customers would have smartened up eventually. In the long run, forcing users to employ SMTP authentication, etc. does decrease the amount of SPAM. Thanks for the interesting anecdote, but it is rather non-sequitur and probably more appropriate for spam-l than postfix-users. I share your anti-spam zeal, but that is not under discussion here. The OP has already stated he understands the merits of using the submission port but needs another solution given his REAL WORLD constraints. The real problem is that he is enabling a user base to control his actions. He has to determine who is in charge. If he is, then he makes the final decisions. If not, then 'quite bitchin'. Wrong. The real problem is that you are making baseless assumptions about the OP's operating environment and customer base. The who is in charge mentality makes for fun macho narrative, but often does not apply when paying customers and bureaucratic management types run the show. In those scenarios, the people running the mail servers take orders and implement decisions from higher up. No one is bitching in this thread, so your note appears to have been mis-directed. The point remains that the OP is in an un-ideal situation and is seeking a TECHNICAL workaround given a set of unfortunate constraints. It is perfectly reasonable to inform him about the virtues of 587 submission (this was done early in the thread), but repeatedly swinging the same cluebat in spite of context does not seem useful. Speaking of which, this thread has veered way off topic, so this is my last post on the subject. :-) -- Sahil Tandon sa...@tandon.net
