Re: how to fix this issue-spam
Am 04.02.2016 um 10:55 schrieb Antony Stone: On Thursday 04 February 2016 at 10:47:18, Chandran Manikandan wrote: 1. Our users received some spam emails which is showing our domain email account in From address. Nothing unusual in that - forged From addresses have been common for many years. like the mail from you From: Antony StoneTo: users@spamassassin.apache.org Are you using DKIM / SPF for your domain? I mean, why do you accept email apparently from your own domain when it does not come from one of your authorised servers? because the From header has nothing to do with the envelope sender and so not with SPF and spoofing protections signature.asc Description: OpenPGP digital signature
how to fix this issue-spam
Hi friends, I need some help from you. could you go through my below issue and help me to fix . 1. Our users received some spam emails which is showing our domain email account in From address. But those email account don't have mailbox in my server. 2. Second thing is some emails send spam emails in showing from address is our server mailbox. but i have check to click reply showing different email address and domains this reply...@mail.com How to fix those above two issues on my server. I am running Centos 6.6 64 bit server with spamdyke and spamassassin packages. My simcontrol rule is below. :clam=yes,spam=yes,spam_hits=12,attach=.mp3:.src:.bat:.pif:.exe:.chm:.com:.dll:.dot:.email:.hlp:.hta:.inf:.msi:.reg:.scr:.url:.vbs:.mpeg:.zip:.7z If i change spamhits = 5 or less spam emails are blocked but we cannot receive emails from our same domains Could you anyone of you provide solution to fix for me. Appreciate anyone help me to fix this. -- *Thanks,* *Manikandan.C* *System Administrator*
Re: how to fix this issue-spam
On Thursday 04 February 2016 at 10:58:42, Reindl Harald wrote: > Am 04.02.2016 um 10:55 schrieb Antony Stone: > > On Thursday 04 February 2016 at 10:47:18, Chandran Manikandan wrote: > >> 1. Our users received some spam emails which is showing our domain email > >> account in From address. > > > > Nothing unusual in that - forged From addresses have been common for many > > years. > > like the mail from you > > From: Antony Stone> To: users@spamassassin.apache.org Um, that's not a forged From address. I own the domain source.it and spamassassin.open.source.it is a valid subdomain of that. > > Are you using DKIM / SPF for your domain? I mean, why do you accept > > email apparently from your own domain when it does not come from one of > > your authorised servers? > > because the From header has nothing to do with the envelope sender and > so not with SPF and spoofing protections True, but given that the original poster said nothing about the envelope sender, we don't know what that is. I'd be prepared to bet that implementing this would improve his server's operation, though. Antony. -- Most people are aware that the Universe is big. - Paul Davies, Professor of Theoretical Physics Please reply to the list; please *don't* CC me.
Re: how to fix this issue-spam
Am 04.02.2016 um 11:04 schrieb Antony Stone: On Thursday 04 February 2016 at 10:58:42, Reindl Harald wrote: Am 04.02.2016 um 10:55 schrieb Antony Stone: On Thursday 04 February 2016 at 10:47:18, Chandran Manikandan wrote: 1. Our users received some spam emails which is showing our domain email account in From address. Nothing unusual in that - forged From addresses have been common for many years. like the mail from you From: Antony StoneTo: users@spamassassin.apache.org Um, that's not a forged From address. I own the domain source.it and spamassassin.open.source.it is a valid subdomain of that. technically *it is* the envelope sender is @spamassassin.apache.org, the message comes not from your server, but it has your "From" header and so the point is you CAN NOT distinct between a maling-list or a forged From-Header because technically it's the same and yes it passes SPF - for the @spamassassin.apache.org envelope Are you using DKIM / SPF for your domain? I mean, why do you accept email apparently from your own domain when it does not come from one of your authorised servers? because the From header has nothing to do with the envelope sender and so not with SPF and spoofing protections True, but given that the original poster said nothing about the envelope sender, we don't know what that is. I'd be prepared to bet that implementing this would improve his server's operation, though. but he talks about From-Headers Barracuda Networks was stupid enough to extend their spoofing protection after years to From-Headers and not only envelopes resulting in ruin mailing-lists by block your own messages because "customers complained that they still get spam where the MUA shows their own domain as sender" result: disable the next filter on the appliance to stop harmful behavior signature.asc Description: OpenPGP digital signature
Re: how to fix this issue-spam
On Thursday 04 February 2016 at 10:47:18, Chandran Manikandan wrote: > 1. Our users received some spam emails which is showing our domain email > account in From address. Nothing unusual in that - forged From addresses have been common for many years. > But those email account don't have mailbox in my server. Okay, so they're randomly made up, rather than copied from real emails which have been seen. Again, nothing too unusual about that. Are you using DKIM / SPF for your domain? I mean, why do you accept email apparently from your own domain when it does not come from one of your authorised servers? > 2. Second thing is some emails send spam emails in showing from address is > our server mailbox. > but i have check to click reply showing different email address and domains > this reply...@mail.com So, the "From" header doesn't match the "Reply-To" header. Not so unusual. > How to fix those above two issues on my server. Don't accept emails from domains with SPF / DKIM unless they come from authorised servers, and set up SPF / DKIM for your domain. Antony. -- "The problem with television is that the people must sit and keep their eyes glued on a screen; the average American family hasn't time for it." - New York Times, following a demonstration at the 1939 World's Fair. Please reply to the list; please *don't* CC me.
Re: [Announce] SA-Plugins: RedisAWL, RuleTimingRedis
On 16/07/2015 19:58, Benning, Markus wrote: > Hi Patrik, > > i just pushed Version 1.002 to github and CPAN: > > -- > The following new features have been added: > > - New option: timing_redis_password allows to specifiy a redis password Sorry to reply to an old thread, but is it possible for the the RedisAWL plugin to specify a redis password too? (I'm looking to use TxRep with a redis backend...) Thanks. s.
Re: how to fix this issue-spam
Are you using DKIM / SPF for your domain? I mean, why do you accept email apparently from your own domain when it does not come from one of your authorised servers? >>> >>> because the From header has nothing to do with the envelope sender and >>> so not with SPF and spoofing protections >> >> True, but given that the original poster said nothing about the envelope >> sender, we don't know what that is. I'd be prepared to bet that implementing >> this would improve his server's operation, though. >but he talks about From-Headers Yes. Based on his original email where it was "showing" the From address, that would imply the From: visible in the mail client or webmail interface. This spoofing can be blocked with a DMARC DNS record. DMARC is a combination of SPF and DKIM plus From: header spoofing check. You must get SPF and DKIM setup before adding the '_dmarc' DNS record for the sending domain. DMARC (the '_dmarc' DNS record) = visible From: header check SPF = envelope-from header check DKIM = authentication of sending mail servers using signing https://dmarc.org/wiki/FAQ#What_type_of_illegitimate_email_does_DMARC_address.3F DMARC is very powerful and very complicated to setup but worth it. One of the best features of DMARC is the reporting so you can see if your own servers are setup properly and see how many other bad servers are spoofing your domain every day. Reporting can be setup very easily and is a good starting place with no risk. _dmarc.example.com IN TXT "v=DMARC1; p=none; rua=mailto:em...@example.com; Setup the above DNS record for your domain and wait for the XML reports to start coming in. I setup a script to POP the email from my report mailbox and import the XML into a database for a basic web page report. You can also us https://dmarcian.com/dmarc-xml/.
Re: how to fix this issue-spam
Am 04.02.2016 um 16:20 schrieb David Jones: Are you using DKIM / SPF for your domain? I mean, why do you accept email apparently from your own domain when it does not come from one of your authorised servers? because the From header has nothing to do with the envelope sender and so not with SPF and spoofing protections True, but given that the original poster said nothing about the envelope sender, we don't know what that is. I'd be prepared to bet that implementing this would improve his server's operation, though. but he talks about From-Headers Yes. Based on his original email where it was "showing" the From address, that would imply the From: visible in the mail client or webmail interface. This spoofing can be blocked with a DMARC DNS record. DMARC is a combination of SPF and DKIM plus From: header spoofing check. You must get SPF and DKIM setup before adding the '_dmarc' DNS record for the sending domain tell me something new wait i tell you something (for you) new: DMARC and mailing-lists is a awful topic - what do you think would have happened with you mail to the list if your domain would enforce DMARC and my MX reject mails violating the policy? signature.asc Description: OpenPGP digital signature
Re: how to fix this issue-spam
On Thursday, February 04, 2016 08:05:59 PM Reindl Harald wrote: > in context of "DKIM and DMARC are the present and near future" how do > you imaine that to work if you have no clue who is sending on behalf of > yours? > Well you obviously have something emotionally invested in SPF. But anyways DMARC explicitly has a full testing mode and a reporting feedback cycle - which actually works and is supported by some big mail receivers - so you can work through these issues during deployment.
Re: how to fix this issue-spam
On 2016-02-04 11:04, Antony Stone wrote: From: Antony StoneTo: users@spamassassin.apache.org Um, that's not a forged From address. I own the domain source.it and spamassassin.open.source.it is a valid subdomain of that. https://dmarcian.com/spf-survey/spamassassin.open.source.it https://dmarcian.com/dmarc-inspector/spamassassin.open.source.it untrusted if you make it trusted, you will benefit from it aswell with local rules
Re: how to fix this issue-spam
Am 04.02.2016 um 17:38 schrieb David Jones: * you did not provide a hint to the list-problem * to "solve" the OP's problem DMARC is not needed Mail admins need to get familiar with DMARC because major ISPs have begun to take this seriously in the past year and are starting to reject or put into spam folders when this is setup incorrectly or missing. Many mail servers trust inbound email better (not whitelist) when SPF and DKIM checks pass. Google is telling all of their mail customers to add DMARC DNS records to block spoofing of their own domains before Google ist telling somebody something they should better learn the difference between "~" and "-" in a SPF record to make gmail.com at least on envelope-level spoofing protected i high percentage of spam here would not only have been flagged but outright rejected if they would do their own homework ;; ANSWER SECTION: gmail.com. 300 IN TXT "v=spf1 redirect=_spf.google.com" ;; ANSWER SECTION: _spf.google.com.300 IN TXT "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all" signature.asc Description: OpenPGP digital signature
Re: how to fix this issue-spam
On Thu, 4 Feb 2016, Reindl Harald wrote: DMARC is a combination of SPF and DKIM plus From: header spoofing check. You must get SPF and DKIM setup before adding the '_dmarc' DNS record for the sending domain tell me something new wait i tell you something (for you) new: DMARC and mailing-lists is a awful topic - what do you think would have happened with you mail to the list if your domain would enforce DMARC and my MX reject mails violating the policy? It's true that forwarding/maillists mangle SPF however unless the list does the idiocy of subject munging (pre-pending '[list-name]' to the subject) DKIM should pass thru lists unscathed. So if your DMARC policiy is to accept on SPF -or- DKIM success then you should have no worries. If you demand SPF -and- DKIM then good luck to you. -- Dave Funk University of Iowa College of Engineering 319/335-5751 FAX: 319/384-0549 1256 Seamans Center Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527 #include Better is not better, 'standard' is better. B{
Re: how to fix this issue-spam
On Thursday, February 04, 2016 06:06:14 PM Reindl Harald wrote: > before Google ist telling somebody something they should better learn > the difference between "~" and "-" in a SPF record to make gmail.com at > least on envelope-level spoofing protected > > i high percentage of spam here would not only have been flagged but > outright rejected if they would do their own homework > > ;; ANSWER SECTION: > gmail.com. 300 IN TXT "v=spf1 > redirect=_spf.google.com" > > ;; ANSWER SECTION: > _spf.google.com.300 IN TXT "v=spf1 > include:_netblocks.google.com include:_netblocks2.google.com > include:_netblocks3.google.com ~all" SPF strict outright breaks mail forwarding, unless the forwarder rewrites the envelope sender. DKIM + DMARC is a much better compromise. It allows properly-signed mail forwarded intact to still pass DMARC checks. The only significant forwarders that break DMARC are mailing lists, because they tend to change headers (especially subject lines) and add content to the message body, both of which break the DKIM signatures. Ironically, they also rewrite the envelope sender, so they didn't notice how broken SPF by itself was. Mailing lists will need to learn to either not modify the message being forwarded, or else both rewrite the From: header and preferably remove any now-broken DKIM signatures. Or just refuse mail from DMARC-reject senders, which will eventually marginalize their use. Neither mechanism is perfect, but I think everyone can agree that email needs to adapt to remain useful in a world full of criminals. And even more importantly, it does seem that DMARC-reject is gaining traction among big mail receivers.
Re: how to fix this issue-spam
>* you did not provide a hint to the list-problem >* to "solve" the OP's problem DMARC is not needed Mail admins need to get familiar with DMARC because major ISPs have begun to take this seriously in the past year and are starting to reject or put into spam folders when this is setup incorrectly or missing. Many mail servers trust inbound email better (not whitelist) when SPF and DKIM checks pass. Google is telling all of their mail customers to add DMARC DNS records to block spoofing of their own domains. Whether or not you agree with this Google recommendation, it's coming. I know this will cause problems with legit 3rd party senders and mailing lists. Many 3rd party senders are figuring out the proper way to send email. Something is going to have to be done on mailing lists or everyone will have to keep whitelisting them manually which is not a good long-term solution. https://blog.returnpath.com/how-to-explain-dmarc-in-plain-english/ https://support.sendgrid.com/hc/en-us/articles/200182958-Everything-about-DMARC- >you can simply reject based on the from header anything pretending it's >you own domain from foreign servers - no need for DKIM/DMARC/SPF - and >on the MTA level but there are not only mailing-lists - not everyone can block their own domain at the MTA level but they can setup DKIM/DMARC/SPF - this does not cover bad senders spoofing your domain to other mail servers not under your control.
Re: how to fix this issue-spam
Am 04.02.2016 um 16:49 schrieb David Jones: DMARC is a combination of SPF and DKIM plus From: header spoofing check. You must get SPF and DKIM setup before adding the '_dmarc' DNS record for the sending domain tell me something new This email was not just for you. If you already knew this, then ignore it. wait i tell you something (for you) new: DMARC and mailing-lists is a awful topic - what do you think would have happened with you mail to the list if your domain would enforce DMARC and my MX reject mails violating the policy? I knew that too but I am not going to go down to your level and make an inappropriate comment like you did. You are a smart guy so you would know to setup a different email address to use with mailing lists that didn't have DMARC reject policy sorry, but that makes no sense * you did not provide a hint to the list-problem * to "solve" the OP's problem DMARC is not needed you can simply reject based on the from header anything pretending it's you own domain from foreign servers - no need for DKIM/DMARC/SPF - and on the MTA level but there are not only mailing-lists signature.asc Description: OpenPGP digital signature
Re: how to fix this issue-spam
>> DMARC is a combination of SPF and DKIM plus From: header spoofing check. >> You must get SPF and DKIM setup before adding the '_dmarc' DNS record for >> the sending domain >tell me something new This email was not just for you. If you already knew this, then ignore it. >wait i tell you something (for you) new: DMARC and mailing-lists is a >awful topic - what do you think would have happened with you mail to the >list if your domain would enforce DMARC and my MX reject mails violating >the policy? I knew that too but I am not going to go down to your level and make an inappropriate comment like you did. You are a smart guy so you would know to setup a different email address to use with mailing lists that didn't have DMARC reject policy.
Re: how to fix this issue-spam
Am 04.02.2016 um 18:30 schrieb Alan Hodgson: On Thursday, February 04, 2016 06:06:14 PM Reindl Harald wrote: before Google ist telling somebody something they should better learn the difference between "~" and "-" in a SPF record to make gmail.com at least on envelope-level spoofing protected i high percentage of spam here would not only have been flagged but outright rejected if they would do their own homework ;; ANSWER SECTION: gmail.com. 300 IN TXT "v=spf1 redirect=_spf.google.com" ;; ANSWER SECTION: _spf.google.com.300 IN TXT "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all" SPF strict outright breaks mail forwarding, unless the forwarder rewrites the envelope sender since https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme and gmail it self implements SRS fot their own forwardings that is no excuse it would possibly reduce the amount of people forwarding their mails from a 10 years old freemail account to a differnt freemail provider with a 5 year old address and from there to their personal domain with the result of procude backscatters all over the world and make a lot of "last-external" rules useless signature.asc Description: OpenPGP digital signature
Re: how to fix this issue-spam
On Thursday, February 04, 2016 04:36:14 PM Reindl Harald wrote: > > wait i tell you something (for you) new: DMARC and mailing-lists is a > awful topic - what do you think would have happened with you mail to the > list if your domain would enforce DMARC and my MX reject mails violating > the policy? Actually, it appears this list is one of the rare ones that would be fine with DMARC reject, since it doesn't break existing DKIM signatures.
Re: how to fix this issue-spam
On Thursday, February 04, 2016 07:41:44 PM Reindl Harald wrote: > which people don't know this? > admins? > don't maintain services then! > > users? > > just use the SMTP server your mailprovider tells you and no other one > and for smtp-admins: just don't accept enevlope senders for which you > would not accept incoming mail > > that is as easy as something can be > Yeah, it's really really not. I'm in a 50 person company and we have our internal mail server, 3 different ESPs sending mail on our behalf for diffferent applications, Google calendar sending on our behalf, and 2 different SAAS customer service platforms sending as us. I can't even imagine how many different sources a large company has. And SPF doesn't do anything about the only part of the message the users care about, the message headers. In any event, SPF is legacy. DKIM and DMARC are the present and near future of mail services. DMARC uses SPF only as a fallback for broken or missing DKIM signatures.
Re: how to fix this issue-spam
Am 04.02.2016 um 19:51 schrieb Alan Hodgson: On Thursday, February 04, 2016 07:41:44 PM Reindl Harald wrote: which people don't know this? admins? don't maintain services then! users? just use the SMTP server your mailprovider tells you and no other one and for smtp-admins: just don't accept enevlope senders for which you would not accept incoming mail that is as easy as something can be Yeah, it's really really not. it is I'm in a 50 person company and we have our internal mail server, 3 different ESPs sending mail on our behalf for diffferent applications, Google calendar sending on our behalf, and 2 different SAAS customer service platforms sending as us. I can't even imagine how many different sources a large company has. normally all that "on our behalf" are using their own envelope and the From-Header, this applies to Google and all legit mass-senders if it's not mass-senders nothing easier than tell a MTA to relay over the correct MTA including authentication, that's what we do for many years when we send "on behalf" of a customer not hosting mail on our infrastructure And SPF doesn't do anything about the only part of the message the users care about, the message headers. different story but "~" is for TESTING and if i don't intend to *really* use SPF i don't start with it and if i don't grok that difference at least i do not demand from others how they have to setup their mail domains In any event, SPF is legacy. DKIM and DMARC are the present and near future of mail services. DMARC uses SPF only as a fallback for broken or missing DKIM signatures DKIM is way to fargile at all - guess why SpamAssasin just uses T_DKIM_INVALID instead of DKIM_INVALID - because it randomly failed for untouched legit mail, Google for other parts of mailsystems then SA which has and have the same issues and the come back and talk about the future signature.asc Description: OpenPGP digital signature
Re: how to fix this issue-spam
Am 04.02.2016 um 20:00 schrieb Reindl Harald: Am 04.02.2016 um 19:51 schrieb Alan Hodgson: On Thursday, February 04, 2016 07:41:44 PM Reindl Harald wrote: which people don't know this? admins? don't maintain services then! users? just use the SMTP server your mailprovider tells you and no other one and for smtp-admins: just don't accept enevlope senders for which you would not accept incoming mail that is as easy as something can be Yeah, it's really really not. it is I'm in a 50 person company and we have our internal mail server, 3 different ESPs sending mail on our behalf for diffferent applications, Google calendar sending on our behalf, and 2 different SAAS customer service platforms sending as us. I can't even imagine how many different sources a large company has. normally all that "on our behalf" are using their own envelope and the From-Header, this applies to Google and all legit mass-senders if it's not mass-senders nothing easier than tell a MTA to relay over the correct MTA including authentication, that's what we do for many years when we send "on behalf" of a customer not hosting mail on our infrastructure in context of "DKIM and DMARC are the present and near future" how do you imaine that to work if you have no clue who is sending on behalf of yours? if you are able to coordinate the correct usage of DKIM with all of them than you can also set a correct SPF (in case they are not using their own envelope for whatever reason) so, no, your complete picture don't match and si just a weak excuse And SPF doesn't do anything about the only part of the message the users care about, the message headers. different story but "~" is for TESTING and if i don't intend to *really* use SPF i don't start with it and if i don't grok that difference at least i do not demand from others how they have to setup their mail domains In any event, SPF is legacy. DKIM and DMARC are the present and near future of mail services. DMARC uses SPF only as a fallback for broken or missing DKIM signatures DKIM is way to fargile at all - guess why SpamAssasin just uses T_DKIM_INVALID instead of DKIM_INVALID - because it randomly failed for untouched legit mail, Google for other parts of mailsystems then SA which has and have the same issues and the come back and talk about the future signature.asc Description: OpenPGP digital signature
Re: how to fix this issue-spam
>> Google is telling all of their mail customers to add DMARC DNS records to >> block >> spoofing of their own domains >before Google ist telling somebody something they should better learn >the difference between "~" and "-" in a SPF record to make gmail.com at >least on envelope-level spoofing protected >i high percentage of spam here would not only have been flagged but >outright rejected if they would do their own homework You must not understand why Google promotes the ~all over the -all. The problem is most people don't know all of the legit sources of email for their domain so it's dangerous to use -all if you aren't 100 percent sure that all of your senders are covered in your SPF record. For Google and myself, it's better to tell everyone to use ~all and SOFT FAIL the SPF check to put the message into the Spam folder than to have mail bounced. The ~all is also the best way currently to handle the forwarding problem mentioned by Alan Hodgson. SRS has it's own problems.
Re: how to fix this issue-spam
Am 04.02.2016 um 19:17 schrieb David Jones: Google is telling all of their mail customers to add DMARC DNS records to block spoofing of their own domains before Google ist telling somebody something they should better learn the difference between "~" and "-" in a SPF record to make gmail.com at least on envelope-level spoofing protected i high percentage of spam here would not only have been flagged but outright rejected if they would do their own homework You must not understand why Google promotes the ~all over the -all. The problem is most people don't know all of the legit sources of email for their domain so it's dangerous to use -all if you aren't 100 percent sure that all of your senders are covered in your SPF record. which people don't know this? admins? don't maintain services then! users? just use the SMTP server your mailprovider tells you and no other one and for smtp-admins: just don't accept enevlope senders for which you would not accept incoming mail that is as easy as something can be For Google and myself, it's better to tell everyone to use ~all and SOFT FAIL the SPF check to put the message into the Spam folder than to have mail bounced. The ~all is also the best way currently to handle the forwarding problem mentioned by Alan Hodgson. SRS has it's own problems oh yeah a great way to not realize why some mails don't reach senders and others pass through instead get a clear SPF reject and learn which is your submission servers score SPF_SOFTFAIL 0 0.972 0 0.665 signature.asc Description: OpenPGP digital signature
Re: how to fix this issue-spam
On 2016-02-04 18:30, Alan Hodgson wrote: SPF strict outright breaks mail forwarding, unless the forwarder rewrites the envelope sender. nope, i want NOT to use my envelope sender from apache org, wake up
Re: how to fix this issue-spam
On 2016-02-04 16:36, Reindl Harald wrote: wait i tell you something (for you) new: DMARC and mailing-lists is a awful topic - what do you think would have happened with you mail to the list if your domain would enforce DMARC and my MX reject mails violating the policy? mailllist that breaks dkim would loose users from domains that enforce dmarc reject, try use yahoo sender domains to eg opendmarc maillist, funny this maillist breaks dkim, and all users say or think maillist does not work with dmarc reject, silly maillists running dkim fixes is bad like hell on this issues the dmarc maillist solved it with take over owner ships of from header, so thay ignore there own problem braking dkim signed mails on top of that libspf2 needs updates to latest spf rfc, and client software using libspf2 would have to make sure not to test sender-id hopefully maillist owners wake up some day postfix maillist does not break dkim, so dmarc policy reject does not reject mails from maillist there and this maillist here i see dmarc pass please dont reply since i ignore your ignorances