Re: Verification of DANE TLSA MX equivalent RRs
* Viktor Dukhovni postfix-us...@dukhovni.org: On Thu, Sep 19, 2013 at 10:44:27AM +0200, Stefan Foerster wrote: * Viktor Dukhovni postfix-us...@dukhovni.org: You should be looking at the SMTP draft, not the OPS draft. [...] Would that be draft-ietf-dane-smtp-01? Because this one, too, explicitely doesn't cover mail submission. No: https://tools.ietf.org/html/draft-dukhovni-smtp-opportunistic-tls-01 I see. So, for joe.u...@example.com the whole setup would probably be something along: - publish SRV record for _submission._tcp SRV 0 1 587 mail.example.com - publish TLSA record for mail.example.com - one might think about certificate usage 0 or 1 here, right? - make sure the submission server at mail.example.com has certificates for mail.example.com as well as example.com, with example.com being the certificate that's displayed when the client does't support SNI, at least according to draft-fanf-dane-mua-00 I can see why you are being sceptical about MUA support for this. And, from an ops PoV, the requirement of having two certificates, one for the server hostname and one for the mail domain, with the need of obtaining both from a CA that has widepread support amongst MUAs, with the further need to provide two endpoints, one for old and one for new clients, is a real PITA. JFTR: The second mentioning of RFC6409 in section 3 of draft-dukhovni-smtp-opportunistic-tls-01 might possibly be a typo, referring to RFC6186. Stefan signature.asc Description: Digital signature
TLS: advice on best practices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I have a TLS enabled Postfix with a PKI certificate. The configuration of SMTP TLS is: smtp_tls_security_level = may smtp_tls_note_starttls_offer = yes smtp_tls_fingerprint_digest = sha1 smtp_tls_policy_maps = hash:/etc/postfix/tls_policy and in tls_policy I put some recipient domains I know with fingerprint and the fingerprint(s) of their keys. But many PKI keys last 365 days, so sooner or later the fingerprints are no longer valid and the mail will not be delivered to that domains until I change the policy or I put a new fingerprint. My question is: with PKI keys is better to leave the opportunistic TLS policy and use fingerprint only for self issued keys with 3650 days of validity or are there some better ways to handle this? Thank you in advance. Ciao, luigi - -- / +--[Luigi Rosa]-- \ I have always imagined that paradise will be a kind of library. --Jorge Luis Borges -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlI8MzwACgkQ3kWu7Tfl6ZTs9ACdERs11iAybH22fRTs+AmDU3QQ CBUAniWJce7Z0kb2sb2Nt69Z8BCFLnZh =PrkZ -END PGP SIGNATURE-
Re: Verification of DANE TLSA MX equivalent RRs
On Fri, Sep 20, 2013 at 11:47:35AM +0200, Stefan Foerster wrote: I see. So, for joe.u...@example.com the whole setup would probably be something along: - publish SRV record for _submission._tcp SRV 0 1 587 mail.example.com Yes. Though it will be some time before most MUAs are zeroconf in this way. Perhaps the mobile device OSs will lead here, but it is also possible that each platform will simply assume you're using their cloud email service, and not choose to support RFC 6186. - publish TLSA record for mail.example.com - one might think about certificate usage 0 or 1 here, right? No. Whenever there is indirection between the user specified destination and the name of the ultimate TCP endpoint host, and especially when TLS support is discovered rather (also requiring DNSSEC to avoid downgrade attacks) the public CA PKI is inapplicable without DNSSEC, so the same guidelines apply, usage 2/3 only. - make sure the submission server at mail.example.com has certificates for mail.example.com as well as example.com, with example.com being the certificate that's displayed when the client does't support SNI, at least according to draft-fanf-dane-mua-00 No need. One certificate is enough. With certificate usage 2 TLSA RRs, just point the SRV record at the same name that users who don't rely on zeroconf via RFC 6186 are told to set as their SMTP server. With certificate usage 3 TLSA RRs, the name in the certificate is irrelevant. from an ops PoV, the requirement of having two certificates, one for the server hostname and one for the mail domain, with the need of obtaining both from a CA that has widepread support amongst MUAs, with the further need to provide two endpoints, one for old and one for new clients, is a real PITA. There is no such need, the draft RFC allows server operators to use *either* name (whichever they prefer), and requires clients to support both. There is NO requirement for server operators to publish both. JFTR: The second mentioning of RFC6409 in section 3 of draft-dukhovni-smtp-opportunistic-tls-01 might possibly be a typo, referring to RFC6186. Thanks, yes, I'll fix that. -- Viktor.
Re: Verification of DANE TLSA MX equivalent RRs
* Viktor Dukhovni postfix-us...@dukhovni.org: On Fri, Sep 20, 2013 at 11:47:35AM +0200, Stefan Foerster wrote: - make sure the submission server at mail.example.com has certificates for mail.example.com as well as example.com, with example.com being the certificate that's displayed when the client does't support SNI, at least according to draft-fanf-dane-mua-00 No need. One certificate is enough. With certificate usage 2 TLSA RRs, just point the SRV record at the same name that users who don't rely on zeroconf via RFC 6186 are told to set as their SMTP server. With certificate usage 3 TLSA RRs, the name in the certificate is irrelevant. from an ops PoV, the requirement of having two certificates, one for the server hostname and one for the mail domain, with the need of obtaining both from a CA that has widepread support amongst MUAs, with the further need to provide two endpoints, one for old and one for new clients, is a real PITA. There is no such need, the draft RFC allows server operators to use *either* name (whichever they prefer), and requires clients to support both. There is NO requirement for server operators to publish both. To be honest, that's not what I read from section 4 of draft-fanf-dane-mua-00: | A mail server that is the target of an [RFC6186] SRV record MUST have | a TLS certificate that authenticates the SRV owner domain (i.e. the | user's mail domain). This is necessary for clients that cannot | perform DNSSEC validation. This certificate MUST be the default that | is presented if the client does not use the TLS Server Name Indication | extension (TLS SNI) [RFC6066]. | In order to support this specification, the mail server MUST also have | a certificate that authenticates the SRV target domain (the mail | server hostname). This can be done using a multi-name certificate or | by using the client's TLS SNI to select the appropriate certificate. | The mail server's TLSA record MUST correspond to this certificate. Or were you referring to draft-dukhovni-smtp-opportunistic-tls-01? Stefan P.S: I feel that we might be stretching what's considered on-topic on this mailing list - perhaps we should take this off-list, or to a more appropriate (read: DANE related) list? signature.asc Description: Digital signature
Re: TLS: advice on best practices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/20/2013 6:36 AM, Luigi Rosa wrote: Hi, I have a TLS enabled Postfix with a PKI certificate. The configuration of SMTP TLS is: smtp_tls_security_level = may smtp_tls_note_starttls_offer = yes smtp_tls_fingerprint_digest = sha1 smtp_tls_policy_maps = hash:/etc/postfix/tls_policy and in tls_policy I put some recipient domains I know with fingerprint and the fingerprint(s) of their keys. But many PKI keys last 365 days, so sooner or later the fingerprints are no longer valid and the mail will not be delivered to that domains until I change the policy or I put a new fingerprint. My question is: with PKI keys is better to leave the opportunistic TLS policy and use fingerprint only for self issued keys with 3650 days of validity or are there some better ways to handle this? fingerprint verification is intended for a very limited number of clients -- typically internal hosts or highly trusted business partners willing to closely cooperate with you. Without close cooperation from the remote site, fingerprint verification just isn't practical. For an arbitrary third-party site, you'll probably need to stick to encrypt or maybe in some cases verify. http://www.postfix.org/TLS_README.html#client_tls Hopefully widespread DANE adoption will take the pain out of this in the future. -- Noel Jones -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSPFttAAoJEJGRUHb5Oh6gVP8H/13ES2pc0zGkSJGwBXXoBI9h h+epsLfdT4QX2swUI785HzjDXoLFUzNQyqUXdRo4jp3rnUoQABLP1mi/NZpZlnuy QKwtIvLqF1dTwxcQ4KNMkOMkWXFRE0VYHSQVnWfpYP5K/XZPYm5uIHKb2oM9C0eH yJvZ/geC+dmODLDEwvFXfk5Tx1U68CuJ2+25cRoouVtwX9vbD4VlorQf1osnG5Gz Fp3GzMXe6CIS/2DuujXv/v6CYSqVzqtmjtawbl6ZBF7+YUxf9Ae+JJaIoqpjgyf+ ecRStPfbqsbRBzY/8/3OFW95ZoseAEBKMbjLmPCovFx1+b1YyLwY+7SgW2q+Ex0= =7A8M -END PGP SIGNATURE-
Re: TLS: advice on best practices
On Fri, Sep 20, 2013 at 09:27:57AM -0500, Noel Jones wrote: Without close cooperation from the remote site, fingerprint verification just isn't practical. For an arbitrary third-party site, you'll probably need to stick to encrypt or maybe in some cases verify. http://www.postfix.org/TLS_README.html#client_tls One should generally use secure, not verify. It was mistake on my part to create both security levels, they differ only in the default matching strategy. We should have had a single level with a configurable global matching strategy (smtp_tls_verify_cert_match) that defaults safe, and with the per-site match overrides allowing users to fine-tune as necessary. Instead we have verify and secure' that differ only in the unsafe setting of smtp_tls_verify_cert_match vs. a safe setting for the analogous smtp_tls_secure_cert_match. Users should probably set: # Default MITM safe matching (as in secure) smtp_tls_verify_cert_match = nexthop, dot-nexthop smtp_tls_secure_cert_match = nexthop, dot-nexthop # Default MITM unsafe matching (as in verify) smtp_tls_verify_cert_match = hostname smtp_tls_secure_cert_match = hostname and then use the two levels interchangeably. [ Don't try to alias one in terms of the implicit default value of the other, Postfix configuration parameter expansion happens incrementally, and the defaults are not all set when parameters are expanded. ] Hopefully widespread DANE adoption will take the pain out of this in the future. Amen. -- Viktor.
Re: Verification of DANE TLSA MX equivalent RRs
On Fri, Sep 20, 2013 at 04:39:42PM +0200, Stefan Foerster wrote: There is no such need, the draft RFC allows server operators to use *either* name (whichever they prefer), and requires clients to support both. There is NO requirement for server operators to publish both. To be honest, that's not what I read from section 4 of draft-fanf-dane-mua-00: I'll take a look at that. It is still a draft, if necessary, we'll work to revise it. | A mail server that is the target of an [RFC6186] SRV record MUST have | a TLS certificate that authenticates the SRV owner domain (i.e. the | user's mail domain). This is necessary for clients that cannot | perform DNSSEC validation. This certificate MUST be the default that | is presented if the client does not use the TLS Server Name Indication | extension (TLS SNI) [RFC6066]. | In order to support this specification, the mail server MUST also have | a certificate that authenticates the SRV target domain (the mail | server hostname). This can be done using a multi-name certificate or | by using the client's TLS SNI to select the appropriate certificate. | The mail server's TLSA record MUST correspond to this certificate. Or were you referring to draft-dukhovni-smtp-opportunistic-tls-01? The latter naturally. My take is that clients using SRV RRs that can't do DNSSEC get no security so there's no point in specifying required certificates for these. Especially with many domains hosted by third parties it is impractical to require pervasive trans-organizational SNI. So the above requirement is a mistake that needs to be corrected. P.S: I feel that we might be stretching what's considered on-topic on this mailing list - perhaps we should take this off-list, or to a more appropriate (read: DANE related) list? If you want to pursue the MUA issues further, or have additional questions/comments about DANE for MTAs, feel free to join the DANE WG mailing list: d...@ietf.org Your timing is good, Tony has just returned to the list after a long break, and this is a good opportunity to start resolving any conflicts between his prior work and my more recent drafts. -- Viktor.
Do not forward spam
Hi, i'm having problems with spam forwarding - lot's of our users enabled forwarding to gmail and every spam they receive is also forwarded. Today gmail block us because of spam (which we were just forwarding, not sending). Any tips how can i disable forwarding in case of a spam (for example, when message has X-Spam-Status: Yes) ? Thanks. azur
Re: Do not forward spam
Am 20.09.2013 16:42, schrieb azurIt: Hi, i'm having problems with spam forwarding - lot's of our users enabled forwarding to gmail and every spam they receive is also forwarded. Today gmail block us because of spam (which we were just forwarding, not sending). Any tips how can i disable forwarding in case of a spam (for example, when message has X-Spam-Status: Yes) ? Thanks. azur you should reject and/or filter ( quarantaine ) incomming spam at incomming smtp stage what about using clamav-milter with sane-security antispam signatures and/or spamass-milter, perhaps amavis-milter Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Do not forward spam
On Fri, Sep 20, 2013 at 10:42 AM, azurIt azu...@pobox.sk wrote: Hi, i'm having problems with spam forwarding - lot's of our users enabled forwarding to gmail and every spam they receive is also forwarded. Today gmail block us because of spam (which we were just forwarding, not sending). Any tips how can i disable forwarding in case of a spam (for example, when message has X-Spam-Status: Yes) ? Thanks. azur As a first line of defence, maybe use postscreen to cut down the spam before it reaches smtpd ? The postscreen documentation (http://www.postfix.org/POSTSCREEN_README.html) mentions four layers of defence, if you have some of that implemented, or all of it, you would be able to cut down on your incoming spam, before anything gets forwarded to Google or any other place. cheers, mehul -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
Re: Do not forward spam
Am 20.09.2013 19:31, schrieb azurIt: I don't believe in rejecting e-mails based on spam checks - there are and always be false positives. I will rather accept 100 spams than reject single legitimate e-mail message. ok ,so why cry about your own decisions ? Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Do not forward spam
azurIt wrote: I don't believe in rejecting e-mails based on spam checks - there are and always be false positives. I will rather accept 100 spams than reject single legitimate e-mail message. Spam volume these days is such that accepting, processing, and storing **all** mail is becoming more and more unworkable, especially with a situation like you're asking about where that stream of garbage is forwarded out of your system to a system that *does* reject some volume of spam (or blocks your system outright if you send them too much spam). Depending on how you count, we reject anywhere from 50% to 90% of our total mail volume based on a Spamhaus lookup. Aside from an incident where a Postini netblock got listed for a little while, I don't think I recall *any* false positives over several years. To more directly answer your original question, it would help if you posted an overview of your mail flow. It sounds like your forwarding is done via alias rather than .forward or some similar processing on final local delivery; choosing a different place for your forwarding may help cut the volume of forwarded spam. -kgd
Re: Do not forward spam
Am 20.09.2013 18:12, schrieb azurIt: Blocking emails based on spam filters are always wrong. Spam recognition will NEVER be 100%, there are always false positives. We are accepting all emails and filter them after. I just need to tell Postfix to NOT forward particular messages and only deliver them locally (for example, as mentioned before, based on headers). azur you might use amavis-new with quarantaine, so you might inspect suspicious mails by human admins or the users themselfs for release or reject, after all, my false postives rate with clamav/spamass milter is nearly null ,about 1 users , so thats good enough in real, if really something goes wrong ( mail bounced at smtp income stage), sender may contact postmaster ( configure some contact in the bounce notice ) fix the problem Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Do not forward spam
On Sep 20, 2013, at 18:21, azurIt azu...@pobox.sk wrote: CC: postfix-users@postfix.org On Fri, Sep 20, 2013 at 10:42 AM, azurIt azu...@pobox.sk wrote: Hi, i'm having problems with spam forwarding - lot's of our users enabled forwarding to gmail and every spam they receive is also forwarded. Today gmail block us because of spam (which we were just forwarding, not sending). Any tips how can i disable forwarding in case of a spam (for example, when message has X-Spam-Status: Yes) ? Thanks. azur As a first line of defence, maybe use postscreen to cut down the spam before it reaches smtpd ? The postscreen documentation (http://www.postfix.org/POSTSCREEN_README.html) mentions four layers of defence, if you have some of that implemented, or all of it, you would be able to cut down on your incoming spam, before anything gets forwarded to Google or any other place. Looks fine but i NEED to deliver also spams locally, i just don't want to forward them away. No one 'needs' to deliver spam locally. On a properly configured system, the vast majority of spam bounces off the before-queue defenses, and never reaches the stage where a decision about forwarding or local storage needs to be made. If you are running into trouble with Gmail it is quite likely that you are accepting too much garbage from bots and zombies. This is a problem you should solve at the earliest possible stage, which is where postscreen comes in. Read the documentation again, and understand why it should be part of your defenses. If you think your problem can be solved using header checks, read the appropriate documentation; http://www.postfix.org/header_checks.5.html But really, start by cutting down on what you accept. I don't believe in rejecting e-mails based on spam checks - there are and always be false positives. I will rather accept 100 spams than reject single legitimate e-mail message.
Re: Do not forward spam
On Sep 20, 2013, at 18:12, azurIt azu...@pobox.sk wrote: On 2013-09-20 09:42, azurIt wrote: i'm having problems with spam forwarding - lot's of our users enabled forwarding to gmail and every spam they receive is also forwarded. Today gmail block us because of spam (which we were just forwarding, not sending). Any tips how can i disable forwarding in case of a spam (for example, when message has X-Spam-Status: Yes) ? Thanks. You may first want to look at why you are receiving the spam in the first place and not rejecting it. There are many ways to fight this, much of which will come down to what your policies are regarding rejecting mail, false positives, etc. You could always turn off the ability of your users to forward mail to other services, problem solved. This is not an option, we are offering commercial services and users demands this feature. Gmail offers POP3 retrieval, which is a perfectly servicable option if users DEMAND every spam message, plus forwarding. Blocking emails based on spam filters are always wrong. Spam recognition will NEVER be 100%, there are always false positives. We are accepting all emails and filter them after. I just need to tell Postfix to NOT forward particular messages and only deliver them locally (for example, as mentioned before, based on headers). Has it occurred to you that the reason lots of your users enable forwarding to Gmail may be the fact that you accept everything? And that they are essentially using Gmail as the spam filter they need because of this? You are creating this problem yourself. No spam filtering is 100% without false positives, but properly configured before-queue defenses generally cut out ~90% of the garbage you get from bots and zombies. Or more, depending on how tight of a ship you can afford to run. It also presents a traceable error path to any senders that may be caught with their pants down because of configuration issues, compromised systems and what have you. This means that anything that actually reaches the stage where you decide whether to store or forward is about 10% of what you are accepting now, and much less likely to cause trouble with forwarding. If you must do your own thing, figure out how to use the quarantine features of your chosen content filtering software, and do forwarding from there based on rules you specify. Or dig into the Postfix documentation and figure out how you might achieve what you are after without backscattering, or discarding mail. Mvg, Joni
Re: Do not forward spam
On 2013-09-20 09:42, azurIt wrote: i'm having problems with spam forwarding - lot's of our users enabled forwarding to gmail and every spam they receive is also forwarded. Today gmail block us because of spam (which we were just forwarding, not sending). Any tips how can i disable forwarding in case of a spam (for example, when message has X-Spam-Status: Yes) ? Thanks. You may first want to look at why you are receiving the spam in the first place and not rejecting it. There are many ways to fight this, much of which will come down to what your policies are regarding rejecting mail, false positives, etc. You could always turn off the ability of your users to forward mail to other services, problem solved. This is not an option, we are offering commercial services and users demands this feature. If you absolutely must be able to forward mail, then you will want to work with Google so they understand what you are doing, and allow this mail to pass without blocking your system. But I would still work on blocking the spam from being received in the first place. Blocking emails based on spam filters are always wrong. Spam recognition will NEVER be 100%, there are always false positives. We are accepting all emails and filter them after. I just need to tell Postfix to NOT forward particular messages and only deliver them locally (for example, as mentioned before, based on headers). azur
Re: Do not forward spam
CC: postfix-users@postfix.org On Fri, Sep 20, 2013 at 10:42 AM, azurIt azu...@pobox.sk wrote: Hi, i'm having problems with spam forwarding - lot's of our users enabled forwarding to gmail and every spam they receive is also forwarded. Today gmail block us because of spam (which we were just forwarding, not sending). Any tips how can i disable forwarding in case of a spam (for example, when message has X-Spam-Status: Yes) ? Thanks. azur As a first line of defence, maybe use postscreen to cut down the spam before it reaches smtpd ? The postscreen documentation (http://www.postfix.org/POSTSCREEN_README.html) mentions four layers of defence, if you have some of that implemented, or all of it, you would be able to cut down on your incoming spam, before anything gets forwarded to Google or any other place. Looks fine but i NEED to deliver also spams locally, i just don't want to forward them away.
Re: Do not forward spam
Am 20.09.2013 18:12, schrieb azurIt: Blocking emails based on spam filters are always wrong says who? Spam recognition will NEVER be 100% nothing will 100%, nowehere there are always false positives yes, and there are some 100 times more spam We are accepting all emails and filter them after than accept that you are considered as a spammer and backscatter I just need to tell Postfix to NOT forward particular messages no, you need to realize that they way you are acting you are considered as spammer for good reasons and the wrong handling accepting anything is nothing postfix can fix after that
Re: Do not forward spam
Am 20.09.2013 19:31, schrieb azurIt: I don't believe in rejecting e-mails based on spam checks - there are and always be false positives. I will rather accept 100 spams than reject single legitimate e-mail message. ok ,so why cry about your own decisions ? Where exacly i was 'crying'? I was just friendly ASKING, if Postfix is able to _not_ forward a message based on it's headers.
Re: Do not forward spam
azurIt wrote: I don't believe in rejecting e-mails based on spam checks - there are and always be false positives. I will rather accept 100 spams than reject single legitimate e-mail message. Spam volume these days is such that accepting, processing, and storing **all** mail is becoming more and more unworkable, especially with a situation like you're asking about where that stream of garbage is forwarded out of your system to a system that *does* reject some volume of spam (or blocks your system outright if you send them too much spam). Depending on how you count, we reject anywhere from 50% to 90% of our total mail volume based on a Spamhaus lookup. Aside from an incident where a Postini netblock got listed for a little while, I don't think I recall *any* false positives over several years. To more directly answer your original question, it would help if you posted an overview of your mail flow. It sounds like your forwarding is done via alias rather than .forward or some similar processing on final local delivery; choosing a different place for your forwarding may help cut the volume of forwarded spam. Thank you for a first post which tries to answer my original question. I'm doing forwards with 'virtual_alias_maps'. I will be, probably, able to implement all forwarding features of postfix with, for example, maildrop but it will be really lots of work. But it's a good idea anyway, thanks. azur
Re: Do not forward spam
On Fri, Sep 20, 2013 at 10:03:32PM +0200, azurIt wrote: On 2013-09-20 09:42, azurIt wrote: i'm having problems with spam forwarding - lot's of our users enabled forwarding to gmail and every spam they receive is also forwarded. Today gmail block us because of spam (which we were just forwarding, not sending). Any tips how can i disable snip One note to all fans of 'spam filters rejecting' here: Did you even notice that NO ONE of big e-mail providers are rejecting messages based on standard spam filter techniques? Google, Yahoo, Microsoft, ATT, ... No one is doing it, most of them have developed their own No, I have not noticed that. Neither have you! You have noticed, at the top of this thread, that gmail is rejecting you! On the contrary, I have noticed that every major receiver has some sort of pre-DATA filtering rules. I have noticed, when a server for which I was responsible was listed on Spamhaus PBL or XBL, that I wasn't delivering much of my mail at all. Every major site was subject to delivery problems. I've personally known Microsoft to accept and discard non-spam mail. I've heard about Google doing the same. filtering systems and you must be really big spammer to be blocked permanently. The best of them is Google, just try their filters and you will see (even blocking which was used to us was targeted only to particular messages). When my server's reverse DNS failed (blame my former colo provider, not me), gmail rejected everything I sent. You apparently have little experience with real-world email. Your quarantine, don't reject ideals simply will not work for many sites. I've told before of a heavily-spammed small business domain I began hosting in 2005. The office manager, who was supposed to go through the email and print the important ones out for the boss, could literally do nothing else all day. Delete, delete, delete ... hours on end. Almost through the inbox? Oops, it's time to go home! I got her 8+ hour email sorting job down to about a half hour, by using sane and reasonable spam blocking techniques. Once one of her correspondents' mail host got listed on Spamhaus XBL, and sure enough, we rejected that mail. The sender got a bounce and knew that the mail didn't get through. So the sender called to ask. See, it's a whole lot better for interoperability in the days of 90%+ traffic being spam and abuse to reject mail than to tuck it away in a deep, dark quarantine where no one will ever have time to look. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: Do not forward spam
On 2013-09-20 09:42, azurIt wrote: i'm having problems with spam forwarding - lot's of our users enabled forwarding to gmail and every spam they receive is also forwarded. Today gmail block us because of spam (which we were just forwarding, not sending). Any tips how can i disable forwarding in case of a spam (for example, when message has X-Spam-Status: Yes) ? Thanks. You may first want to look at why you are receiving the spam in the first place and not rejecting it. There are many ways to fight this, much of which will come down to what your policies are regarding rejecting mail, false positives, etc. You could always turn off the ability of your users to forward mail to other services, problem solved. If you absolutely must be able to forward mail, then you will want to work with Google so they understand what you are doing, and allow this mail to pass without blocking your system. But I would still work on blocking the spam from being received in the first place.
Re: Do not forward spam
/dev/rob0: No, I have not noticed that. Neither have you! You have noticed, at the top of this thread, that gmail is rejecting you! The way I read his request is that he wants to forward non-spam only, and is looking for a Postfix solution that supports this. The best proposal I can come up with is a Milter that triggers on headers added by has spam filter, and that adds a second recipient only if the mail does not appear to be spam. Wietse
Re: Do not forward spam
Am 20.09.2013 22:10, schrieb azurIt: Am 20.09.2013 22:03, schrieb azurIt: One note to all fans of 'spam filters rejecting' here: Did you even notice that NO ONE of big e-mail providers are rejecting messages based on standard spam filter techniques? Google, Yahoo, Microsoft, ATT, ... No one is doing it, most of them have developed their own filtering systems and you must be really big spammer to be blocked permanently. The best of them is Google, just try their filters and you will see (even blocking which was used to us was targeted only to particular messages) that must be why you started this with Today gmail block us because of spam (which we were just forwarding, not sending) :-) Please read my whole message. Thank you i did - but you still refuse to understand that *any* well implemented spam filter based on content also filters and rejects *pre queue* - nobody but you does accept *any* message and in many countries filter and delete spam *after* accept it from the sender even is not permitted by law *any* serious spam filter REJECTS at SMTP level because it is the only way the sender knows it was filtered while not be a backscatter because the *sending server* is generating the bounce with the rejct message of the final destination and if it was a professional spammer he will supress it and not read the reject message at all here you go: http://www.postfix.org/SMTPD_PROXY_README.html BTW: avoid to look answering yourself by quoting because you cut the poster you refer
Re: Do not forward spam
CC: postfix-users@postfix.org azurIt: I was just friendly ASKING, if Postfix is able to _not_ forward a message based on it's headers. Assumung that these headers are added by a spam filter, this would require a Milter plugin that examines messages after your spam filter, and that dynamically adds a forwarding address to the message envelope (i.e. in addition to the existing local mailbox address). Milters can be implemented in a variety of languages including Perl and Python. If all they do is inspect message headers, then the performance impact should be limited. Thank you, i will consider this.
Re: Do not forward spam
Am 20.09.2013 22:03, schrieb azurIt: One note to all fans of 'spam filters rejecting' here: Did you even notice that NO ONE of big e-mail providers are rejecting messages based on standard spam filter techniques? Google, Yahoo, Microsoft, ATT, ... No one is doing it, most of them have developed their own filtering systems and you must be really big spammer to be blocked permanently. The best of them is Google, just try their filters and you will see (even blocking which was used to us was targeted only to particular messages) that must be why you started this with Today gmail block us because of spam (which we were just forwarding, not sending) :-)
Re: Do not forward spam
On 2013-09-20 1:31 PM, azurIt azu...@pobox.sk wrote: I don't believe in rejecting e-mails based on spam checks Then don't allow blanket forwarders, or just accept it when someone blocks you for good cause because of your silly decisions. - there are and always be false positives. For CONTENT filter based spam checks, yes, certainly, but there are a ton of NON-CONTENT pre-queue anti-spam checks that will block or reject 90-95%+ of the garbage with a FP rate of as close to 100% as you can get, the best of which are available in postscreen. Failure to take advantage of such options is just plain foolish. I will rather accept 100 spams than reject single legitimate e-mail message. Would you rather accept 1000 spams than reject one legitimate message? 10,000? A million? If someone is using a server that is spewing out spam, I am absolutely happy to reject their LEGITIMATE mail unless/until they fix their server, as should anyone. -- Best regards, */Charles/*
Re: Do not forward spam
azurIt: I was just friendly ASKING, if Postfix is able to _not_ forward a message based on it's headers. Assumung that these headers are added by a spam filter, this would require a Milter plugin that examines messages after your spam filter, and that dynamically adds a forwarding address to the message envelope (i.e. in addition to the existing local mailbox address). Milters can be implemented in a variety of languages including Perl and Python. If all they do is inspect message headers, then the performance impact should be limited. Wietse
Re: Do not forward spam
On 2013-09-20 09:42, azurIt wrote: i'm having problems with spam forwarding - lot's of our users enabled forwarding to gmail and every spam they receive is also forwarded. Today gmail block us because of spam (which we were just forwarding, not sending). Any tips how can i disable forwarding in case of a spam (for example, when message has X-Spam-Status: Yes) ? Thanks. You may first want to look at why you are receiving the spam in the first place and not rejecting it. There are many ways to fight this, much of which will come down to what your policies are regarding rejecting mail, false positives, etc. You could always turn off the ability of your users to forward mail to other services, problem solved. This is not an option, we are offering commercial services and users demands this feature. Gmail offers POP3 retrieval, which is a perfectly servicable option if users DEMAND every spam message, plus forwarding. Blocking emails based on spam filters are always wrong. Spam recognition will NEVER be 100%, there are always false positives. We are accepting all emails and filter them after. I just need to tell Postfix to NOT forward particular messages and only deliver them locally (for example, as mentioned before, based on headers). Has it occurred to you that the reason lots of your users enable forwarding to Gmail may be the fact that you accept everything? And that they are essentially using Gmail as the spam filter they need because of this? No, we have our own spam filters but they are NOT rejecting e-mails, only putting them in Spam folder. There are no complains about spam from users at all. You are creating this problem yourself. No spam filtering is 100% without false positives, but properly configured before-queue defenses generally cut out ~90% of the garbage you get from bots and zombies. Or more, depending on how tight of a ship you can afford to run. It also presents a traceable error path to any senders that may be caught with their pants down because of configuration issues, compromised systems and what have you. We are, of course, not accepting every garbage: smtpd_sender_restrictions = reject_non_fqdn_sender reject_unknown_sender_domain I just meant that we are not rejecting e-mails based on spam filters. This means that anything that actually reaches the stage where you decide whether to store or forward is about 10% of what you are accepting now, and much less likely to cause trouble with forwarding. If you must do your own thing, figure out how to use the quarantine features of your chosen content filtering software, and do forwarding from there based on rules you specify. Or dig into the Postfix documentation and figure out how you might achieve what you are after without backscattering, or discarding mail. We are not backscatters, our systems are configured correctly. One note to all fans of 'spam filters rejecting' here: Did you even notice that NO ONE of big e-mail providers are rejecting messages based on standard spam filter techniques? Google, Yahoo, Microsoft, ATT, ... No one is doing it, most of them have developed their own filtering systems and you must be really big spammer to be blocked permanently. The best of them is Google, just try their filters and you will see (even blocking which was used to us was targeted only to particular messages).
Re: Do not forward spam
On Sep 20, 2013, at 18:21, azurIt azu...@pobox.sk wrote: CC: postfix-users@postfix.org On Fri, Sep 20, 2013 at 10:42 AM, azurIt azu...@pobox.sk wrote: Hi, i'm having problems with spam forwarding - lot's of our users enabled forwarding to gmail and every spam they receive is also forwarded. Today gmail block us because of spam (which we were just forwarding, not sending). Any tips how can i disable forwarding in case of a spam (for example, when message has X-Spam-Status: Yes) ? Thanks. azur As a first line of defence, maybe use postscreen to cut down the spam before it reaches smtpd ? The postscreen documentation (http://www.postfix.org/POSTSCREEN_README.html) mentions four layers of defence, if you have some of that implemented, or all of it, you would be able to cut down on your incoming spam, before anything gets forwarded to Google or any other place. Looks fine but i NEED to deliver also spams locally, i just don't want to forward them away. No one 'needs' to deliver spam locally. On a properly configured system, the vast majority of spam bounces off the before-queue defenses, and never reaches the stage where a decision about forwarding or local storage needs to be made. If you are running into trouble with Gmail it is quite likely that you are accepting too much garbage from bots and zombies. This is a problem you should solve at the earliest possible stage, which is where postscreen comes in. Read the documentation again, and understand why it should be part of your defenses. If you think your problem can be solved using header checks, read the appropriate documentation; http://www.postfix.org/header_checks.5.html But really, start by cutting down on what you accept. Mvg, Joni
Re: Do not forward spam
Am 20.09.2013 22:03, schrieb azurIt: One note to all fans of 'spam filters rejecting' here: Did you even notice that NO ONE of big e-mail providers are rejecting messages based on standard spam filter techniques? Google, Yahoo, Microsoft, ATT, ... No one is doing it, most of them have developed their own filtering systems and you must be really big spammer to be blocked permanently. The best of them is Google, just try their filters and you will see (even blocking which was used to us was targeted only to particular messages) that must be why you started this with Today gmail block us because of spam (which we were just forwarding, not sending) :-) Please read my whole message. Thank you.
Re: Do not forward spam
Hello Azur, On 9/20/2013 12:45 PM, DTNX Postmaster wrote: Has it occurred to you that the reason lots of your users enable forwarding to Gmail may be the fact that you accept everything? And that they are essentially using Gmail as the spam filter they need because of this? Joni makes a very salient point here, and others made the same point as well. I can understand your false positive philosophy, but I don't agree with it, and neither does any other respectable mail OP today. This philosophy may have worked in the mid 1990s when spam volumes were low and merely an annoyance. But the situation on the ground of the battlefield in 2013 makes this untenable. The spam volume has increased over 1000 fold and is actively wrecking infrastructures when left unchecked. Thus, taking your currently flawed philosophy into account, *at bare minimum* you need to stop accepting spam from malware infected PCs into your queue. You can safely reject nearly all of this bot spam at smtp connect using Postscreen and similar methods. These look at the client sending the spam, not the content. Thus the FP rate is zero--nobody requests email from a spam bot. Nobody gives explicit opt-in permission for a bot network operator to send them email. Remember, spam is defined by consent, not content. Spambots are never given consent. Block them. Rejecting bots at connect should eliminate 80-90% of your inbound spam volume. Other than putting a huge dent in the forwarding problem, this will also: 1. Decrease network bandwidth consumed after connect 2. Decrease network bandwidth consumed during forwarding 3. Decrease disk space consumed by all the spam you're currently accepting 4. Cut down dramatically on CPU cycles currently burned analyzing all emails for spam 5. Generally reduce the physical hardware infrastructure required to support your user load 6. Dramatically increase the number of email users you can support with your current hardware infrastructure As you can see, there are many critical advantages to rejecting the low hanging fruit bot spam sources, without causing false positives. Frankly, if I was your employer I'd have fired you already for not having implemented measures to block bot spam, simply because of the financial burden it places on me due to the extra infrastructure required to ingest, forward, store it, etc. Others here likely share this sentiment. Ingesting all bot spam, all spam, will eventually bankrupt you. You cannot be profitable running a commercial email operation if you're ingesting all the spam. Either the infrastructure costs will eat all your profits, or, more likely, you will eventually lose your customers. On 9/20/2013 12:45 PM, Kris Deugau wrote: To more directly answer your original question, it would help if you posted an overview of your mail flow. It sounds like your forwarding is done via alias rather than .forward or some similar processing on final local delivery; choosing a different place for your forwarding may help cut the volume of forwarded spam. A commercial email service should never configure per user forwarding at the MTA level. This is why Sieve, procmail, etc exist, to allow users to configure this themselves at the MDA level. Here, any forwarded email is resubmitted to the MTA. As someone else pointed out, you have an easier trail to follow if there is a problem with a specific user and forwarding. It also allows you, the administrator, to implement site wide MDA delivery rules that override individual user rules. In this case, you'd create an MDA rule that delivers any message with an appropriate SPAM tag in the header to a user's local SPAM folder. If the user creates a forward rule it will not forward the spam. Yes, you have work ahead of you to rearchitect this correctly. But this is how it should have been done in the first place. If you need additional assistance, the first thing you need to do is tell us which MDA you're using. Procmail, Maildrop, Dovecot LDA, etc. -- Stan
Re: Do not forward spam
On Sep 20, 2013, at 22:03, azurIt azu...@pobox.sk wrote: You are creating this problem yourself. No spam filtering is 100% without false positives, but properly configured before-queue defenses generally cut out ~90% of the garbage you get from bots and zombies. Or more, depending on how tight of a ship you can afford to run. It also presents a traceable error path to any senders that may be caught with their pants down because of configuration issues, compromised systems and what have you. We are, of course, not accepting every garbage: smtpd_sender_restrictions = reject_non_fqdn_sender reject_unknown_sender_domain I just meant that we are not rejecting e-mails based on spam filters. Which is exactly what the various suggestions were about. About rejecting incoming connections based on the connection profile and the envelope, before a message is queued. In other words, no one is suggesting rejecting a message based on its content, we are suggesting that you can cut down the amount of spam you need to make a store or forward decision on tremendously, by raising the bar on what you accept in the first place. The very first reply you got, from Robert Schetterer, already made the distinction between rejection and filtering, by the way. And if the 'smtpd_sender_restrictions' you list above is your idea of not accepting garbage, there is quite a bit of room for improvement. This means that anything that actually reaches the stage where you decide whether to store or forward is about 10% of what you are accepting now, and much less likely to cause trouble with forwarding. If you must do your own thing, figure out how to use the quarantine features of your chosen content filtering software, and do forwarding from there based on rules you specify. Or dig into the Postfix documentation and figure out how you might achieve what you are after without backscattering, or discarding mail. We are not backscatters, our systems are configured correctly. Nowhere am I suggesting that you are. I am noting it as a risk that one needs to be aware of. Did you notice your original question was answered there, by the way? It is one of several answers you got before you sent this message. One note to all fans of 'spam filters rejecting' here: Did you even notice that NO ONE of big e-mail providers are rejecting messages based on standard spam filter techniques? Google, Yahoo, Microsoft, ATT, ... No one is doing it, most of them have developed their own filtering systems and you must be really big spammer to be blocked permanently. The best of them is Google, just try their filters and you will see (even blocking which was used to us was targeted only to particular messages). Ahh, now you reveal that you are not being blocked, but that they are rejecting some (but not all!) messages based on their local rules. In other words, your original problem description is incomplete at best, and hints at a different class of problem; being blocked by Gmail. You should therefore not be surprised that the suggestions and answers you get focus on that much bigger problem of no messages being accepted at all. And please, you don't think you are the only one here who deals with forwarding to the big gorillas in the game, do you? To get the most value from this list and others like it, assume that most of the problems you run into have already been solved in various ways, for a wide variety of setups and scenarios. Perhaps your own solution is not the best option. Perhaps your view of the problem is incomplete, or perhaps you are misunderstanding the problem completely. And just in case that the issues you are having do present a novel problem, always be as descriptive as possible. That you are doing forwards with 'virtual_alias_maps' at the moment should really have been part of your original post, for example. Better questions tend to get much better answers, with less noise for everyone. Mvg, Joni
