smtpd_sender_restriction

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

smtpd_sender_restriction

Martin Skjöldebrand
Hi,

I was under the impression that

smtpd_sender_restrictions=check_sender_access
hash:/etc/postfix/sender_access

would take a list of domain and either reject or discard the message on
reaching the server, based on the content of the file
/etc/postfix/sender_access. Maybe I am totally confused about this?
In my main.cf it seems not to have the desired effect.
Anyone able to shed some light on my meager understandings of postfix.

/Martin S
Reply | Threaded
Open this post in threaded view
|

Re: smtpd_sender_restriction

Dominic Raferd
On 28 December 2016 at 09:06, Martin Skjöldebrand
<[hidden email]> wrote:

> Hi,
>
> I was under the impression that
>
> smtpd_sender_restrictions=check_sender_access
> hash:/etc/postfix/sender_access
>
> would take a list of domain and either reject or discard the message on
> reaching the server, based on the content of the file
> /etc/postfix/sender_access. Maybe I am totally confused about this?
> In my main.cf it seems not to have the desired effect.
> Anyone able to shed some light on my meager understandings of postfix.
>
> /Martin S

Did you rebuild the sender_access.db file with postmap
/etc/postfix/sender_access (without errors), and then postfix reload?
The sender_access file itself is not read by postfix, only the .db
file. Otherwise post here an example of your sender_access file data,
each domain (or mail address) you want to reject should be on a
separate line followed by whitespace REJECT - full info at
http://www.postfix.org/access.5.html
Reply | Threaded
Open this post in threaded view
|

Re: smtpd_sender_restriction

Martin Skjöldebrand
Yes I did, sorry I didn't mention it.

/martin s

Skickat från BlueMail
Den 28 dec. 2016, kI 11:42, Dominic Raferd <[hidden email]> skrev:
On 28 December 2016 at 09:06, Martin Skjöldebrand
<[hidden email]> wrote:
Hi,

I was under the impression that

smtpd_sender_restrictions=check_sender_access
hash:/etc/postfix/sender_access

would take a list of domain and either reject or discard the message on
reaching the server, based on the content of the file
/etc/postfix/sender_access. Maybe I am totally confused about this?
In my main.cf it seems not to have the desired effect.
Anyone able to shed some light on my meager understandings of postfix.

/Martin S

Did you rebuild the sender_access.db file with postmap
/etc/postfix/sender_access (without errors), and then postfix reload?
The sender_access file itself is not read by postfix, only the .db
file. Otherwise post here an example of your sender_access file data,
each domain (or mail address) you want to reject should be on a
separate line followed by whitespace REJECT - full info at
http://www.postfix.org/access.5.html
Reply | Threaded
Open this post in threaded view
|

Re: smtpd_sender_restriction

Martin Skjöldebrand
In reply to this post by Dominic Raferd
Den 2016-12-28 kl. 11:40, skrev Dominic Raferd:

>
> Did you rebuild the sender_access.db file with postmap
> /etc/postfix/sender_access (without errors), and then postfix reload?
> The sender_access file itself is not read by postfix, only the .db
> file. Otherwise post here an example of your sender_access file data,
> each domain (or mail address) you want to reject should be on a
> separate line followed by whitespace REJECT - full info at
> http://www.postfix.org/access.5.html
>

So what I did was I edited the sender_access file, the beginning of
which contains

# REJECT domains which *might* have legit senders (yeah very likely)
# DISCARD domains which obviously or suspected to not honouring unsub
commands

dagens-erbjudanden.com DISCARD
tailtucks.com REJECT
nyhets-torget.se DISCARD
mina-erbjudanden.se DISCARD
fantastisk2.ccemails.net DISCARD
nam-mail.com DISCARD
rabattgatan.com DISCARD

Saved it and ran postmap /etc/postfix/sender_access
which didn't present any error then did a servicectl restart postfix

This is as I understand what is needed. I haven't seen any mail from
"rabattgatan.com" in the last hour or so, but just soon after I did this
the first time I got at least two.

I do hope this is the correct procedure, else feel free to correct.

/Martin S
Reply | Threaded
Open this post in threaded view
|

Re: smtpd_sender_restriction

Dominic Raferd
On 28 December 2016 at 14:40, Martin Skjöldebrand
<[hidden email]> wrote:

> Den 2016-12-28 kl. 11:40, skrev Dominic Raferd:
>
>>
>> Did you rebuild the sender_access.db file with postmap
>> /etc/postfix/sender_access (without errors), and then postfix reload?
>> The sender_access file itself is not read by postfix, only the .db
>> file. Otherwise post here an example of your sender_access file data,
>> each domain (or mail address) you want to reject should be on a
>> separate line followed by whitespace REJECT - full info at
>> http://www.postfix.org/access.5.html
>>
>
> So what I did was I edited the sender_access file, the beginning of
> which contains
>
> # REJECT domains which *might* have legit senders (yeah very likely)
> # DISCARD domains which obviously or suspected to not honouring unsub
> commands
>
> dagens-erbjudanden.com DISCARD
> tailtucks.com REJECT
> nyhets-torget.se DISCARD
> mina-erbjudanden.se DISCARD
> fantastisk2.ccemails.net DISCARD
> nam-mail.com DISCARD
> rabattgatan.com DISCARD
>
> Saved it and ran postmap /etc/postfix/sender_access
> which didn't present any error then did a servicectl restart postfix
>
> This is as I understand what is needed. I haven't seen any mail from
> "rabattgatan.com" in the last hour or so, but just soon after I did this
> the first time I got at least two.
>

Do you have any earlier entries/values in smtp_sender_restrictions
before this line which might result in OK verdict for email from
[hidden email] (and similar) - in this case the logic will never
reach your sender_access checking.
Reply | Threaded
Open this post in threaded view
|

Re: smtpd_sender_restriction

John Fawcett
In reply to this post by Martin Skjöldebrand
On 12/28/2016 03:40 PM, Martin Skjöldebrand wrote:

> Den 2016-12-28 kl. 11:40, skrev Dominic Raferd:
>
>> Did you rebuild the sender_access.db file with postmap
>> /etc/postfix/sender_access (without errors), and then postfix reload?
>> The sender_access file itself is not read by postfix, only the .db
>> file. Otherwise post here an example of your sender_access file data,
>> each domain (or mail address) you want to reject should be on a
>> separate line followed by whitespace REJECT - full info at
>> http://www.postfix.org/access.5.html
>>
> So what I did was I edited the sender_access file, the beginning of
> which contains
>
> # REJECT domains which *might* have legit senders (yeah very likely)
> # DISCARD domains which obviously or suspected to not honouring unsub
> commands
>
> dagens-erbjudanden.com DISCARD
> tailtucks.com REJECT
> nyhets-torget.se DISCARD
> mina-erbjudanden.se DISCARD
> fantastisk2.ccemails.net DISCARD
> nam-mail.com DISCARD
> rabattgatan.com DISCARD
>
> Saved it and ran postmap /etc/postfix/sender_access
> which didn't present any error then did a servicectl restart postfix
>
> This is as I understand what is needed. I haven't seen any mail from
> "rabattgatan.com" in the last hour or so, but just soon after I did this
> the first time I got at least two.
>
> I do hope this is the correct procedure, else feel free to correct.
>
> /Martin S

Martin

you can test your map with:

postmap -q rabattgatan.com hash:/etc/postfix/sender_access

Can you show evidence, i.e. the log file entries of an email passing
through your system from the arrival to the delivery, which shows that
the map was not taken into account?

Can you post your postconf -n output?

John

Reply | Threaded
Open this post in threaded view
|

Re: smtpd_sender_restriction

Martin Skjöldebrand
Den 2016-12-28 kl. 16:56, skrev John Fawcett:

> you can test your map with:
>
> postmap -q rabattgatan.com hash:/etc/postfix/sender_access
>
> Can you show evidence, i.e. the log file entries of an email passing
> through your system from the arrival to the delivery, which shows that
> the map was not taken into account?

The output indicates it will discard the rubbish. I must've remembered
incorrectly or something. I'll spend some time later to look at the
logs. Thanks all who commented.

/Martin S

Reply | Threaded
Open this post in threaded view
|

Re: smtpd_sender_restriction

Noel Jones-2
On 12/28/2016 1:03 PM, Martin Skjöldebrand wrote:
> The output indicates it will discard the rubbish. I must've remembered
> incorrectly or something. I'll spend some time later to look at the
> logs. Thanks all who commented.

While it's very satisfying to DISCARD the rubbish, it's often
counterproductive.  It's almost always better to REJECT unwanted mail.

When you DISCARD, that means your mail server has to process the
entire message; REJECT will terminate the transaction before the
body of the email is sent, saving bandwidth and CPU, and freeing an
smptd process to accept more mail.

When you DISCARD, the sender thinks you have accepted the mail; some
bad actors take this as an invitation to send you ever increasing
amounts of junk, wasting even more of your bandwidth and CPU.


  -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: smtpd_sender_restriction

Martin Skjöldebrand
Den 2016-12-28 kl. 21:40, skrev Noel Jones:

> On 12/28/2016 1:03 PM, Martin Skjöldebrand wrote:
>> The output indicates it will discard the rubbish. I must've remembered
>> incorrectly or something. I'll spend some time later to look at the
>> logs. Thanks all who commented.
>
> While it's very satisfying to DISCARD the rubbish, it's often
> counterproductive.  It's almost always better to REJECT unwanted mail.
>
> When you DISCARD, that means your mail server has to process the
> entire message; REJECT will terminate the transaction before the
> body of the email is sent, saving bandwidth and CPU, and freeing an
> smptd process to accept more mail.
>
> When you DISCARD, the sender thinks you have accepted the mail; some
> bad actors take this as an invitation to send you ever increasing
> amounts of junk, wasting even more of your bandwidth and CPU.

Yes, of course seeing that now it makes perfect sense. Somehow I got it
the otherway round ... I'll change this.

/Martin S

Reply | Threaded
Open this post in threaded view
|

Re: smtpd_sender_restriction

Martin Skjöldebrand
In reply to this post by John Fawcett
Den 2016-12-28 kl. 16:56, skrev John Fawcett:

> On 12/28/2016 03:40 PM, Martin Skjöldebrand wrote:
>> Den 2016-12-28 kl. 11:40, skrev Dominic Raferd:
>>
>>> Did you rebuild the sender_access.db file with postmap
>>> /etc/postfix/sender_access (without errors), and then postfix reload?
>>> The sender_access file itself is not read by postfix, only the .db
>>> file. Otherwise post here an example of your sender_access file data,
>>> each domain (or mail address) you want to reject should be on a
>>> separate line followed by whitespace REJECT - full info at
>>> http://www.postfix.org/access.5.html
>>>
>> So what I did was I edited the sender_access file, the beginning of
>> which contains
>>
>> # REJECT domains which *might* have legit senders (yeah very likely)
>> # DISCARD domains which obviously or suspected to not honouring unsub
>> commands
>>
>> dagens-erbjudanden.com DISCARD
>> tailtucks.com REJECT
>> nyhets-torget.se DISCARD
>> mina-erbjudanden.se DISCARD
>> fantastisk2.ccemails.net DISCARD
>> nam-mail.com DISCARD
>> rabattgatan.com DISCARD
>>
>> Saved it and ran postmap /etc/postfix/sender_access
>> which didn't present any error then did a servicectl restart postfix
>>
>> This is as I understand what is needed. I haven't seen any mail from
>> "rabattgatan.com" in the last hour or so, but just soon after I did this
>> the first time I got at least two.
>>
>> I do hope this is the correct procedure, else feel free to correct.
>>
>> /Martin S
>
> Martin
>
> you can test your map with:
>
> postmap -q rabattgatan.com hash:/etc/postfix/sender_access

martin@Mail:~$ postmap -q rabattgatan.com hash:/etc/postfix/sender_access
REJECT


> Can you show evidence, i.e. the log file entries of an email passing
> through your system from the arrival to the delivery, which shows that
> the map was not taken into account?

This is a bit weird. I can see other mails in list above being rejected,
either becasuse they are in the list above e.g.

Dec 29 06:31:29 Mail postfix/smtpd[14543]: NOQUEUE: reject: RCPT from
mta2.dk-eamail.eamailserver.dk[81.92.123.64]: 554 5.7.1
<[hidden email]>: Sender address rejected: Access
denied; from=<[hidden email]>
to=<[hidden email]> proto=ESMTP
helo=<mta2.dk-eamail.eamailserver.dk>

Or because they're blocked by rbl or some other error (domain unknown).
But I'm not finding rabattgatan.com anywhere in the logs (mail.log, syslog)

> Can you post your postconf -n output?

martin@Mail:~$ postconf -n
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
content_filter = amavis:[127.0.0.1]:10024
disable_vrfy_command = yes
dovecot_destination_recipient_limit = 1
enable_original_recipient = no
header_checks = regexp:/etc/postfix/header_checks
inet_interfaces = all
mailbox_size_limit = 0
maximal_backoff_time = 8000s
maximal_queue_lifetime = 7d
minimal_backoff_time = 1000s
mydestination =
myhostname = mail.skjoldebrand.org
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mynetworks_style = host
myorigin = /etc/hostname
readme_directory = no
recipient_delimiter = +
smtp_helo_timeout = 60s
smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_client_restrictions = reject_rbl_client sbl.spamhaus.org,
reject_rbl_client blackholes.easynet.nl, reject_rbl_client cbl.abuseat.org
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_delay_reject = yes
smtpd_error_sleep_time = 1s
smtpd_hard_error_limit = 12
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, warn_if_reject
reject_non_fqdn_hostname, reject_invalid_hostname, permit
smtpd_recipient_limit = 16
smtpd_recipient_restrictions = reject_unauth_pipelining,
permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_recipient,
reject_unknown_recipient_domain, reject_unauth_destination,
check_policy_service inet:127.0.0.1:10023, permit
smtpd_relay_restrictions = reject_unauth_pipelining, permit_mynetworks,
permit_sasl_authenticated, reject_non_fqdn_recipient,
reject_unknown_recipient_domain, reject_unauth_destination,
check_policy_service inet:127.0.0.1:10023, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain =
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sender_login_maps =
mysql:/etc/postfix/mysql_virtual_sender_login_maps.cf
smtpd_sender_restrictions = check_sender_access
hash:/etc/postfix/sender_access, permit_mynetworks,
reject_authenticated_sender_login_mismatch, permit_sasl_authenticated,
warn_if_reject reject_non_fqdn_sender, reject_unknown_sender_domain,
reject_unauth_pipelining, permit
smtpd_soft_error_limit = 3
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_dh1024_param_file = /etc/ssl/private/dhparams.pem
smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK,
aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_loglevel = 1
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 450
virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf,
mysql:/etc/postfix/mysql_virtual_alias_domainaliases_maps.cf
virtual_gid_maps = static:8
virtual_mailbox_base = /var/vmail
virtual_mailbox_domains = mysql:/etc/postfix/mysql_virtual_domains_maps.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf,
mysql:/etc/postfix/mysql_virtual_mailbox_domainaliases_maps.cf
virtual_transport = dovecot
virtual_uid_maps = static:150

Reply | Threaded
Open this post in threaded view
|

Re: smtpd_sender_restriction

Martin Skjöldebrand
Den 2016-12-29 kl. 09:05, skrev Martin Skjöldebrand:
> Can you show evidence, i.e. the log file entries of an email passing
>> through your system from the arrival to the delivery, which shows that
>> the map was not taken into account?
>
> This is a bit weird. I can see other mails in list above being rejected,
> either becasuse they are in the list above e.g.

And just to point out the "obvious" I just got a mail through from
[hidden email] ..

/Martin S
Reply | Threaded
Open this post in threaded view
|

Re: smtpd_sender_restriction

Dominic Raferd
On 29 December 2016 at 08:08, Martin Skjöldebrand
<[hidden email]> wrote:

> Den 2016-12-29 kl. 09:05, skrev Martin Skjöldebrand:
>> Can you show evidence, i.e. the log file entries of an email passing
>>> through your system from the arrival to the delivery, which shows that
>>> the map was not taken into account?
>>
>> This is a bit weird. I can see other mails in list above being rejected,
>> either becasuse they are in the list above e.g.
>
> And just to point out the "obvious" I just got a mail through from
> [hidden email] ..

Two possibilities occur to me - (a) the email is not 'really' from
[hidden email], maybe this is the envelope sender or just the
display name? or (b) if your mailserver is relaying on incoming emails
to another final destination mailbox e.g. gmail, maybe the emails from
[hidden email] are being sent direct to the final destination
mailbox (i.e. your 'hidden' gmail address) and so never passing
through your postfix mailserver. All this should be clear from the
headers of an offending email.
Reply | Threaded
Open this post in threaded view
|

Re: smtpd_sender_restriction

Martin Skjöldebrand
Den 2016-12-29 kl. 10:45, skrev Dominic Raferd:

> Two possibilities occur to me - (a) the email is not 'really' from
> [hidden email], maybe this is the envelope sender or just the
> display name? or (b) if your mailserver is relaying on incoming emails
> to another final destination mailbox e.g. gmail, maybe the emails from
> [hidden email] are being sent direct to the final destination
> mailbox (i.e. your 'hidden' gmail address) and so never passing
> through your postfix mailserver. All this should be clear from the
> headers of an offending email.

I'm not relaying the mail anywhere, but reading off of my server.

I post the headers of the mail here in case more eyes can see what I'm
not seeing.

Return-Path: <[hidden email]>
Delivered-To: [hidden email]
Received: from localhost (mail.skjoldebrand.org [127.0.0.1])
        by mail.skjoldebrand.org (Postfix) with ESMTP id 5C49241FA9
        for <[hidden email]>; Thu, 29 Dec 2016 09:49:14 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at skjoldebrand.org
X-Spam-Flag: NO
X-Spam-Score: 4.93
X-Spam-Level: ****
X-Spam-Status: No, score=4.93 tagged_above=-9999 required=6.31
        tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_IMAGE_ONLY_24=1.282,
        HTML_MESSAGE=0.001, NO_RECEIVED=-0.001, NO_RELAYS=-0.001,
        URIBL_ABUSE_SURBL=1.948, URIBL_BLACK=1.7]
        autolearn=no autolearn_force=no
Received: from mail.skjoldebrand.org ([127.0.0.1])
        by localhost (mail.is5vvtanwi2exf2ymdo0g3rtze.fx.internal.cloudapp.net
[127.0.0.1]) (amavisd-new, port 10024)
        with ESMTP id UEpvsKs9y09d for <[hidden email]>;
        Thu, 29 Dec 2016 09:49:10 +0000 (UTC)
Date: Thu, 29 Dec 2016 10:49:09 +0100
To: [hidden email]
From: Julia Petterson <[hidden email]>
Subject: Du har 15.739,15 kr klart till utbetalning
Message-ID: <[hidden email]>
X-YMLPcode: y3p2+398+54296
List-Unsubscribe: <http://t.ymlp31.net/unsub_gwhbmmugsgbjeyhgmyqggyujsh.php>
MIME-Version: 1.0
Content-Type: multipart/alternative;
        boundary="b1_5b2e4056110b69010cbed7ad5097c5ee"


--b1_5b2e4056110b69010cbed7ad5097c5ee
Content-Type: text/plain; charset = "utf-8"
Content-Transfer-Encoding: quoted-printable


Reply | Threaded
Open this post in threaded view
|

Re: smtpd_sender_restriction

Dominic Raferd
On 29 December 2016 at 10:13, Martin Skjöldebrand
<[hidden email]> wrote:

>
> I post the headers of the mail here in case more eyes can see what I'm
> not seeing.
>
> Return-Path: <[hidden email]>
> Delivered-To: [hidden email]
> Received: from localhost (mail.skjoldebrand.org [127.0.0.1])
>         by mail.skjoldebrand.org (Postfix) with ESMTP id 5C49241FA9
>         for <[hidden email]>; Thu, 29 Dec 2016 09:49:14 +0000 (UTC)
> X-Virus-Scanned: Debian amavisd-new at skjoldebrand.org
> X-Spam-Flag: NO
> X-Spam-Score: 4.93
> X-Spam-Level: ****
> X-Spam-Status: No, score=4.93 tagged_above=-9999 required=6.31
>         tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_IMAGE_ONLY_24=1.282,
>         HTML_MESSAGE=0.001, NO_RECEIVED=-0.001, NO_RELAYS=-0.001,
>         URIBL_ABUSE_SURBL=1.948, URIBL_BLACK=1.7]
>         autolearn=no autolearn_force=no
> Received: from mail.skjoldebrand.org ([127.0.0.1])
>         by localhost (mail.is5vvtanwi2exf2ymdo0g3rtze.fx.internal.cloudapp.net
> [127.0.0.1]) (amavisd-new, port 10024)
>         with ESMTP id UEpvsKs9y09d for <[hidden email]>;
>         Thu, 29 Dec 2016 09:49:10 +0000 (UTC)
> Date: Thu, 29 Dec 2016 10:49:09 +0100
> To: [hidden email]
> From: Julia Petterson <[hidden email]>
> Subject: Du har 15.739,15 kr klart till utbetalning
> Message-ID: <[hidden email]>
> X-YMLPcode: y3p2+398+54296
> List-Unsubscribe: <http://t.ymlp31.net/unsub_gwhbmmugsgbjeyhgmyqggyujsh.php>
> MIME-Version: 1.0
> Content-Type: multipart/alternative;
>         boundary="b1_5b2e4056110b69010cbed7ad5097c5ee"
>


Did you edit out some lines between the 2nd Received: and the Date:
headers? Seems strange that the first (i.e. the last as listed)
Received header is the internal one as postfix passes the email to
amavis, shouldn't there be earlier Received headers showing the
email's progress through to, and including its arrival at, your
server?

BTW if you aren't using Bayes with spamassassin (or you aren't
training it), you could try a lower trigger setting in amavis, I use
4.0 instead of the default 6.31, which would have picked up your
example as spam:

$sa_tag2_level_deflt = 4.0; # add 'spam detected' headers at that level
$sa_kill_level_deflt = 4.0; # triggers spam evasive actions
Reply | Threaded
Open this post in threaded view
|

Re: smtpd_sender_restriction

John Fawcett
In reply to this post by Martin Skjöldebrand
On 12/29/2016 11:13 AM, Martin Skjöldebrand wrote:

> Den 2016-12-29 kl. 10:45, skrev Dominic Raferd:
>
>> Two possibilities occur to me - (a) the email is not 'really' from
>> [hidden email], maybe this is the envelope sender or just the
>> display name? or (b) if your mailserver is relaying on incoming emails
>> to another final destination mailbox e.g. gmail, maybe the emails from
>> [hidden email] are being sent direct to the final destination
>> mailbox (i.e. your 'hidden' gmail address) and so never passing
>> through your postfix mailserver. All this should be clear from the
>> headers of an offending email.
> I'm not relaying the mail anywhere, but reading off of my server.
>
> I post the headers of the mail here in case more eyes can see what I'm
> not seeing.
>
> Return-Path: <[hidden email]>
> Delivered-To: [hidden email]
> Received: from localhost (mail.skjoldebrand.org [127.0.0.1])
> by mail.skjoldebrand.org (Postfix) with ESMTP id 5C49241FA9
> for <[hidden email]>; Thu, 29 Dec 2016 09:49:14 +0000 (UTC)
> X-Virus-Scanned: Debian amavisd-new at skjoldebrand.org
> X-Spam-Flag: NO
> X-Spam-Score: 4.93
> X-Spam-Level: ****
> X-Spam-Status: No, score=4.93 tagged_above=-9999 required=6.31
> tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_IMAGE_ONLY_24=1.282,
> HTML_MESSAGE=0.001, NO_RECEIVED=-0.001, NO_RELAYS=-0.001,
> URIBL_ABUSE_SURBL=1.948, URIBL_BLACK=1.7]
> autolearn=no autolearn_force=no
> Received: from mail.skjoldebrand.org ([127.0.0.1])
> by localhost (mail.is5vvtanwi2exf2ymdo0g3rtze.fx.internal.cloudapp.net
> [127.0.0.1]) (amavisd-new, port 10024)
> with ESMTP id UEpvsKs9y09d for <[hidden email]>;
> Thu, 29 Dec 2016 09:49:10 +0000 (UTC)
> Date: Thu, 29 Dec 2016 10:49:09 +0100
> To: [hidden email]
> From: Julia Petterson <[hidden email]>
> Subject: Du har 15.739,15 kr klart till utbetalning
> Message-ID: <[hidden email]>
> X-YMLPcode: y3p2+398+54296
> List-Unsubscribe: <http://t.ymlp31.net/unsub_gwhbmmugsgbjeyhgmyqggyujsh.php>
> MIME-Version: 1.0
> Content-Type: multipart/alternative;
> boundary="b1_5b2e4056110b69010cbed7ad5097c5ee"
>
>
> --b1_5b2e4056110b69010cbed7ad5097c5ee
> Content-Type: text/plain; charset = "utf-8"
> Content-Transfer-Encoding: quoted-printable
>
>
the envelope sender is [hidden email]

That is why it is not stopped by your checks.

There is a difference between the envelope sender (the sender that is
indicated in the SMTP transaction in the MAIL FROM command) and the
From: header in the message content.

John