You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Chandran Manikandan <te...@gmail.com> on 2016/02/04 10:47:18 UTC
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.rr@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
Posted by Alan Hodgson <ah...@lists.simkin.ca>.
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
Posted by David B Funk <db...@engineering.uiowa.edu>.
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
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: how to fix this issue-spam
Posted by David Jones <dj...@ena.com>.
>>SPF strict outright breaks mail forwarding, unless the forwarder rewrites the
>>envelope sender.
>SPF does NOT break mail forwarding (and is not obsolete, as you claim in
>later mail)
Until most MTAs support SRS easily and possibly by default, SPF is going
to be broken by forwarding. You are correct that it's technically not a problem
with SPF but nevertheless it's a reality today on nearly all MTAs and
mail platforms.
Re: how to fix this issue-spam
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 04.02.16 09:30, Alan Hodgson wrote:
>SPF strict outright breaks mail forwarding, unless the forwarder rewrites the
>envelope sender.
SPF does NOT break mail forwarding (and is not obsolete, as you claim in
later mail)
Forwarding without rewriting envelope sender is what's broken there.
It causes issues like misdirected bounces to the originator, not to the
forwarder.
>DKIM + DMARC is a much better compromise. It allows properly-signed mail
>forwarded intact to still pass DMARC checks.
DKIM required DATA phase to complete, while SPF can be rejected prior it.
DKIM has its issues, related to charater set conversion that may be
ligitimately done by servers.
--
Matus UHLAR - fantomas, uhlar@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.
Linux - It's now safe to turn on your computer.
Linux - Teraz mozete pocitac bez obav zapnut.
Re: how to fix this issue-spam
Posted by Benny Pedersen <me...@junc.eu>.
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
Posted by Reindl Harald <h....@thelounge.net>.
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
Re: how to fix this issue-spam
Posted by Alan Hodgson <ah...@lists.simkin.ca>.
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
Posted by Alan Hodgson <ah...@lists.simkin.ca>.
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
Posted by Reindl Harald <h....@thelounge.net>.
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
Re: how to fix this issue-spam
Posted by Reindl Harald <h....@thelounge.net>.
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
Re: how to fix this issue-spam
Posted by Alan Hodgson <ah...@lists.simkin.ca>.
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
Posted by Reindl Harald <h....@thelounge.net>.
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
Re: how to fix this issue-spam
Posted by David Jones <dj...@ena.com>.
>> 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
Posted by Reindl Harald <h....@thelounge.net>.
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"
Re: how to fix this issue-spam
Posted by David Jones <dj...@ena.com>.
>* 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
Posted by Reindl Harald <h....@thelounge.net>.
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
Re: how to fix this issue-spam
Posted by David Jones <dj...@ena.com>.
>> 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
Posted by Reindl Harald <h....@thelounge.net>.
Am 04.02.2016 um 20:43 schrieb Benny Pedersen:
> please dont reply since i ignore your ignorances
then SHUT UP if you don't want a response!
Re: how to fix this issue-spam
Posted by Benny Pedersen <me...@junc.eu>.
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
Re: how to fix this issue-spam
Posted by Reindl Harald <h....@thelounge.net>.
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?
Re: how to fix this issue-spam
Posted by David Jones <dj...@ena.com>.
>>>> 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:email@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
Posted by Reindl Harald <h....@thelounge.net>.
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 Stone <An...@spamassassin.open.source.it>
>> 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.
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
Re: how to fix this issue-spam
Posted by Benny Pedersen <me...@junc.eu>.
On 2016-02-04 11:04, Antony Stone wrote:
>> From: Antony Stone <An...@spamassassin.open.source.it>
>> 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.
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
Posted by Antony Stone <An...@spamassassin.open.source.it>.
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 <An...@spamassassin.open.source.it>
> 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
Posted by Reindl Harald <h....@thelounge.net>.
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 <An...@spamassassin.open.source.it>
To: 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
Re: how to fix this issue-spam
Posted by Antony Stone <An...@spamassassin.open.source.it>.
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.rr@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.