Re: Stopping acceptence from unowned networks address as from my domains
On Fri, 8 Feb 2019 at 01:31, li...@lazygranch.com wrote: > I'm having trouble finding check_sender_access AND inline. Is inline > some way of not using hash? For example, I have: > > check_sender_access hash:/etc/postfix/sender_checks, > > Maybe I'm using this wrong. I have this set up to whitelist addresses. > That is my sender_checks looks like > > gwoodper...@ok.com OK > > I'm not using this to reject anything. > re inline see http://www.postfix.org/DATABASE_README.html What you are doing is fine but whitelisting in general carries risk and whitelisting on the envelope sender especially because this parameter is easily faked and it will not usually be seen by the recipient. I use check_sender _access whitelisting only for a few cases where legitimate mails have previously been wrongly blocked by subsequent RBL or reject_unknown_reverse_client_hostname tests. (If your RBL tests are done inside postscreen then local whitelisting by envelope sender is too late I think.) I do however use check_sender_access for blacklisting (REJECT) and for spam scoring.
Re: Stopping acceptence from unowned networks address as from my domains
On Thu, 7 Feb 2019 05:24:08 +0100
Francesc Peñalvez wrote:
> I asked the same and Vietse Venema answer this:
>
> Postfix 3.0 and later:
>
> /etc/postfix/main.cf:
> smtpd_sender_restrictions =
> permit_mynetworks
> permit_sasl_authenticated
> check_sender_access inline:{
> { example.com = REJECT local sender from unauthorized
> client }
> { other.example = REJECT local sender from unauthorized
> client }
> }
>
> Instead of example.com and other.example, specify your email domains.
>
> Note: this breaks email from remote mail forwarders or from remote
> distribution lists that don't reset the sender address.
>
>
> this worked perfectly for me
>
> *
> Este mensaje y todos los archivos adjuntos son confidenciales y de
> uso exclusivo por parte de su/sus destinatario/s. Si usted ha
> recibido este mensaje por error, le agradecemos que lo notifique
> inmediatamente al remitente y destruya el mensaje. Queda prohibida
> cualquier modificación, edición, uso o divulgación no autorizados. El
> Emisor no se hace responsable de este mensaje si ha sido modificado,
> distorsionado, falsificado, infectado por un virus o editado o
> difundido sin autorización.
>
>
> ***
> This message and any attachments are confidential and intended for
> the named addressee(s) only. If you have received this message in
> error, please notify immediately the sender, then delete the message.
> Any unauthorized modification, edition, use or dissemination is
> prohibited. The sender shall not be liable for this message if it has
> been modified, altered, falsified, infected by a virus or even edited
> or disseminated without authorization.
> ***
>
> El 07/02/2019 a las 2:44, Ruben Safir escribió:
> > I got this email, which I thought I set up postfix to block
> >
> > >From ru...@mrbrklyn.com Wed Feb 6 06:26:12 2019
> > Return-Path:
> > X-Original-To: ru...@mrbrklyn.com
> > Delivered-To: ru...@mrbrklyn.com
> > Received: from mail.isentia.asia (mail.mediabanc.ws
> > [203.223.144.88]) by mrbrklyn.com (Postfix) with ESMTP id
> > BE463161132 for ; Wed, 6 Feb 2019 06:25:50
> > -0500 (EST) Received: from fixed-187-189-92-126.totalplay.net
> > (187.189.92.126) by mail.mediabanc.ws (10.61.3.33) with Microsoft
> > SMTP Server id 8.1.240.5; Wed,
> > 6 Feb 2019 15:36:09 +0800
> > From: BSM
> > To: ru...@mrbrklyn.com
> > Subject: Directorio Empresarial Mexicano 2019
> > Date: Wed, 6 Feb 2019 01:40:06 -0600
> > Message-ID: <20190206014006.8f2d6192f98f7...@mrbrklyn.com>
> > MIME-Version: 1.0
> > Content-Type: text/html; charset="iso-8859-1"
> > Content-Transfer-Encoding: quoted-printable
> > X-UID: 55347
> > Status: RO
> > Content-Length: 36872
> > Lines: 561
> >
> > This is addressed as me in the From line and came from outside my
> > local network
> >
> > I want domain being accepted From my domain only is it comes from
> > within the local network
> >
>
I'm having trouble finding check_sender_access AND inline. Is inline
some way of not using hash? For example, I have:
check_sender_access hash:/etc/postfix/sender_checks,
Maybe I'm using this wrong. I have this set up to whitelist addresses.
That is my sender_checks looks like
goodper...@ok.com OK
I'm not using this to reject anything.
Re: SMTP_HELO_NAME can cause Blacklist triggers
On 2/7/19 2:52 PM, Bill Cole wrote: *snip* But your core point is valid: mailing from an AWS instance (or from anywhere on an IP with a programmatically derived PTR) in general is going to work poorly. There is too little accountability for abuse from the AWS IP pool for it to merit a default level of trust. Even with a proper reverse DNS if you use a VPS hosting service you have to deal with being blacklisted. Doesn't matter how long you have has the IP either. Someone spins up a VPS on same subnet and starts spamming and the entire subnet gets put on the blacklist because of showshoe spammers. What you can do if you don't have the cash to buy your own subnet and use a VPS service, get three of them at different hosting locations and when one gets blacklisted, forward to one of the others to relay until you are removed from the blacklist (usually takes 24 hours because of cached DNS results)
Re: SMTP_HELO_NAME can cause Blacklist triggers
On 7 Feb 2019, at 14:09, Matus UHLAR - fantomas wrote: On 06.02.19 02:42, Patton, Matthew [Contractor] wrote: I learned the hard way that if you don't set $myhostname to a FQDN you can quickly end up on a black list despite having valid SPF records. any evidence about this? Returning to the OP's question, Postfix does append $mydomain to the automatically derived value of $myhostname when the latter is not explicitly set in main.cf and is not fully qualified. Except that it doesn't. (or I misunderstood what you wrote) I set $myhostname = 'smtp'. $mydomain was also set. I had to set both since gethostbyname() would have returned a value of 'ip-XX.aws.internal'. what led you to the conclusion that your non-fqdn hostname caused RBL listing? I know servers that refuse non-FQDN helo. I've seen servers that refuse invalid or generic DNS names (ip-XX.aws.internal is both). But I don't remember a RBL that would immediately list such hosts. I don't believe any DNSBL will list on a generic "non-FQDN helo" basis, however there are idiosyncratic non-FQDN helo names and patterns which are good enough indicators of membership in specific botnets to block or even list on a DNSBL. I believe that the CBL has at times used such names as a listing trigger, but it is important to add that it is my understanding that the CBL also has strong criteria for *where* and *how* a sending machine must display app-layer fingerprint behaviors for a listing, i.e. you can't get listed for sending entirely legitimate non-bulk email to working addresses of living humans using an otherwise botnet-only HELO name. PSBL and NiX Spam *MAY* also use such "fingerprint" HELO names and I'm not as confident that their safeguards are as strong as CBL's. But your core point is valid: mailing from an AWS instance (or from anywhere on an IP with a programmatically derived PTR) in general is going to work poorly. There is too little accountability for abuse from the AWS IP pool for it to merit a default level of trust. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Available For Hire: https://linkedin.com/in/billcole
Problems invoking amavis from postfix
I am building a new system on CentOS7 that has postfix 2.10.1 and
amavis-new 2.11.1
I am working from my notes of 2 years ago when I last did this
successfully so either something has changed since then (quite likely),
or I am missing something from my notes (also quite likely).
For main.cf I run:
postconf -e 'content_filter = amavis:[127.0.0.1]:10024'
Then I append to the default master.cf (working from my understanding
that the last instruction in master.cf encountered is the one applied,
rather than trying to edit what is there):
#
==
# service type private unpriv chroot wakeup maxproc command + args #
(yes) (yes) (yes) (never) (100) #
==
smtpd pass - - n - - smtpd submission inet n - n - - smtpd -o
smtpd_recipient_restrictions= pickup unix n - n 60 1 pickup -o
content_filter= relay unix - - n - - smtp -o fallback_relay= maildrop
unix - n n - - pipe flags=DRhu user=vmail argv=/usr/local/bin/maildrop
-d ${recipient} uucp unix - n n - - pipe flags=Fqhu user=uucp argv=uux
-r -n -z -a$sender - $nexthop!rmail ($recipient) ifmail unix - n n - -
pipe flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop
($recipient) bsmtp unix - n n - - pipe flags=Fq. user=bsmtp
argv=/usr/local/sbin/bsmtp -f $sender $nexthop $recipient # # spam/virus
section # amavis unix - - y - 2 lmtp -o lmtp_data_done_timeout=1200 -o
lmtp_send_xforward_command=yes -o disable_dns_lookups=yes -o max_use=20
127.0.0.1:10025 inet n - n - - smtpd -o content_filter= -o
smtpd_delay_reject=no -o
smtpd_client_restrictions=permit_mynetworks,reject -o
smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o
smtpd_recipient_restrictions=permit_mynetworks,reject -o
smtpd_data_restrictions=reject_unauth_pipelining -o
smtpd_end_of_data_restrictions= -o smtpd_restriction_classes= -o
mynetworks=127.0.0.0/8 -o smtpd_error_sleep_time=0 -o
smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o
smtpd_client_connection_count_limit=0 -o
smtpd_client_connection_rate_limit=0 -o
receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters
-o local_header_rewrite_clients= -o smtpd_milters= -o
local_recipient_maps= -o relay_recipient_maps= # # Dovecot LDA dovecot
unix - n n - - pipe flags=DRhu user=vmail:mail
argv=/usr/libexec/dovecot/deliver -d ${recipient} # # Vacation mail
vacation unix - n n - - pipe flags=Rq user=vacation
argv=/var/spool/vacation/vacation.pl -f ${sender} -- ${recipient}
Dovecot is working just fine, BTW. So I run a couple of tests:
sendmail -i r...@test.htt-consult.com < sample-virus-simple.txt
Feb 7 12:52:57 klovia postfix/pickup[11341]: 9347458EC: uid=0 from=
Feb 7 12:52:57 klovia postfix/cleanup[11458]: 9347458EC:
message-id=<20190207175257.934745...@klovia.htt-consult.com>
Feb 7 12:52:57 klovia postfix/qmgr[6089]: 9347458EC:
from=, size=430, nrcpt=1 (queue active)
Feb 7 12:52:58 klovia dovecot: lda(r...@test.htt-consult.com): sieve:
msgid=<20190207175257.934745...@klovia.htt-consult.com>: stored mail
into mailbox 'INBOX'
Feb 7 12:52:58 klovia postfix/pipe[11465]: 9347458EC:
to=, relay=dovecot, delay=4.3,
delays=3.4/0.08/0/0.77, dsn=2.0.0, status=sent (delivered via dovecot
service)
Feb 7 12:52:58 klovia postfix/qmgr[6089]: 9347458EC: removed
sendmail -i r...@test.htt-consult.com < sample-spam-GTUBE-junk.txt
Feb 7 12:54:08 klovia postfix/pickup[11341]: 860DE58EC: uid=0 from=
Feb 7 12:54:08 klovia postfix/cleanup[11458]: 860DE58EC:
message-id=
Feb 7 12:54:08 klovia postfix/qmgr[6089]: 860DE58EC:
from=, size=941, nrcpt=1 (queue active)
Feb 7 12:54:09 klovia dovecot: lda(r...@test.htt-consult.com): sieve:
msgid=: stored mail into mailbox 'INBOX'
Feb 7 12:54:09 klovia postfix/pipe[11465]: 860DE58EC:
to=, relay=dovecot, delay=0.89,
delays=0.37/0.02/0/0.5, dsn=2.0.0, status=sent (delivered via dovecot
service)
Feb 7 12:54:09 klovia postfix/qmgr[6089]: 860DE58EC: removed
Both right to INBOX. Obviously I am missing something. I have spent
the day reading over stuff, but I am missing what I am missing.
I hope someone here can lend a hand. I suspect it is a 'small'
oversight as that all it takes.
thanks
Oh, and here is the status of amavisd:
# systemctl -l status amavisd
● amavisd.service - Amavisd-new is an interface between MTA and content
checkers.
Loaded: loaded (/usr/lib/systemd/system/amavisd.service; enabled;
vendor preset: disabled)
Active: active (running) since Thu 2019-02-07 08:16:59 EST; 7h ago
Docs: http://www.ijs.si/software/amavisd/#doc
Process: 5715 ExecStart=/usr/sbin/amavisd -c
/etc/amavisd/amavisd.conf (code=exited, status=0/SUCCESS)
Main PID: 6327 (/usr/sbin/amavi)
CGroup: /system.slice/amavisd.service
├─6327 /usr/sbin/amavisd (master)
├─6336 /usr/sbin/amavisd (virgin child)
└─6337 /usr/sbin/amavisd (virgin
Re: SMTP_HELO_NAME can cause Blacklist triggers
On 06.02.19 02:42, Patton, Matthew [Contractor] wrote: I learned the hard way that if you don't set $myhostname to a FQDN you can quickly end up on a black list despite having valid SPF records. any evidence about this? Returning to the OP's question, Postfix does append $mydomain to the automatically derived value of $myhostname when the latter is not explicitly set in main.cf and is not fully qualified. Except that it doesn't. (or I misunderstood what you wrote) I set $myhostname = 'smtp'. $mydomain was also set. I had to set both since gethostbyname() would have returned a value of 'ip-XX.aws.internal'. what led you to the conclusion that your non-fqdn hostname caused RBL listing? I know servers that refuse non-FQDN helo. I've seen servers that refuse invalid or generic DNS names (ip-XX.aws.internal is both). But I don't remember a RBL that would immediately list such hosts. My HELO string was verifiably just $myhostname. Precisely as documented: $smtp_helo_name defaults to $myhostname http://www.postfix.org/postconf.5.html#smtp_helo_name The naked 'smtp' was an instant blacklist largely as a result of millions of vulnerable Microtek home routers which have been exploited. again, how do you know it got to any blacklist? If Postfix had instead used $myhostname.$mydomain IFF $myhostname is not FQDN (has no dots at all) then 'smtp'.$mydomain would have been perfectly fine since there was an A record for it for quite some time. well, since the $mydomain is by default taken from $myhostname, it should be obvious you must set $myhostname to a FQDN. Fair enough. But I still think that at the very least the docs should be a little more explicit, and furthermore a warning is merited during valid_hostname() and with SLOPPY_VALID_HOSTNAME we can continue without error. yes, apparently some of the docs could be little more explicit about $hostname or $smtp_helo_name should be a FQDN. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Atheism is a non-prophet organization.
Re: Stopping acceptence from unowned networks address as from my domains
postfix can do this without further infrastructure On Thu, Feb 07, 2019 at 07:53:38AM -0800, Lucius Rizzo wrote: > On Wed, Feb 06, 2019 at 08:44:40PM -0500, Ruben Safir wrote: > > I got this email, which I thought I set up postfix to block > > Setup SPFi (SPF hardfail) , DKIM, DMARC properly -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and extermination camps, but incompatible with living as a free human being. -RI Safir 2013
Re: Stopping acceptence from unowned networks address as from my domains
On Wed, Feb 06, 2019 at 08:44:40PM -0500, Ruben Safir wrote: > I got this email, which I thought I set up postfix to block Setup SPFi (SPF hardfail) , DKIM, DMARC properly
Re: Stopping acceptence from unowned networks address as from my domains
Greetings, Gary! > From: BSM > To: ru...@mrbrklyn.com I'm explicitly rejecting any attempt to push mails with $mydomain in From through public mail exchanger. If it is internal correspondence from domain members, they should use submission service, which allows such mails. -- With best regards, Andrey Repin Thursday, February 7, 2019 17:36:01 Sorry for my terrible english...
