Re: preventing authenticated smtp users from triggering PBL
On 2010/12/17 11:47 AM, Ted Mittelstaedt wrote: And what prevents a spammer from forging this into a header and bypassing SA? Just askin. On 12/17/2010 8:51 AM, Jason Bertoch wrote: Without checking, I'd guess that matching an authentication header with an address in trusted_networks would be sufficient. On 17.12.10 09:19, Ted Mittelstaedt wrote: why are you using authenticated SMTP from trusted networks? The whole point of auth smtp is to come from UN-trusted networks. Not exactly. The point of auth smtp is not to accept mail from anyone without authentication, even if ip-based for some hosts. If your authentication server is relaying for spammers, you've got an entirely different problem. No, not really. You as an administrator cannot control what your users do and if your users save their authenticated SMTP passwords into their e-mail clients then later allow their machines to be cracked, then the crackers get the auth password and away they go. I think this depends on order of mail headers. If authenticating server before the received header, it is surely trusted. Otherwise you are right and we don't know, if it wasn't the spammer who started with fake authentication header. The best is, of course, to put the authentication data to the Received: header so we don't have to take care of the header order. -- 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. Silvester Stallone: Father of the RISC concept.
Re: preventing authenticated smtp users from triggering PBL
Hi Aaron, I know in our setup we just give trusted_networks a score of -120, that way it usually doesn't matter if they kick off any PBL's etc on their initial hop. Regards Eddie Hallahan Enterprise Management Consulting www.emcuk.com Enterprise Management Consulting is a company registered in England and Wales with company number 3134554. VAT registration number is 681038440. Aaron Bennett wrote: Hi, I've got an issue where users off-campus who are doing authenticated SMTP/TLS from home networks are having their mail hit by the PBL. I have trusted_networks set to include the incoming relay, but still the PBL hits it as follows: Received: from cmail.clarku.edu (muse.clarku.edu [140.232.1.151]) by mothra.clarku.edu (Postfix) with ESMTP id D4FC2684FEA for re...@clarku.edu; Tue, 7 Dec 2010 00:11:24 -0500 (EST) Received: from SENDERMACHINE (macaddress.hsd1.ma.comcast.net [98.216.185.77]) by cmail.clarku.edu (Postfix) with ESMTP id 82F21901E48 for re...@clarku.edu; Tue, 7 Dec 2010 00:11:24 -0500 (EST) From: USER NAME sen...@clarku.edu Despite that internal_networks and trusted_networks are set to 140.232.0.0/16, the message still triggers the PBL rule. Given that I know that (unless there's a trojaned machine or whatever) I must trust email that comes in over authenticated SMTP/TLS through the 'cmail' host, how can I prevent it from hitting the PBL? Thanks, Aaron --- Aaron Bennett Manager of Systems Administration Clark University ITS
Re: preventing authenticated smtp users from triggering PBL
On 12/17/10 9:57 AM, Ted Mittelstaedt wrote: On 12/17/2010 9:23 AM, Aaron Bennett wrote: -Original Message- From: Ted Mittelstaedt [mailto:t...@ipinc.net] Sent: Friday, December 17, 2010 12:20 PM To: users@spamassassin.apache.org Subject: Re: preventing authenticated smtp users from triggering PBL why are you using authenticated SMTP from trusted networks? The whole point of auth smtp is to come from UN-trusted networks. I think you are misunderstanding. I may be on an unstrusted network, but I want to send email through a host on a trusted network. By authenticating, I can. It was the trusted host which authenticated me, and thus SA needs to take that I was authenticated by a trusted host into consideration before applying the PBL rule to the address the mail initiated on. Right, but a spammer can send a message with the same authenticated flag set in the mail header through the standard SMTP port because they are manufacturing the headers out of thin air. My experience with SA is that if it sees that flag anywhere in the header, it will assume the mail is safe. I have also had the experience with earlier versions of SA that they ignore the flag completely but that was fixed a while ago. Ted I use Mimedefang with some home-brewed patches I've been trying to get David to include for the last 3+ years. I look for the local port # that the connection comes in on, and pass it in to SpamAssassin as a hint from the command via --cf=... And port 587 forces a different rule than 25 does. This can't be forged. -Philip
Re: preventing authenticated smtp users from triggering PBL
Am 17.12.2010 20:50, schrieb Jason Bertoch: On 2010/12/17 2:48 PM, Robert Schetterer wrote: forget trusted_networks use i.e spamass-milter with spamassassin with option -I: skip (ignore) checks if sender is authenticated Though I've not used spamass-milter, will this really work if the authentication server is not local? should not matter , ( normally all auth processes with postfix are based on sasl or dovecot etc ) , so it should only depend on a existing and working authentication process what kind ever i think internal this is checked over the milter code in postfix -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: preventing authenticated smtp users from triggering PBL
On Fri, 17 Dec 2010 10:11:11 -0800 Ted Mittelstaedt t...@ipinc.net wrote: On 12/17/2010 9:28 AM, Jason Bertoch wrote: In the OP's case, his authenticating server is separate from his SA server. In any case, the server indicating authentication (localhost or otherwise) should be a trusted server, else you don't trust the authentication. auth-smtp is only a speedbump to the spammers, it blocks the dumb ones. A sophisticated spammer can hijack a machine and use it's authenticated SMTP connection to it's mailserver to send spam. I never trust the authentication. The main reason for SA checking authentication is to turn-off MX specific tests such as PBL, for that reason you have to be able to trust the authentication. That's not the same as trusting the sender.
Re: preventing authenticated smtp users from triggering PBL
On 12/17/10 11:04 PM, Ted Mittelstaedt wrote: It's shit-for-brains young girl administrative assistants at companies who are our customers who apparently have too much time on their hands. Don't hold back,.. how do you REALLY feel about outlook stationary? -- Michael Scheidell, CTO o: 561-999-5000 d: 561-948-2259 ISN: 1259*1300 *| *SECNAP Network Security Corporation * Certified SNORT Integrator * 2008-9 Hot Company Award Winner, World Executive Alliance * Five-Star Partner Program 2009, VARBusiness * Best in Email Security,2010: Network Products Guide * King of Spam Filters, SC Magazine 2008 __ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.secnap.com/products/spammertrap/ __
Re: preventing authenticated smtp users from triggering PBL
On 2010/12/17 11:28 AM, Aaron Bennett wrote: I've got an issue where users off-campus who are doing authenticated SMTP/TLS from home networks are having their mail hit by the PBL. I have trusted_networks set to include the incoming relay, but still the PBL hits it as follows: Received: from cmail.clarku.edu (muse.clarku.edu [140.232.1.151]) by mothra.clarku.edu (Postfix) with ESMTP id D4FC2684FEA forre...@clarku.edu; Tue, 7 Dec 2010 00:11:24 -0500 (EST) Received: from SENDERMACHINE (macaddress.hsd1.ma.comcast.net [98.216.185.77]) by cmail.clarku.edu (Postfix) with ESMTP id 82F21901E48 forre...@clarku.edu; Tue, 7 Dec 2010 00:11:24 -0500 (EST) From: USER NAMEsen...@clarku.edu Despite that internal_networks and trusted_networks are set to 140.232.0.0/16, the message still triggers the PBL rule. Given that I know that (unless there's a trojaned machine or whatever) I must trust email that comes in over authenticated SMTP/TLS through the 'cmail' host, how can I prevent it from hitting the PBL? Based on the headers you included, there's nothing indicating the sender was authenticated. Are you using the following in postfix? smtpd_sasl_authenticated_header yes -- /Jason smime.p7s Description: S/MIME Cryptographic Signature
Re: preventing authenticated smtp users from triggering PBL
I've tusseled with this and eventually I gave up and setup a cheap PC with FreeBSD that does nothing other than serve authenticated SMTP for customers. Obviously it does not run spamassassin. It relays all mail (inbound and outbound) to the main server. The one thing I would advise if you do this is to apply a limit to the maximum number of message recipients and if you can, rate-limit the mail. Sooner or later a spammer will discover one of your user's passwords and they will commence relaying through the server. Also, I would STRONGLY advise that you block inbound port 25 on this server and only permit inbound traffic on port 587, the submission port. Ted On 12/17/2010 8:28 AM, Aaron Bennett wrote: Hi, I've got an issue where users off-campus who are doing authenticated SMTP/TLS from home networks are having their mail hit by the PBL. I have trusted_networks set to include the incoming relay, but still the PBL hits it as follows: Received: from cmail.clarku.edu (muse.clarku.edu [140.232.1.151]) by mothra.clarku.edu (Postfix) with ESMTP id D4FC2684FEA forre...@clarku.edu; Tue, 7 Dec 2010 00:11:24 -0500 (EST) Received: from SENDERMACHINE (macaddress.hsd1.ma.comcast.net [98.216.185.77]) by cmail.clarku.edu (Postfix) with ESMTP id 82F21901E48 forre...@clarku.edu; Tue, 7 Dec 2010 00:11:24 -0500 (EST) From: USER NAMEsen...@clarku.edu Despite that internal_networks and trusted_networks are set to 140.232.0.0/16, the message still triggers the PBL rule. Given that I know that (unless there's a trojaned machine or whatever) I must trust email that comes in over authenticated SMTP/TLS through the 'cmail' host, how can I prevent it from hitting the PBL? Thanks, Aaron --- Aaron Bennett Manager of Systems Administration Clark University ITS
RE: preventing authenticated smtp users from triggering PBL
-Original Message- Based on the headers you included, there's nothing indicating the sender was authenticated. Are you using the following in postfix? smtpd_sasl_authenticated_header yes No, I'm not -- that's a good idea. If I turn that on, can I write a rule based on it, or will SA pick up on it automatically? Thanks, Aaron
Re: preventing authenticated smtp users from triggering PBL
On 12/17/2010 8:41 AM, Jason Bertoch wrote: On 2010/12/17 11:28 AM, Aaron Bennett wrote: I've got an issue where users off-campus who are doing authenticated SMTP/TLS from home networks are having their mail hit by the PBL. I have trusted_networks set to include the incoming relay, but still the PBL hits it as follows: Received: from cmail.clarku.edu (muse.clarku.edu [140.232.1.151]) by mothra.clarku.edu (Postfix) with ESMTP id D4FC2684FEA forre...@clarku.edu; Tue, 7 Dec 2010 00:11:24 -0500 (EST) Received: from SENDERMACHINE (macaddress.hsd1.ma.comcast.net [98.216.185.77]) by cmail.clarku.edu (Postfix) with ESMTP id 82F21901E48 forre...@clarku.edu; Tue, 7 Dec 2010 00:11:24 -0500 (EST) From: USER NAMEsen...@clarku.edu Despite that internal_networks and trusted_networks are set to 140.232.0.0/16, the message still triggers the PBL rule. Given that I know that (unless there's a trojaned machine or whatever) I must trust email that comes in over authenticated SMTP/TLS through the 'cmail' host, how can I prevent it from hitting the PBL? Based on the headers you included, there's nothing indicating the sender was authenticated. Are you using the following in postfix? smtpd_sasl_authenticated_header yes And what prevents a spammer from forging this into a header and bypassing SA? Just askin. Ted
Re: preventing authenticated smtp users from triggering PBL
On 2010/12/17 11:46 AM, Aaron Bennett wrote: -Original Message- Based on the headers you included, there's nothing indicating the sender was authenticated. Are you using the following in postfix? smtpd_sasl_authenticated_header yes No, I'm not -- that's a good idea. If I turn that on, can I write a rule based on it, or will SA pick up on it automatically? SA is supposed to pick up on it automatically. -- /Jason smime.p7s Description: S/MIME Cryptographic Signature
Re: preventing authenticated smtp users from triggering PBL
On 2010/12/17 11:47 AM, Ted Mittelstaedt wrote: And what prevents a spammer from forging this into a header and bypassing SA? Just askin. Without checking, I'd guess that matching an authentication header with an address in trusted_networks would be sufficient. If your authentication server is relaying for spammers, you've got an entirely different problem. -- /Jason smime.p7s Description: S/MIME Cryptographic Signature
Re: preventing authenticated smtp users from triggering PBL
On fre 17 dec 2010 17:47:26 CET, Ted Mittelstaedt wrote smtpd_sasl_authenticated_header yes And what prevents a spammer from forging this into a header and bypassing SA? Just askin. clever :-) this is just informative header, not one that disable sasl in postfix sender can add this header self yes, but postfix still ask for password -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: preventing authenticated smtp users from triggering PBL
Ted Mittelstaedt wrote: On 12/17/2010 8:41 AM, Jason Bertoch wrote: Based on the headers you included, there's nothing indicating the sender was authenticated. Are you using the following in postfix? smtpd_sasl_authenticated_header yes And what prevents a spammer from forging this into a header and bypassing SA? Just askin. It's not a separate header; it's a switch to indicate SMTP AUTH in the Received: header that Postfix adds. -kgd
Re: preventing authenticated smtp users from triggering PBL
On 12/17/2010 8:51 AM, Jason Bertoch wrote: On 2010/12/17 11:47 AM, Ted Mittelstaedt wrote: And what prevents a spammer from forging this into a header and bypassing SA? Just askin. Without checking, I'd guess that matching an authentication header with an address in trusted_networks would be sufficient. why are you using authenticated SMTP from trusted networks? The whole point of auth smtp is to come from UN-trusted networks. If your authentication server is relaying for spammers, you've got an entirely different problem. No, not really. You as an administrator cannot control what your users do and if your users save their authenticated SMTP passwords into their e-mail clients then later allow their machines to be cracked, then the crackers get the auth password and away they go. Ted
RE: preventing authenticated smtp users from triggering PBL
-Original Message- From: Ted Mittelstaedt [mailto:t...@ipinc.net] Sent: Friday, December 17, 2010 12:20 PM To: users@spamassassin.apache.org Subject: Re: preventing authenticated smtp users from triggering PBL why are you using authenticated SMTP from trusted networks? The whole point of auth smtp is to come from UN-trusted networks. I think you are misunderstanding. I may be on an unstrusted network, but I want to send email through a host on a trusted network. By authenticating, I can. It was the trusted host which authenticated me, and thus SA needs to take that I was authenticated by a trusted host into consideration before applying the PBL rule to the address the mail initiated on.
Re: preventing authenticated smtp users from triggering PBL
On 2010/12/17 12:19 PM, Ted Mittelstaedt wrote: why are you using authenticated SMTP from trusted networks? The whole point of auth smtp is to come from UN-trusted networks. In the OP's case, his authenticating server is separate from his SA server. In any case, the server indicating authentication (localhost or otherwise) should be a trusted server, else you don't trust the authentication. If your authentication server is relaying for spammers, you've got an entirely different problem. No, not really. You as an administrator cannot control what your users do and if your users save their authenticated SMTP passwords into their e-mail clients then later allow their machines to be cracked, then the crackers get the auth password and away they go. As I said, that is a different problem. Feel free not to use smtp-auth, or require VPN first, or whatever makes you happy. -- /Jason smime.p7s Description: S/MIME Cryptographic Signature
Re: preventing authenticated smtp users from triggering PBL
On 12/17/2010 9:12 AM, Kris Deugau wrote: Ted Mittelstaedt wrote: On 12/17/2010 8:41 AM, Jason Bertoch wrote: Based on the headers you included, there's nothing indicating the sender was authenticated. Are you using the following in postfix? smtpd_sasl_authenticated_header yes And what prevents a spammer from forging this into a header and bypassing SA? Just askin. It's not a separate header; it's a switch to indicate SMTP AUTH in the Received: header that Postfix adds. -kgd I know that, Sendmail adds the same flag when setup for auth SMTP. The problem is that SA will see this and assume the mail is safe. This is the fundamental problem with passing trust indicators in the headers. In the versions of SA I have used, SA will assume the mail is safe no matter what Received line in the header has the auth indicator set. They may have fixed that in the most recent SA but I don't believe so, and even if they did then what if SA is running on a prefilter server in front of an Exchange server for example? And you still have the problem of if a spammer's custom-written virus has determined a user password. The spammers are now able to do this with some of their hijack tools. And there are also a LOT of phishing spams now that we see from time to time that tell users that their e-mail password needs to be reset and to go to such and such a webpage and change it, etc. A couple times a month I'm changing user passwords who have fallen for these phishes. Sometimes it is mere minutes after the user has pasted their existing e-mail password into one of these phish sites that the spammers start relaying spam though the mailserver. However mostly, the typical MO is the spammers wait until Friday night at 9pm local time and then start up the spamming. This is why a separate auth SMTP server is a very useful thing to have. It is much easier to identify a spam injector when the mailserver is only handling authenticated SMTP and determine what compromised userID they are using. And you can apply rate-limits on an authenticated-SMTP server that you cannot get away with on the main mailserver. But, go ahead, do it your way. If your a small site you might even be OK for long enough to forget this advice. But sooner or later your going to get cracked into and you will wish you had separated the servers. Ted
Re: preventing authenticated smtp users from triggering PBL
On fre 17 dec 2010 18:36:25 CET, Ted Mittelstaedt wrote But, go ahead, do it your way. If your a small site you might even be OK for long enough to forget this advice. But sooner or later your going to get cracked into and you will wish you had separated the servers. clamav stops most of this shit from spammers, no seperated servers needed here, i see it as you say add more mx records on dns to help stop spaming, but as long users are plain stupid to reset passwords then thay loose all secureity -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
RE: preventing authenticated smtp users from triggering PBL
From: Ted Mittelstaedt [mailto:t...@ipinc.net] And what prevents a spammer from forging this into a header and bypassing SA? Just askin. Ted The fact that the authenticating server forwarding the request is trusted and/or internal network. SA doesn't look at any auth token outside of the trusted ring. A spammer can obviously add a fake received: header, but it would be left out of the trusted ring and thereby not considered by SA. In example. exam...@example.com is your trusted, border MSA. This is really authenticated, of course: Received: from imauser (host246-74-dynamic.49-82-r.retail.telecomitalia.it [82.49.74.246]) by msa.example.com (Postfix) with ESMTPA id 4582D39D066 for exam...@example.com; Fri, 17 Dec 2010 17:48:01 +0100 (CET) This is not: Received: from imaspammer (host246-74-dynamic.49-82-r.retail.telecomitalia.it [82.49.74.246]) by msa.example.com (Postfix) with ESMTPA id 4582D39D066 for exam...@example.com; Fri, 17 Dec 2010 17:48:01 +0100 (CET) Received: from msa.example.com (host246-74-dynamic.49-82-r.retail.telecomitalia.it [82.49.74.246]) by msa.example.com (Postfix) with ESMTP id 4582D39D066 for exam...@example.com; Fri, 17 Dec 2010 17:48:01 +0100 (CET) See? The first Received: is the forged one and looks a lot like the second one, which is the true one. SA would stop looking for auth keywords (ESMTPA, in this example) right at the second line and would not take the first into account... SA also avails the msa_networks setting to allow a node to act both as a MX and a MUA, making a message look like internally sourced iff the node says it is from an authenticated source. Giampaolo
RE: preventing authenticated smtp users from triggering PBL
SA also avails the msa_networks setting to allow a node to act both as a MX and a MUA, making a message look like internally sourced iff the node says it is from an authenticated source. Of course, I meant: SA also avails of the msa_networks setting to allow a node to act both as a MTA and a MSA, making a message look like internally sourced iff that node says it is from an authenticated source. I always get into confusion with these tricky acronyms... Giampaolo
Re: preventing authenticated smtp users from triggering PBL
On 12/17/2010 9:23 AM, Aaron Bennett wrote: -Original Message- From: Ted Mittelstaedt [mailto:t...@ipinc.net] Sent: Friday, December 17, 2010 12:20 PM To: users@spamassassin.apache.org Subject: Re: preventing authenticated smtp users from triggering PBL why are you using authenticated SMTP from trusted networks? The whole point of auth smtp is to come from UN-trusted networks. I think you are misunderstanding. I may be on an unstrusted network, but I want to send email through a host on a trusted network. By authenticating, I can. It was the trusted host which authenticated me, and thus SA needs to take that I was authenticated by a trusted host into consideration before applying the PBL rule to the address the mail initiated on. Right, but a spammer can send a message with the same authenticated flag set in the mail header through the standard SMTP port because they are manufacturing the headers out of thin air. My experience with SA is that if it sees that flag anywhere in the header, it will assume the mail is safe. I have also had the experience with earlier versions of SA that they ignore the flag completely but that was fixed a while ago. Ted
Re: preventing authenticated smtp users from triggering PBL
On 12/17/2010 9:28 AM, Jason Bertoch wrote: On 2010/12/17 12:19 PM, Ted Mittelstaedt wrote: why are you using authenticated SMTP from trusted networks? The whole point of auth smtp is to come from UN-trusted networks. In the OP's case, his authenticating server is separate from his SA server. In any case, the server indicating authentication (localhost or otherwise) should be a trusted server, else you don't trust the authentication. auth-smtp is only a speedbump to the spammers, it blocks the dumb ones. A sophisticated spammer can hijack a machine and use it's authenticated SMTP connection to it's mailserver to send spam. I never trust the authentication. If your authentication server is relaying for spammers, you've got an entirely different problem. No, not really. You as an administrator cannot control what your users do and if your users save their authenticated SMTP passwords into their e-mail clients then later allow their machines to be cracked, then the crackers get the auth password and away they go. As I said, that is a different problem. Feel free not to use smtp-auth, or require VPN first, or whatever makes you happy. Depends on what your users need. You apparently have savvy ones so you have gotten soft. I have ignorant ones so I trust nobody. Ted
Re: preventing authenticated smtp users from triggering PBL
Ted Mittelstaedt wrote: I know that, Sendmail adds the same flag when setup for auth SMTP. The problem is that SA will see this and assume the mail is safe. N if your trust path is set correctly, then SA won't run tests like eg PBL (IP blocks designated by the nominal owner as not allowed to send SMTP traffic to world+dog). It does NOT mean SA treats the mail as safe. In the versions of SA I have used, SA will assume the mail is safe no matter what Received line in the header has the auth indicator set. They may have fixed that in the most recent SA but I don't believe so, *scratch head* I've never had problems with mistaken RBL hits as the OP is asking about *if* I've got my *_networks set correctly. Earlier this year I discovered an edge case with our accelerated dialup service and had to make some adjustments to the trust path to include the accelerator host as an MSA - but previous to that the setup had been working correctly. and even if they did then what if SA is running on a prefilter server in front of an Exchange server for example? I have no idea what scenario you're referring to here - inbound mail? The OP is asking about outbound mail; and so far as your own filtering is concerned, (especially) if you're an ISP your spam filter really shouldn't penalize customers who send mail directly through the SMTP server you provide, whether that's separate from your MX(es) or not. And you still have the problem of if a spammer's custom-written virus has determined a user password. The spammers are now able to do this with some of their hijack tools. And there are also a LOT of phishing spams now that we see from time to time that tell users that their e-mail password needs to be reset and to go to such and such a webpage and change it, etc. I'm not sure where you're going with this, but this scenario will be a problem with SMTP AUTH no matter how that info is passed to SA. Unless you can guarantee real control over end-user systems, you *will* have to deal with this somehow. I'll leave it at that since the original question was about preventing PBL hits on authenticated users. But, go ahead, do it your way. If your a small site you might even be OK for long enough to forget this advice. But sooner or later your going to get cracked into and you will wish you had separated the servers. The ISP I work for currently has 6 machines handling customer-facing mail services - two physical machines for MX, two for outbound SMTP and two running SA and Clam. I've worked with a number of single-machine and partial-split configurations on a smaller scale, but I don't recall any special challenges tracking down a cracked account. TBH the only problem I recall was the size of the logfiles relative to available CPU power to search them. -kgd
RE: preventing authenticated smtp users from triggering PBL
My experience with SA is that if it sees that flag anywhere in the header, it will assume the mail is safe. I have also had the experience No, Ted. SA wouldn't accept an authenticated mark from outside its trusted_network. with earlier versions of SA that they ignore the flag completely but that was fixed a while ago. Are you speaking of the msa_network setting then? Giampaolo Ted
Re: preventing authenticated smtp users from triggering PBL
On 12/17/2010 9:32 AM, Benny Pedersen wrote: On fre 17 dec 2010 18:19:55 CET, Ted Mittelstaedt wrote The whole point of auth smtp is to come from UN-trusted networks. will not agre on that one, if you require auth it must check all ip even localhost I don't mean to say that just because auth is required from untrusted networks that it's not a good idea to use it on trusted ones. it's actually also a very good idea to block off port 25 from your mail clients even the ones ON trusted networks. In fact a good case can be made for ignoring the trusted networks mechanism in SA entirely and spamfiltering everything, even the stuff coming from your own users. unfortunately, while you can do that in a corporation it is difficult for a commercial ISP to do it to users that are paying them for mail. Users are hypocritical in this way, they want to send e-mail loaded up with very spam-like constructions (html, blank subject lines, etc.) but they don't want to receive it. ;-) or yes, i see any ip as untrusted if user do not pass sasl auth firefox is olso a safer password browser if you store login passwords in it and forget to enable master password, but some see it as a feature, i see it as a bug I regard almost the entire concept of storing passwords for interactive programs as utterly defeating the purpose of having passwords in the first place, but I recognize this isn't universally accepted. Ted
Re: preventing authenticated smtp users from triggering PBL
On 12/17/2010 10:15 AM, Kris Deugau wrote: Ted Mittelstaedt wrote: I know that, Sendmail adds the same flag when setup for auth SMTP. The problem is that SA will see this and assume the mail is safe. N if your trust path is set correctly, then SA won't run tests like eg PBL (IP blocks designated by the nominal owner as not allowed to send SMTP traffic to world+dog). It does NOT mean SA treats the mail as safe. That doesn't help us you see because we have users who send mail that is constructed in such a way as it will trigger the other SA tests, yet they insist on being allowed to send it. In the versions of SA I have used, SA will assume the mail is safe no matter what Received line in the header has the auth indicator set. They may have fixed that in the most recent SA but I don't believe so, *scratch head* I've never had problems with mistaken RBL hits It's not the RBL hits that are the problem. as the OP is asking about *if* I've got my *_networks set correctly. Earlier this year I discovered an edge case with our accelerated dialup service and had to make some adjustments to the trust path to include the accelerator host as an MSA - but previous to that the setup had been working correctly. and even if they did then what if SA is running on a prefilter server in front of an Exchange server for example? I have no idea what scenario you're referring to here - inbound mail? The OP is asking about outbound mail; and so far as your own filtering is concerned, (especially) if you're an ISP your spam filter really shouldn't penalize customers who send mail directly through the SMTP server you provide, whether that's separate from your MX(es) or not. Exactly my point. The problem I have had with SA as I said in my original response is that even if you use authenticated SMTP that setting the auth flag in the received header simply didn't work. Even when it is there, SA still filtered. If you say that setting the flag only makes SA skip the RBL checks then I believe you, but what is the point, the RBL checks aren't the issue. The filtering is the issue. It is possible this is because I use sa-milter. It is possible this is because I have an older SA version that's been fixed now. There's many possibilities. But, whatever the problem, the easy fix was using a separate machine for auth-smtp and not running SA on it. It was only a few years later after doing this when I stated seeing the spammers cracking auth-smtp passwords, that I realized how many OTHER benefits to using a separate auth-smtp server that there are. And you still have the problem of if a spammer's custom-written virus has determined a user password. The spammers are now able to do this with some of their hijack tools. And there are also a LOT of phishing spams now that we see from time to time that tell users that their e-mail password needs to be reset and to go to such and such a webpage and change it, etc. I'm not sure where you're going with this, but this scenario will be a problem with SMTP AUTH no matter how that info is passed to SA. Unless you can guarantee real control over end-user systems, you *will* have to deal with this somehow. I'll leave it at that since the original question was about preventing PBL hits on authenticated users. And my original answer was don't run SA on the authenticated users by the solution of using a separate auth-smtp machine. But, go ahead, do it your way. If your a small site you might even be OK for long enough to forget this advice. But sooner or later your going to get cracked into and you will wish you had separated the servers. The ISP I work for currently has 6 machines handling customer-facing mail services - two physical machines for MX, two for outbound SMTP and two running SA and Clam. I've worked with a number of single-machine and partial-split configurations on a smaller scale, but I don't recall any special challenges tracking down a cracked account. TBH the only problem I recall was the size of the logfiles relative to available CPU power to search them. Dealing with the logfiles is an issue but more of an issue is when the spammers are using a hijacked system that isn't on a very fast line or isn't sending traffic very fast. In those cases one of my tricks is to temporarily change the server to queueing-only, then let the server alone for 20 minutes. Then it is really easy to identify the spam in the mail queue because there is so much of it relative to the legitimate mail. Spammers have gotten very tricky and nowadays they parallelize spamruns. What they will do is your compromised machine will not just have a single message that it hammers out to 10,000 victims, instead it has 100 different messages that are hammered out to 100 different victims. Presumably they have 100 other machines across the Internet that are also cracked and are doing the same thing that are working on alternate chunks of the victim list. When I have to
Re: preventing authenticated smtp users from triggering PBL
On Fri, 17 Dec 2010 11:24:51 -0800 Ted Mittelstaedt t...@ipinc.net wrote: It is possible this is because I use sa-milter. If you want to make complex policy decisions, you might want to use something like MIMEDefang (note: I'm the author. :)) It lets you encode your mail processing logic in Perl, so you can avoid SA if mail meets certain criteria. MIMEDefang isn't always appropriate, but it's the first tool that comes to mind if you need complex or flexible filtering policy. http://www.mimedefang.org/ Regards, David.
Re: preventing authenticated smtp users from triggering PBL
On 12/17/2010 2:24 PM, Ted Mittelstaedt wrote: Exactly my point. The problem I have had with SA as I said in my original response is that even if you use authenticated SMTP that setting the auth flag in the received header simply didn't work. Even when it is there, SA still filtered. If you say that setting the flag only makes SA skip the RBL checks then I believe you, but what is the point, the RBL checks aren't the issue. The filtering is the issue. If SA can see that the message was authenticated, it will extend its trust network to include the machine that authenticated. This mainly affects things like blacklist lookups. Other than that, it will have no effect. SA will scan everything you give it regardless of the source. If you do not want certain messages to be scanned, you need to find a way to prevent them from being sent to SA. Perhaps there is a setting in sa-milter for this. -- Bowie
Re: preventing authenticated smtp users from triggering PBL
Am 17.12.2010 17:28, schrieb Aaron Bennett: Hi, I've got an issue where users off-campus who are doing authenticated SMTP/TLS from home networks are having their mail hit by the PBL. I have trusted_networks set to include the incoming relay, but still the PBL hits it as follows: Received: from cmail.clarku.edu (muse.clarku.edu [140.232.1.151]) by mothra.clarku.edu (Postfix) with ESMTP id D4FC2684FEA for re...@clarku.edu; Tue, 7 Dec 2010 00:11:24 -0500 (EST) Received: from SENDERMACHINE (macaddress.hsd1.ma.comcast.net [98.216.185.77]) by cmail.clarku.edu (Postfix) with ESMTP id 82F21901E48 for re...@clarku.edu; Tue, 7 Dec 2010 00:11:24 -0500 (EST) From: USER NAME sen...@clarku.edu Despite that internal_networks and trusted_networks are set to 140.232.0.0/16, the message still triggers the PBL rule. Given that I know that (unless there's a trojaned machine or whatever) I must trust email that comes in over authenticated SMTP/TLS through the 'cmail' host, how can I prevent it from hitting the PBL? Thanks, Aaron --- Aaron Bennett Manager of Systems Administration Clark University ITS forget trusted_networks use i.e spamass-milter with spamassassin with option -I: skip (ignore) checks if sender is authenticated additional use clamav-milter with a few sanesecurity antispam sigs , its fast enough to reject known spam from authed user without slowing down deliver out other chance, depending how you setted up spamassassin with postfix read this http://www200.pair.com/mecham/spam/bypassing.html in some setups you can use simular configs to bypass with spamassassin like bypass for amavis specially something like this ---snip In main.cf: smtpd_data_restrictions = reject_unauth_pipelining permit_sasl_authenticated check_client_access regexp:/etc/postfix/add_auth_header.regexp # In /etc/postfix/add_auth_header.regexp: /^/ PREPEND X-SMTP-Auth: no # In SpamAssassin's local.cf: header __NO_SMTP_AUTH X-SMTP-Auth =~ /^no$/m meta SMTP_AUTH !__NO_SMTP_AUTH describe SMTP_AUTH Message sent using SMTP Authentication tflags SMTP_AUTH nice score SMTP_AUTH -10 I suggest you do not use X-SMTP-Auth literally. I would obscure this by using a X-something-else header name of your choice, and if you have more than one machine, I suggest using something different on each. In order to prevent confusion (the header would end up getting written again after the message was processed by amavisd-new), you should override smtpd_data_restrictions on the amavisd-new reinjection port. In master.cf add -o smtpd_data_restrictions= 127.0.0.1:10025inetn-n--smtpd -o content_filter= -o smtpd_data_restrictions= [other typical amavisd-new reinjection port overrides] ---snip which is marking authed mail and bypass the spamassassin/amavis filter afterwards the recommended way is to let authed user use submission port submission 587/tcp , without configured the filter for it in master.cf -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: preventing authenticated smtp users from triggering PBL
On 2010/12/17 2:48 PM, Robert Schetterer wrote: forget trusted_networks use i.e spamass-milter with spamassassin with option -I: skip (ignore) checks if sender is authenticated Though I've not used spamass-milter, will this really work if the authentication server is not local? -- /Jason smime.p7s Description: S/MIME Cryptographic Signature
RE: preventing authenticated smtp users from triggering PBL
On 12/17/2010 10:15 AM, Kris Deugau wrote: Ted Mittelstaedt wrote: I know that, Sendmail adds the same flag when setup for auth SMTP. The problem is that SA will see this and assume the mail is safe. N if your trust path is set correctly, then SA won't run tests like eg PBL (IP blocks designated by the nominal owner as not allowed to send SMTP traffic to world+dog). It does NOT mean SA treats the mail as safe. That doesn't help us you see because we have users who send mail that is constructed in such a way as it will trigger the other SA tests, yet they insist on being allowed to send it. Is it spam, maybe? Note you can craft a rule such that authenticated in-bound mail may get some negative points, such that even spam-looking messages may pass. In the versions of SA I have used, SA will assume the mail is safe no matter what Received line in the header has the auth indicator set. They may have fixed that in the most recent SA but I don't believe so, *scratch head* I've never had problems with mistaken RBL hits It's not the RBL hits that are the problem. Uhu? Wasn't this thread about this? as the OP is asking about *if* I've got my *_networks set correctly. Earlier this year I discovered an edge case with our accelerated dialup service and had to make some adjustments to the trust path to include the accelerator host as an MSA - but previous to that the setup had been working correctly. and even if they did then what if SA is running on a prefilter server in front of an Exchange server for example? I have no idea what scenario you're referring to here - inbound mail? The OP is asking about outbound mail; and so far as your own filtering is concerned, (especially) if you're an ISP your spam filter really shouldn't penalize customers who send mail directly through the SMTP server you provide, whether that's separate from your MX(es) or not. Exactly my point. The problem I have had with SA as I said in my original response is that even if you use authenticated SMTP that setting the auth flag in the received header simply didn't work. Even when it is there, SA still filtered. If you say that setting the flag only makes SA skip the RBL checks then I believe you, but what is the point, the RBL checks aren't the issue. The filtering is the issue. It is possible this is because I use sa-milter. It is possible this is because I have an older SA version that's been fixed now. So, it had issues with PBL too? There's many possibilities. But, whatever the problem, the easy fix was using a separate machine for auth-smtp and not running SA on it. It was only a few years later after doing this when I stated seeing the spammers cracking auth-smtp passwords, that I realized how many OTHER benefits to using a separate auth-smtp server that there are. In example, having all that spam from cracked accounts to pass without earning any score... Isn't this exactly the benefit on gets SA-filtering also authenticated messages? Also, most SA spawners (like amavis-new, in example) may even drop and/or send you alerts when a message is earning too many spam points. Amavis-new also has banks, which lets you tune the handling of a suspicious message based on the its direction (inbound or submitted for outbound).
RE: preventing authenticated smtp users from triggering PBL
I've got an issue where users off-campus who are doing authenticated SMTP/TLS from home networks are having their mail hit by the PBL. I have trusted_networks set to include the incoming relay, but still the PBL hits it as follows: I mentioned in a direct email (as my blackberry won't make it to the list). Use submission port (587 rfc) and only allow authentication over this port. Set your MTA not to do any type of checks with mail coming in from this one. On postfix, it's a simple config in the master.cf file. This is secure enough and will accomplish what you want with very little headache. In fact, it's better because now you don't have to worry about any SA overhead for outgoing email. Everyone authenticates against this, and no worries about zombie machines, etc, because it will require a password either way.
Re: preventing authenticated smtp users from triggering PBL
* Ted Mittelstaedt t...@ipinc.net: On 12/17/2010 8:41 AM, Jason Bertoch wrote: On 2010/12/17 11:28 AM, Aaron Bennett wrote: I've got an issue where users off-campus who are doing authenticated SMTP/TLS from home networks are having their mail hit by the PBL. I have trusted_networks set to include the incoming relay, but still the PBL hits it as follows: Received: from cmail.clarku.edu (muse.clarku.edu [140.232.1.151]) by mothra.clarku.edu (Postfix) with ESMTP id D4FC2684FEA forre...@clarku.edu; Tue, 7 Dec 2010 00:11:24 -0500 (EST) Received: from SENDERMACHINE (macaddress.hsd1.ma.comcast.net [98.216.185.77]) by cmail.clarku.edu (Postfix) with ESMTP id 82F21901E48 forre...@clarku.edu; Tue, 7 Dec 2010 00:11:24 -0500 (EST) From: USER NAMEsen...@clarku.edu Despite that internal_networks and trusted_networks are set to 140.232.0.0/16, the message still triggers the PBL rule. Given that I know that (unless there's a trojaned machine or whatever) I must trust email that comes in over authenticated SMTP/TLS through the 'cmail' host, how can I prevent it from hitting the PBL? The examples you provided above only tell ESMTP was used. This make me think you are either using a very ancient version of Postfix or the Received: headers stem from a sender who did not SMTP AUTH, because Postfix prints ESMTPSA (S=secure, A=authenticated) when TLS and SMTP AUTH have been used in the SMTP session. Based on the headers you included, there's nothing indicating the sender was authenticated. Are you using the following in postfix? smtpd_sasl_authenticated_header yes And what prevents a spammer from forging this into a header and bypassing SA? Just askin. Anyone can forge this, but you don't need to fall for it. You could, for example, only let users send messages from your servers if they use the submission port (tcp/587). On this port SMTP AUTH is a must to send a message and smtpd_sasl_authenticated_header may be trusted safely (unless someones credentials have been stolen and the spammer uses that identity). At the same time you disable SMTP AUTH on port 25 and kill any header that claims to be from your server using ESMTPA or ESMTPSA. You could, for example, place a special header check next to your regular port 25 smtp service in master.cf. The header check rule matches on your server name and the string ESMTP[A|SA] and results in IGNORE (see: man 5 header_checks): # == # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # == smtp inet n - - - - smtpd -o header_checks=pcre:/etc/postfix/kill_forged_headers submission inet n - - - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_authenticated_header=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING in /etc/postfix/kill_forged_headers: /^by\hexample.org\h\(Postfix\)\hwith\hESMTP[A|SA]/IGNORE p...@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563 signature.asc Description: Digital signature
Re: preventing authenticated smtp users from triggering PBL
On 12/17/2010 11:57 AM, Giampaolo Tomassoni wrote: On 12/17/2010 10:15 AM, Kris Deugau wrote: Ted Mittelstaedt wrote: I know that, Sendmail adds the same flag when setup for auth SMTP. The problem is that SA will see this and assume the mail is safe. N if your trust path is set correctly, then SA won't run tests like eg PBL (IP blocks designated by the nominal owner as not allowed to send SMTP traffic to world+dog). It does NOT mean SA treats the mail as safe. That doesn't help us you see because we have users who send mail that is constructed in such a way as it will trigger the other SA tests, yet they insist on being allowed to send it. Is it spam, maybe? It's shit-for-brains young girl administrative assistants at companies who are our customers who apparently have too much time on their hands. When you see e-mails using fonts, blue lettering on a yellow-orange background that contains a jpg of a sunset with a big-old smiley in the sun, liberally laced with capitalized words, the blink tag, and a half dozen fluff URL's they apparently found during the mornings surfing of pictures of kittens clawing stuffed toys, copied to at least 50 of their other shit-for-brains friends at other companies, it makes you wonder how these companies make any money at all. I guess these creatures must serve a decorative function at the reception desk. Certainly they can't be trusted to answer the phone! Note you can craft a rule such that authenticated in-bound mail may get some negative points, such that even spam-looking messages may pass. But then I have to be forever modifying it when the next customer hires another one of the airheads. In the versions of SA I have used, SA will assume the mail is safe no matter what Received line in the header has the auth indicator set. They may have fixed that in the most recent SA but I don't believe so, *scratch head* I've never had problems with mistaken RBL hits It's not the RBL hits that are the problem. Uhu? Wasn't this thread about this? I took the OP's post to mean that the RBL hit was just the proverbial canary in the coal mine, in other words he's seeing the RBL hits because those are the ones that go over the threshold and get the message blocked, but that ultimately he didn't want ANY filtering on an authenticated SMTP mail. But perhaps he does just want SA doing filtering with the exception of the RBL checks, on incoming auth-smtp. That sounds odd to me, but whatever floats your boat I guess. as the OP is asking about *if* I've got my *_networks set correctly. Earlier this year I discovered an edge case with our accelerated dialup service and had to make some adjustments to the trust path to include the accelerator host as an MSA - but previous to that the setup had been working correctly. and even if they did then what if SA is running on a prefilter server in front of an Exchange server for example? I have no idea what scenario you're referring to here - inbound mail? The OP is asking about outbound mail; and so far as your own filtering is concerned, (especially) if you're an ISP your spam filter really shouldn't penalize customers who send mail directly through the SMTP server you provide, whether that's separate from your MX(es) or not. Exactly my point. The problem I have had with SA as I said in my original response is that even if you use authenticated SMTP that setting the auth flag in the received header simply didn't work. Even when it is there, SA still filtered. If you say that setting the flag only makes SA skip the RBL checks then I believe you, but what is the point, the RBL checks aren't the issue. The filtering is the issue. It is possible this is because I use sa-milter. It is possible this is because I have an older SA version that's been fixed now. So, it had issues with PBL too? There's many possibilities. But, whatever the problem, the easy fix was using a separate machine for auth-smtp and not running SA on it. It was only a few years later after doing this when I stated seeing the spammers cracking auth-smtp passwords, that I realized how many OTHER benefits to using a separate auth-smtp server that there are. In example, having all that spam from cracked accounts to pass without earning any score... Isn't this exactly the benefit on gets SA-filtering also authenticated messages? Also, most SA spawners (like amavis-new, in example) may even drop and/or send you alerts when a message is earning too many spam points. Amavis-new also has banks, which lets you tune the handling of a suspicious message based on the its direction (inbound or submitted for outbound). Those are good points and touch on what I would call different approaches to e-mail on the Internet. These days, with the free mail providers, hotmail, gmail, etc. quite a lot of people have gotten used to the notion that e-mailboxes should be free. Well, you know how it is with something
