Re: re-route mails on demand during block of ip address
On 31 May 2019, at 11:12, Stefan Bauer wrote: > thank you for your reply. You know, in real world, ips/ranges get blocked > from time to time Not be legitimate RBLs they don't unless you are actually sending spam. If more IPs than just you mail server are getting blocked, then you probably need to get a new NSP that doesn't tolerate spammers. If you want to send mail to others you pretty much need to meet these criteria. Fixed IP with valid rDNS NSP that does not allow spammers A valid secure configuration on your server (no open relay) Not be sending spam yourself If you can't meet all of those, then you need to rely on someone else who does meet those minimums to send mail on your behalf. I've been through several IP changes over the years and the only RBL that haas ever listed me was barracuda, which was coincidently after I replied to one of their marketing emails with "fuck off" but even that was more than a decade ago. -- 'Detectoring is like gambling,' said Vimes, putting down the clove. 'The secret is to know the winner in advance.'
Re: Mail Delivery Status report
> On 31 May 2019, at 00:33, Bastian Blank > wrote: > > On Fri, May 31, 2019 at 12:03:37AM -0600, @lbutlr wrote: >> I am getting mail delivery status reports for every bcc email (that is, >> every email, since I use a bcc map to create a backup of all the mail). > > Then you missconfigured something. Sure, but what could it be? > Mails duplicated by bcc maps are sent with NOTIFY=NONE, so don't create any > DSN. Yes, that is how it worked a couple of weeks ago. And the pm;y was O see to change that is to set sundial -v which is not set anywhere and isn't in postconf . > See http://www.postfix.org/postconf.5.html#recipient_bcc_maps And I posted the contents of the file referred to in recipient_bcc_maps >> Still, I am not sure why these messages are bing generate or how to turn >> them off. > > Show logs, read http://www.postfix.org/DEBUG_README.html#mail There's nothing interesting in the logs, sadly. It shows the bcc message being created and sent to the bcc address and the the delivery status notification ebbing generated as well, but not why. mail postfix/pipe[78386]: 45FZmb6nfgzdrvL: to=>, relay=dovecot, delay=0.03, delays=0.01/0.01/0/0.01, dsn=2.0.0, status=deliverable (delivers to command: /usr/local/libexec/dovecot/dovecot-lda) mail postfix/pickup[14015]: 45FZmb6nfgzdrvL: uid=0 from= mail postfix/cleanup[78054]: 45FZmb6nfgzdrvL: message-id=<45fzmb6nfgzd...@mail.covisp.net> mail postfix/qmgr[65477]: 45FZmb6nfgzdrvL: from=, size=271, nrcpt=2 (queue active) mail postfix/local[78415]: 45FZmb6nfgzdrvL: to=, orig_to=, relay=local, delay=0.03, delays=0.01/0.01/0/0.01, dsn=2.0.0, status=deliverable (delivers to command: /usr/local/bin/procmail -t -a $EXTENSION) mail postfix/bounce[78605]: 45FZmb6nfgzdrvL: sender delivery status notification: 45FZmb6xXXzdrvd mail postfix/qmgr[65477]: 45FZmb6nfgzdrvL: removed But nothin there says why the delivery status notification is generated. -- Q is for QUENTIN who sank in the mire R is for RHODA consumed by a fire
Mail Delivery Status report
I am getting mail delivery status reports for every bcc email (that is, every
email, since I use a bcc map to create a backup of all the mail).
I've looked through all the postfix files for any instance of sendmail -v, and
have only found it as a comment in bounce.cf.default
/usr/local/etc/postfix
# grep "sendmail -v" *
bounce.cf.default:# address...) or for verbose mail delivery (sendmail -v
address...).
main.cf:
recipient_bcc_maps = pcre:$config_directory/rbcc.pcre
rbcc.pcre:
if !/backup.*@/
/^([^+_]*).*@(.*)/ backup+151.${1}.${2}@
endif
the MDSR is not really a problem, but it is not needed, so I'd like to turn it
off if I could.
> Postfix can produce two types of mail delivery reports for debugging:
>
> • What-if: report what would happen, but do not actually deliver mail.
> This mode of operation is requested with:
>
> % /usr/sbin/sendmail -bv address...
>
> Mail Delivery Status Report will be mailed to .
>
> • What happened: deliver mail and report successes and/or failures,
> including replies from remote SMTP servers. This mode of operation is
> requested with:
>
> % /usr/sbin/sendmail -v address...
"sendmail" doesn't appears uncommented in main,.cf nor master.cf, though
sendmail_path = /usr/local/sbin/sendmail is a default setting.
Still, I am not sure why these messages are bing generate or how to turn them
off.
--
Against stupidity the gods themselves contend in vain.
Re: opendmarc.dat Permission denied issues
> On 30 May 2019, at 07:37, Matus UHLAR - fantomas wrote: > > On 30.05.19 07:27, @lbutlr wrote: >> On 30 May 2019, at 07:24, @lbutlr wrote: >>> But can still be deleted at any time, just "less frequently than /tmp"; >>> certainly not a place to store necessary files. I don't see this anywhere >>> for *BSD, thankfully, so I can safely ignore it. >> >> Goops, forgot to past this: >> >> >> /var/tmp/ Temporary files which are usually preserved across a system >> reboot, unless /var is a memory-based file system. >> >> which is much weaker than "…must not be deleted when the system is booted." > > and what exxactly are you complaining about? Nothing. Just commenting out the difference between Linux and *BSD in how they view this directory. > btw the OP used /var/run, which is also designed to be cleaned upon boot. That's not even part of the defined hierarchy for BSD, though it is often used for storing PID files and some sockets. Storing real data there seems like a bad idea, but sure enough, some programs seem to have put stuff there on my system, and some of it is quite old. Of course, without a specific policy in https://www.freebsd.org/doc/handbook/dirstructure.html it's hard to predict what will happen, though I would hope it is untouched. -- Far away, across the fields, the tolling of the iron bell calls the faithful to their knees to hear the softly spoken magic spells.
Re: opendmarc.dat Permission denied issues
On 30 May 2019, at 07:24, @lbutlr wrote: > But can still be deleted at any time, just "less frequently than /tmp"; > certainly not a place to store necessary files. I don't see this anywhere for > *BSD, thankfully, so I can safely ignore it. Goops, forgot to past this: /var/tmp/ Temporary files which are usually preserved across a system reboot, unless /var is a memory-based file system. which is much weaker than "…must not be deleted when the system is booted." -- "Two years from now, spam will be solved," -- Bill Gates, January, 2004
Re: opendmarc.dat Permission denied issues
On 30 May 2019, at 06:32, Matus UHLAR - fantomas wrote: >> On 29 May 2019, at 08:52, Benny Pedersen wrote: >>> /var/tmp must not be cleaned after boots, /tmp will be cleaned on boot > > On 30.05.19 04:44, @lbutlr wrote: >> I've never heard that. Is that a real thing or just your own 'rule'? > > it's standard FHS: > > https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard > > /tmp > > Temporary files (see also /var/tmp). Often not preserved between system > reboots, and may be severely size restricted. > /var/tmp > > Temporary files to be preserved between reboots. But can still be deleted at any time, just "less frequently than /tmp"; certainly not a place to store necessary files. I don't see this anywhere for *BSD, thankfully, so I can safely ignore it. The only files in /var/tmp on my system are the database for pkg provides and a directory for vi.recovery containing a single file from April 2018. -- Two, Four, Six, Eight! Time to Transubstantiate!
Re: Postscreen - fatal: btree:/var/db/postfix/postscreen_cache
On 30 May 2019, at 02:39, Jos Chrispijn wrote: > A friend advised me to run /postfix/update and it looks as if this did the > trick. Part of that file contains: > > newaliases > postalias hash:/etc/aliases > postfix reload > postfix flush Wher e did that come from? (It doesn't exist on my system). I don't know about you, but new aliases and postalias and postmap are tools that I run extremely rarely. I think the last made I made to aliases might have been as much as 10 years ago. I've changed virtual more frequently, but still rarely. postfix flush is nearly always a bad idea, and I can't imagine it's useful after a reload, or at least I can't think of a reason you'd want to do that; if you've reloaded, postfix will requeue the mail on its own. -- "If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - Don Marquis
Re: opendmarc.dat Permission denied issues
On 29 May 2019, at 08:52, Benny Pedersen wrote: > /var/tmp must not be cleaned after boots, /tmp will be cleaned on boot I've never heard that. Is that a real thing or just your own 'rule'? -- Lobotomy means never having to say you're sorry -- or anything else.
Re: Blacklist honeypot senders
On 24 May 2019, at 12:52, Rafael Azevedo wrote: > > Hi there, > > I've done that by building a policy filter that bans those IPs using > iptables whenever those trap accounts get reached. Oh, well, that sounds lovely. Is it sharable? (shouldn't be much iss ti adapt it to pf) > It wasn't that easy, but its beautiful how it's working. > > Chain SPAMBLOCK (X references) > pkts bytes target prot opt in out source > destination >0 0 REJECT tcp -- * * 179.97.63.X > 0.0.0.0/0multiport dports 25,80,110,143,443,587,993,995 > reject-with icmp-port-unreachable Yep, that's exact.y what I want to do -- The Monks of Cool, whose tiny and exclusive monastery is hidden in a really cool and laid-back valley in the lower Ramtops, have a passing-out test for a novice. He is taken into a room full of all type of clothing and asked: Yo, my son, which of these is the most stylish thing to wear? And the correct answer is: Hey, whatever I select.
Re: Blacklist honeypot senders
On 24 May 2019, at 11:23, Noel Jones wrote: > On 5/24/2019 11:33 AM, @lbutlr wrote: >> I have an active email address that only receives spam (it is an address >> that wasn't used for years but I've recently reactive to see just how much >> spam an unprotected decades old account that hasn't accepted mail since 2006 >> would get). >> Anyway, what I would like to do is somehow blacklist any IP that sends mail >> to that address for some period of time, configurable by me but not >> necessarily dynamic. (That is, if I could specify 1 day or 3 hours for any >> match, that is fine). >> I suspect that postfix might be able to do this through some sort of >> helo_access check? I mean, I know managing the timeout would be outside of >> postfix, but I can figure that part out easily enough. >> Or should I look at expanding the log matching in fail2ban instead? >> Or something obvious and clearly better? > > Adding a log match in fail2ban for the blacklisted recipient is by far the > easiest solution. Yeah, that is probably what I will do. I also looked at postfix-policyd but despite saying specifically that it supports spam trapping, I was unable to find anyway to specify the spam trap address in the conf file. -- I was good and deleted the "You *&;#$ing moron" before posting aren't you proud of me?
Blacklist honeypot senders
I have an active email address that only receives spam (it is an address that wasn't used for years but I've recently reactive to see just how much spam an unprotected decades old account that hasn't accepted mail since 2006 would get). Anyway, what I would like to do is somehow blacklist any IP that sends mail to that address for some period of time, configurable by me but not necessarily dynamic. (That is, if I could specify 1 day or 3 hours for any match, that is fine). I suspect that postfix might be able to do this through some sort of helo_access check? I mean, I know managing the timeout would be outside of postfix, but I can figure that part out easily enough. Or should I look at expanding the log matching in fail2ban instead? Or something obvious and clearly better? -- 'Never build a dungeon you wouldn't be happy to spend the night in yourself,' said the Patrician (...). 'The world would be a happier place if more people remembered that.' --Guards! Guards!
Re: Tell LMTP who is original recipient?
On 21 May 2019, at 15:36, MRob wrote: > Privacy problem is addressed with smtpd_recipient_limit=1 but thats not very > feasible. Are you sure? I think even the big mailing-list services send individual messages now-a-days. -- Good old Dame Fortune. You can _depend_ on her.
Re: Modify logs for delivery?
On 21 May 2019, at 15:07, @lbutlr wrote: > May 21 14:52:32 mail postfix/local[63216]: 457nyS31Y4zdrvK: > to=, orig_to=, relay=local, > delay=0.39, delays=0.34/0.01/0/0.04, dsn=2.0.0, status=sent (delivered to > command: /usr/local/bin/procmail -t -a $EXTENSION) > > May 21 14:53:16 mail postfix/pipe[67313]: 457nzJ4gd7zdrvL: > to=, relay=dovecot, delay=0.21, delays=0.17/0.01/0/0.03, > dsn=2.0.0, status=sent (delivered via dovecot service) I forgot to include the other status-sent type of log: May 21 15:07:17 mail postfix/smtp[77264]: 457pHK0LmQzdrvL: to=, relay=mail.cloud9.net[168.100.1.4]:25, delay=8.8, delays=0.05/0.01/3.3/5.4, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as BB13033AD0C) (this is the harder one to account for since the to appears on a log line pretty much isolated from anything else) May 21 15:07:09 mail postfix/qmgr[26327]: 457pHK0LmQzdrvL: from=, size=1875, nrcpt=2 (queue active) -- Age is only important if you're cheese.
Modify logs for delivery?
I may have asked this in the past, but ion so it's been longe enough I don't remember and can't find it my mail archives. Is there some way to modify what is logged from postfix/local and postfix/pipe so that the "status=sent" lines include the from address as well as the to address? May 21 14:52:32 mail postfix/local[63216]: 457nyS31Y4zdrvK: to=, orig_to=, relay=local, delay=0.39, delays=0.34/0.01/0/0.04, dsn=2.0.0, status=sent (delivered to command: /usr/local/bin/procmail -t -a $EXTENSION) May 21 14:53:16 mail postfix/pipe[67313]: 457nzJ4gd7zdrvL: to=, relay=dovecot, delay=0.21, delays=0.17/0.01/0/0.03, dsn=2.0.0, status=sent (delivered via dovecot service) I know the to and from are in the permit: DATA log line, but that doesn't show the delivery method nor the delays. Not the end of the world, but if it is possible, that's be great. -- There used to be such simple directions, back in the days before they invented parallel universes - Up and Down, Right and Left, Backward and Forward, Past and Future... But normal directions don't work in the multiverse, which has far too many dimensions for anyone to find their way. So new ones have to be invented so that the way can be found. Like: East of the Sun, West of the Moon Or: Behind the North Wind. Or: At the Back of Beyond. Or: There and Back Again. Or: Beyond the Fields We Know. --Lords and Ladies
Re: Block spam at smtp time, but then still forward to users spam box
On 20 May 2019, at 01:42, Brent Clark wrote: > My colleague has proposed that at smtp time, if a mail is deemed as spam, the > server issues a reject code, but then to too accept the mail and forward the > mail the user for incase its a false positive. The odds of a mail scoring over 10.0 on SpamAssassin being legit are so low as to be meaningless, so that's a silly reason to implement a completely non-standard email chain that is likely to only anger your users with even more spam to sort through. > His logic is that, that the spammer does not build up a database. The days of that are long past. Spammers simply buy lists of billions of emails. They do not care about delivery at all. > Currently what we do is, if the score is between 5 and 15, just accept and > move the spam to the users SPAM box. Above 15 we out right block. I'd say 15 is far too high and including that much spam probably trains your users to never even bother looking at the spam folder, but that's fine. > I am on the fence on this one, hence the reason to pick the communities brain. I would never do this. My rule is very simple, anything we accept gets delivered to the user. Anything we reject gets rejected during the SMTP transaction. If it is LEGITIMATE mail, the sender will see the rejection. -- And east is east and west is west and if you take cranberries and stew them like applesauce they taste much more like prunes than rhubarb does.
Re: Ris: AWS timeout
On 14 May 2019, at 21:35, Ron Wheeler wrote: > If people knew how much of the email travels over the internet as a result of > his work, he would be a tech star. I really doubt he is interested in notoriety. -- 'You're your own worst enemy, Rincewind,' said the sword. Rincewind looked up at the grinning men. 'Bet?' --Colour of Magic
Re: GEO IP based restrictions?
On 14 May 2019, at 13:15, @lbutlr wrote: > On 14 May 2019, at 11:41, @lbutlr wrote: >> Has anyone implemented geo based restrictions for postfix login connections, >> or is this something that needs to be done in dovecot? > > This seemed to work pretty well > > pfctl -t badguys -T add $(cat block.zone) > > I can then flush and add when the CIDR file is updated. > > block.zone is the combination of several countries from ipdeny.com and some > other bad actors that have been problems in the past. (still looking for a way to block other IPs from just the specific services, but this list is, on reflection, small enough I can probably manage it manually in hosts.allow.) -- The whole thing that makes a mathematician's life worthwhile is that he gets the grudging admiration of three or four colleagues
Re: GEO IP based restrictions?
On 14 May 2019, at 11:41, @lbutlr wrote: > Has anyone implemented geo based restrictions for postfix login connections, > or is this something that needs to be done in dovecot? This seemed to work pretty well pfctl -t badguys -T add $(cat block.zone) I can then flush and add when the CIDR file is updated. block.zone is the combination of several countries from ipdeny.com and some other bad actors that have been problems in the past. -- The whole thing that makes a mathematician's life worthwhile is that he gets the grudging admiration of three or four colleagues
Re: GEO IP based restrictions?
> On 14 May 2019, at 11:48, John Peach wrote: > > On 5/14/19 1:41 PM, @lbutlr wrote: >> Has anyone implemented geo based restrictions for postfix login connections, >> or is this something that needs to be done in dovecot? >> I was thinking someway to add most of Asia and Eastern Europe to postscreen >> checks would be useful? > > You can always use access_client and reject based on TLD. I ban most of the > new TLDs that are used for nothing but spam and Eastern Europe.. Urd, I already do that for incoming mail via helo restrictions, but I haven't figured out how to do that effectively for the port 993. > I use the geo-ip extension to iptables for restricting IMAP access. I'll look at that, thanks. On 14 May 2019, at 12:33, Allen Coates wrote: > Alternatively, there is an RBL, zz.countries.nerd.dk, which will return a > code based on country of origin - or if you substitute a country code (eg > uk.countries.nerd.dk) it will return a yes/no response, to blacklist (or > whitelist) an individual country. I don't know how robust these people are, > but they are certainly sufficient for a domestic server. that also sounds promising. -- Vampires have risen from the dead, the grave and the crypt, but have never managed it from the cat. --Witches Abroad
GEO IP based restrictions?
Has anyone implemented geo based restrictions for postfix login connections, or is this something that needs to be done in dovecot? I was thinking someway to add most of Asia and Eastern Europe to postscreen checks would be useful? -- "One of the great tragedies of life is the murder of a beautiful theory by a gang of brutal facts." - Benjamin Franklin
Re: include full original message in bounce
On 9 May 2019, at 09:53, Viktor Dukhovni wrote: > But in fact, my view is that bounces should always be headers-only, > and if you're sending important content whose only copy is in the > outbound message, which is "lost" if not delivered, then that's the > problem, fix the sending software to archive the outgoing message. Exactly this. -- The whole thing that makes a mathematician's life worthwhile is that he gets the grudging admiration of three or four colleagues
Re: Blacklistd interaction
On 6 May 2019, at 11:22, lists wrote: > It had been my experience that the firewall uses more resources that > SSHGuard. Certainly it uses more memory. But you do not have to use a firewall if that's an issue. /etc/hosts.allow is always an option, and that block is practically free. -- I never wanted to do this in the first place.
Re: Blacklistd interaction
On 6 May 2019, at 06:33, Lefteris Tsintjelis wrote: > On 6/5/2019 15:14, @lbutlr wrote: >> On 6 May 2019, at 02:10, Lefteris Tsintjelis wrote: >>> Fail2ban and equivalent log parsers are just too resource hungry, >> No they aren't. > > Yes they are. Not on my super powerful 7 year old i5 mail server with a whole 4GB of RAM that I bought for under $300. I'm sure there are people running mail servers on older and lousier hardware, but I'd guess it's not many. >>> messy and more time consuming to maintain >> Sounds like you are parting some false information others fed you. There is >> nothing to maintain, and they run silently and take no time at all. > > Sounds like you never used them but if you say so must be like that 😉 I have used both and currently use sshguard. I've never seen either show up on htop when sorting by CPU time. Currently I am using sshguard 51842 root 52 0 6464 1544 S 0.0 0.0 0:00.00 sh /usr/local/sbin/sshguard -b /usr/local/etc/sshguard.blacklist -b 120:/var/db/sshguard/blacklist.db -i /var/run/sshguard 0.0 CPU, 0.0 Mem, 00:00:00 Time
Re: Blacklistd interaction
On 6 May 2019, at 02:10, Lefteris Tsintjelis wrote: > On 6/5/2019 9:42, @lbutlr wrote: >> On 4 May 2019, at 15:52, Lefteris Tsintjelis wrote: >>> Would be great to consider its future adoption and if possible to take it >>> even further to interact with postscreen. >> Why would this be a good thing for postfix to do? >> There are already plenty of tools that generate block lists for the various >> types of firewalls out there, and they do not require patching postfix. >> SSHGuard and Fail2Ban are two that seem to work very well. > > SSHguard is similar but only for ssh, not for postfix. SSHGuard can be used to block anyone who tries to get into your system. It is not limited to SSH. It even can work without a firewall. > Fail2ban and equivalent log parsers are just too resource hungry, No they aren't. > messy and more time consuming to maintain Sounds like you are parting some false information others fed you. There is nothing to maintain, and they run silently and take no time at all. > blacklistd is offering simplicity, central management, extreme speed compared > to any log parser with minimal resources. There is no comparison really > between log parsers and balcklistd or SSHguard. If you say so. I've used both shgiard and fail2ban and have had no complaints or issues once they are configured. And they both offer a variety of configuration options. -- When we woke up that morning we had no way of knowing that in a matter of hours we'd changed the way we were going. Where would I be now? Where would I be now if we'd never met? Would I be singing this song to someone else instead?
Re: Blacklistd interaction
On 4 May 2019, at 15:52, Lefteris Tsintjelis wrote: > Would be great to consider its future adoption and if possible to take it > even further to interact with postscreen. Why would this be a good thing for postfix to do? There are already plenty of tools that generate block lists for the various types of firewalls out there, and they do not require patching postfix. SSHGuard and Fail2Ban are two that seem to work very well. -- Love seekest only self to please, To bind another to its delight Joys in another's loss of ease And builds a hell in Heaven's despite!
Re: How "safe" is reject_unknown_helo_hostname?
On 28 Apr 2019, at 03:00, Allen Coates wrote: > On 27/04/2019 23:21, @lbutlr wrote: >> >> smtpd_helo_restrictions = permit_mynetworks, reject_invalid_helo_hostname, >>reject_non_fqdn_helo_hostname, check_helo_access >>pcre:/etc/postfix/helo_checks.pcre permit > I usually put my access-control lists EARLY, so I have yes / no / > "further-processing" options The rejects are very cheap (practically free) while processing the pcre file takes more resources. My thinking is the order is less stressful. I doubt it really makes a difference, but old habits... (I did remove permit_mynetworks, here and everywhere. All is good.) -- "These are my rules, I make 'em up." ~George Carlin
Re: Sporadic, repeated connections from aws
On Apr 27, 2019, at 20:15, Noel Jones wrote: > > I still use the fqrdns.pcre too, and I can't remember the last false negative > when it rejected good mail. Thanks. That’s what I suspected, but confirmation is good to have. -- This is my signature. There are many like it, but this one is mine.
Re: How "safe" is reject_unknown_helo_hostname?
On Apr 27, 2019, at 21:13, Bill Cole wrote: > > I keep permit_my_networks out of my postfix config entirely Thanks. I keep meaning to look into doing that, but then I don’t seem to get around to it. My mail server isn’t on a LAN IP, so that doesn’t apply. I’ll keep looking at logs to see if maybe valid-seeming servers are getting dropped. -- This is my signature. There are many like it, but this one is mine.
Re: How "safe" is reject_unknown_helo_hostname?
On 27 Apr 2019, at 14:28, Bill Cole wrote: > On 27 Apr 2019, at 15:28, TG Servers wrote: > >> But you mean to keep reject_non_fqdn_helo_hostname and >> reject_invalid_helo_hostname, right? > > Yes but as part of smtpd_helo_restrictions with a substantial > check_helo_access map ahead of them which has a bunch of OK entries I don't have any before but permit_my_networks. smtpd_helo_restrictions = permit_mynetworks, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, check_helo_access pcre:/etc/postfix/helo_checks.pcre permit grep -i reject /var/log/mail.log | grep -o "helo=<.*>" | sort -u results in a list of servers I am pretty sure I don't want mail from, including a lion's share from the .live TLD ad some hangers-on from .top. What sort of checks do you have ahead of reject_invalid_helo_hostname and reject_non_fqdn_helo_hostname? > because Sturgeon's Law applies to the set of all mail admins. Heh. There is that, I suppose. -- Twentieth century? Why, I could pick a century out of a hat, blindfolded, and come up with a better one.
Re: How "safe" is reject_unknown_helo_hostname?
> On 27 Apr 2019, at 13:40, Bill Cole > wrote: > > On 27 Apr 2019, at 15:23, @lbutlr wrote: > >> Do you still see connections from hotmail.com mail servers? > > That depends on what you mean by "hotmail.com mail servers." > I see a lot of traffic from servers authorized by the SPF record for > hotmail.com. I don't believe any of those use 'hotmail.com' in their EHLO. I > see a few per month which use unresolvable (in the moment) EHLO names. Yes, thanks for the confirmation, that's what I was checking for. I believe the hotmail.com domain has been entirely retired as a source of mail. It was a bit of a garbage fire for many years and I knew many admins who were very angry about hotmail, enough so that even mail from a hotmail.com email address is pretty rare anymore (I have 13 emails from a hotmail address this year in my personal/list accounts, a third of them from one person). -- We will fight for Bovine Freedom and hold our large heads high We will run free with the Buffalo or die
Sporadic, repeated connections from aws
I've had the following in my fqrdns.pcre checks for quite awhile:
/^ec2(-[12]?[0-9]{1,2}){4}\.compute-[0-9]\.amazonaws\.com$/ REJECT Generic -
Please relay via ISP (amazonaws.com)
And I have noticed that I frequently get a series of 50 or more connection
attempts from some aws server out there in a burst (50+ connections in a few
minutes).
Fine, everything is working as it should with my settings, the connection is
dropped right away (although the REJECT is not logged).
Am I right in blocking these connections? Is there any reason for an aws server
to be sending mail directly that I am overlooking?
(the fqrdns.pcre file is a file I downloaded several years back and have made
occasional modifications too, so I am not sure if this was something I added or
part of the original file, though I suspect the latter)
--
And what rough beast, its hour come round at last,
Slouches towards Bethlehem to be born?
Re: unable to find user
> On 27 Apr 2019, at 09:06, Matus UHLAR - fantomas wrote: > > On 27.04.19 09:04, @lbutlr wrote: >> I am using postfix => spamass-milter => SpamAssassin and I get occasional >> errors like these. >> >> spamd: handle_user (userdir) unable to find user: 'virtualuser' >> >> For example, if I have a virtual user "john" who redirects to the local user >> jsmith, I get that error with the username of "john" while mail to jsmith >> goes through fine. >> >> Is it possible to send the user name to the milter after virtual maps have >> been applied? > > spamass-milter has the "-x" option which should do just what you want. I just > haven't tested it with postfix yet Thank you, I don't know how I missed that in the man page. I assume I glazed by it as it specifically mentioned sendmail, which i don't use (but then of course, postfix provides a sendmail-like binary, so doh) It seems to be working. -- What are you, Ghouls? There are no dead students here. This week.
unable to find user
I am using postfix => spamass-milter => SpamAssassin and I get occasional errors like these. spamd: handle_user (userdir) unable to find user: 'virtualuser' For example, if I have a virtual user "john" who redirects to the local user jsmith, I get that error with the username of "john" while mail to jsmith goes through fine. Is it possible to send the user name to the milter after virtual maps have been applied? -- Battlemage? That's not a profession. It barely qualifies as a hobby. 'Battlemage' is about impressive a title as 'Lord of the Dance'. I'm adding Lord of the Dance to my titles.
Re: How "safe" is reject_unknown_helo_hostname?
On 25 Apr 2019, at 17:56, Allen Coates wrote: > I have been looking at the configuration parameter > "reject_unknown_helo_hostname", with a view to using it to resist spam. I don't think that's going to be helpful enough to make up for the legitimate messages you will lose. Not all senders have a valid hostname. You might try it with a warn_if_reject directive and see how many hits you get, but I think you'll find it rejects too much mail you want. -- Where there is a party, everyone is there Everyone will leave at exactly the same time When this party is over it will start again But not been any different be exactly the same
Re: Big problem with this mailing list and Majordomo regarding DMARC
On 19 Apr 2019, at 23:04, Peter wrote: > But this is just one example of where a header might be signed and then is > later added or altered by the mailing list, The only headers that mailing lists often alter are subject (though i think that is dying off, hopefully) and the only non-list-mumble header they add generally is sender. Ig you are signing a non-existent sender in a message to a list, that is a mistake. If you are adding a sender header to a message to a list and signing with that header, that is a mistake. Or, you can insist you are right and break list messages. Your call. -- Major Strasser has been shot. Round up the usual suspects.
Re: How to allow the milter first access to recipients?
On 18 Apr 2019, at 13:15, ecsd wrote: > > The logs show that postfix examines the recipients before the milter is given > the chance to see them. > I have a milter that detects certain RCPT patterns harassing a domain name > and will discard (not bounce) the mail, > but that code cannot be reached because postfix will bounce for a bad > recipient before the milter sees anything, > and /all/ bad-recipient email is bounced. That is undesirable. No, postfix does not bounce bad recipients, it rejects them. Yes, these are different, yes the difference is important. I cannot imagine a scenario in which rejecting bad emails is a bad idea, so I'm failing to see the problem. > Is there a way to put the milter first in examining email? I'm going to guess the answer is essentially no? I mean, you could disable all of postfix's checking and rely just on your milter, but that seems like a plan destined to blow up big time. -- "You never really understand a person until you see things from his point of view, until you climb inside of his skin and walk around in it."
Re: possible to reach hardenize's requirements?
On 13 Apr 2019, at 00:57, Dominic Raferd wrote: > I too find that hardenize complains about my STARTTLS without any details as > to why. Like @lbutlr (and most of us) I offer STARTTLS on port 25 but not > AUTH. However I see this message in my log after the test ran, I think > hardenize is hitting my server too hard and maybe that is why it is (wrongly) > saying there is a problem with the server: > > 2019-04-13 07:36:23 streamingbats postfix/smtpd[19724]: warning: Connection > rate limit exceeded: 31 from outbound.hardenize.com[18.233.176.231] for > service smtp Checking my logs: postfix/smtpd[45229]: connect from outbound.hardenize.com[18.233.176.231] postfix/smtpd[45229]: SSL_accept error from outbound.hardenize.com[18.233.176.231]: -1 postfix/smtpd[45229]: lost connection after STARTTLS from outbound.hardenize.com[18.233.176.231] postfix/smtpd[45229]: disconnect from outbound.hardenize.com[18.233.176.231] ehlo=1 starttls=0/1 commands=½ -- It's better to burn out than it is to rust -- Neil Young as quoted be Kurt Cobain
Re: possible to reach hardenize's requirements?
> On 12 Apr 2019, at 10:42, micah anderson wrote: > > "@lbutlr" writes: > >> On 12 Apr 2019, at 08:46, micah anderson wrote: >>> he site https://hardenize.com provides relatively decent Email reports, >>> along with other reports. It checks a number of things including certs, >>> MTA-STS, TLS-RPT, DANE, SPF, DMARC, and then also TLS. These are all >>> good checks and recommendations, with the exception of the TLS one, I do >>> not see how its possible to meet their standards, and provide an email >>> server on the internet. However, I could be wrong, so I'm interested to >>> know if I am. >> >> I'm not impressed. It complains that STARTTLS is not available on my server. >> It is true it is not available on port 25, ut is available on port 587 where >> it should be. > > Since they are not testing submission, this seems correct. It is not correct to classy this as a warning. > You have disabled STARTTLS on port 25 and only accept unencrypted > connections there? Actually, no. STARTTLS is on port 25 for servers, but hardenize reports it's not available, which for some reason this morning I thought was an indication it was testing it as a login feature. I do not allow logins on port 25. I've since closed the window on hardenize, so I can't easily check what the specific warning text was. -- Reality is not a matter of opinion.
Re: possible to reach hardenize's requirements?
On 12 Apr 2019, at 08:46, micah anderson wrote: > he site https://hardenize.com provides relatively decent Email reports, > along with other reports. It checks a number of things including certs, > MTA-STS, TLS-RPT, DANE, SPF, DMARC, and then also TLS. These are all > good checks and recommendations, with the exception of the TLS one, I do > not see how its possible to meet their standards, and provide an email > server on the internet. However, I could be wrong, so I'm interested to > know if I am. I'm not impressed. It complains that STARTTLS is not available on my server. It is true it is not available on port 25, ut is available on port 587 where it should be. -- What was it they said about gods? They wouldn't exist if there weren't people to believe in them? And that applied to everything. Reality was what went on inside people's heads. --Moving Pictures
Re: SPF and Greylisting
On 5 Apr 2019, at 09:11, Viktor Dukhovni wrote: > Note that you SHOULD NOT ultimately refuse email on SPF softfail, > but greylisting would be OK, if you find it meets your needs. Is grey listing still effective? I know when I stopped using it it was not doing much of anything and I can't imagine it's gotten more effective. -- Lisa Bonet ate no Basil
Re: Authentication attempts for x...@com.au addresses
On 2 Apr 2019, at 14:30, Esteban L wrote: > The times are in seconds, so you'll need to calculate those times. a month is 2629743 seconds. An hour, of course is 3600, but I prefer 86400 which is one day. BTW, pi seconds is very close to 1 nano century. -- <[TN]FBMachine> I got kicked out of Barnes and Noble once for moving all the bibles into the fiction section
Re: pishing from ME
On 24 Mar 2019, at 09:32, Michael wrote: > header CUST_DMARC_FAIL Authentication-Results =~ /mydomain\.com; dmarc=fail/ > score CUST_DMARC_FAIL 4.0 Have you checked this against your spam? You're going to have a lot of problems with a score of 4.0, I expect. -- "Some cause happiness wherever they go; others, whenever they go.." - Oscar Wilde
Re: pishing from ME
On 22 Mar 2019, at 19:45, Bill Cole
wrote:
> Do not accept mail claiming to be from any address in a local domain on the
> port 25 (smtp) smtpd service. Only accept such mail via port 587 (submission)
> and 465 (smtps) services configured to require authentication.
And the way to do this is:
/etc/postfix/sender_access.pcre:
/^@/550 Invalid address format.
/[!%\@].*\@/ 550 This server disallows weird address syntax.
/@kreme.com$/ 450 Spoofing local domain?
/^postmas...@kreme.com$/ 550 Don't Spoof as my postmaster
/^postmaster\@/ OK
/^hostmaster\@/ OK
/^abuse\@/ OK
main.cf:
smtpd_recipient_restrictions = {stuff} check_sender_access
pcre:$config_directory/sender_access.pcre, permit
This very rarely triggers for me because mail gets rejected by the previous
criteria in nearly all cases:
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination,
reject_non_fqdn_sender, reject_non_fqdn_recipient,
reject_unknown_sender_domain, reject_invalid_hostname,
reject_unlisted_recipient, reject_unlisted_sender,
reject_unknown_reverse_client_hostname, warn_if_reject
reject_unknown_client_hostname, check_recipient_access
hash:$config_directory/recipient_access, check_sender_access
pcre:$config_directory/sender_access.pcre, permit
Re: Understanding the importance of submission
On 21 Mar 2019, at 06:50, Bill Cole wrote: > Requiring authentication to relay on *ANY* port is essential. Even if you do > authentication by IP (e.g. permit_mynetworks) or other out-of-band > mechanisms, failing to require authentication to relay will eventually lead > to a system being abused as an open relay. And will probably result in the mail server being blacklisted as an open relay before that even happens, since there are various machines out there that do nothing but test for open relays. The take-away is that one should consider authentication on submission an absolute requirement. -- Come on. Somewhere at the edge of the bell curve is the girl for me.
Re: Permanent store of incoming mail.
On 20 Mar 2019, at 15:40, Patrick Ben Koetter wrote: > Or, if you use dovecot as storage, create a second dovecot instance and dsync > messages from first to second instance. This is a much better solution in terms of features and making that alternate mailspool available. Mine is better in terms of being dead simple to implement, though it is probably more fiddly to maintain. If all you need to do is store the mail for some bureaucratic reason, that's the one I'd use. If you need to be able to let users, for example, recover lost mails from the backup spool or search it or anything much beyond letting it sit their until it expires, then yeah, I'd do what you suggest instead. -- They say only the good die young. If it works the other way too I'm immortal
Re: Permanent store of incoming mail.
On 20 Mar 2019, at 15:06, Homer Wilson Smith wrote: >Pointers to RTFM > >Running Centos 7.x, latest postfix. > >What is the best way to keep a permanent store for > incgoing e-mail. Doesn't have to be forever. 1 year perhaps. I use recipient_bcc_maps -- 'The trouble with my friend here is that he doesn't know the difference between a postulate and a metaphor of human existence. Or a hole in the ground.' --Pyramids
Re: "Chunk exceeds message size limit"
On 19 Mar 2019, at 13:00, Viktor Dukhovni wrote: > Note that, perhaps unintentionally, the treatment of "message_size_limit > = 0" is not documented to mean "no limit". Perhaps we should also > address that. By forbidding a setting of 0? -- 'They're the cream!' Rincewind sighed. 'Cohen, they're the cheese.'
Re: Howto reject only one recipient and not drop entire email?
On 18 Mar 2019, at 06:40, Otto Kekäläinen wrote: > How can I configure Postfix so that _only_ malformed addresses are not > delivered to the next SMTP host, while the rest of the recipients in > the same email/To/CC/BCC are delivered as usual? What you are asking for will deliver mail to people with invalid email addresses in the headers. this seems like a bad idea. -- It was easy to be a vegetarian by day. It was preventing yourself from becoming a humanitarian at night that took the real effort.
Re: intermittent sasl auth fails?
On 17 Mar 2019, at 15:47, @lbutlr wrote: > On 17 Mar 2019, at 05:40, li...@sbt.net.au wrote: >> (both domains are valid, tld.com as well as tld.com.au) > > both are valid in your lookup table? Have you checked this with postman? postmaP (sorry, spelling correcting one wild) -- Stone circles were common enough everywhere in the mountains. Druids built them as weather computers, and since it was always cheaper to build a new 33-Megalith circle than to upgrade an old slow one, there were generally plenty of ancient ones around --Lords and Ladies
Re: intermittent sasl auth fails?
On 17 Mar 2019, at 05:40, li...@sbt.net.au wrote: > (both domains are valid, tld.com as well as tld.com.au) both are valid in your lookup table? Have you checked this with postman? -- 'There has to be enough light,' he panted, 'to see the darkness.'
Re: Postfix stable release 3.4.2
Please stop sending this nonsense to the list. > On 10 Mar 2019, at 17:21, Francesc Peñalvez wrote: > > * > 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. > ***
Re: Question on Relay Host conf
> On 7 Mar 2019, at 20:52, Ozy Mate wrote: > > Dear Friends, > > I have signed up with a 3rd party smtp server as relay host. This server > needs the following lines in the main.cf of our server instead of relayhost > direction: > > smtp_sender_dependent_authentication = yes > sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay > smtp_sasl_auth_enable = yes > smtp_sasl_security_options = noanonymous > smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd > > This is working fine. However, all the senders/domains not listed in > sender_relay file are still able to send emails directly from our email > server. How can I block this? I mean sender not listed in sender_relay file > should not be able to send any email from our Postfix server. Nothin that you posted would indicate you're taken steps to prevent this. sender_dependent_relayhost_maps is just what it says, sender_dependent, so it only applies to the senders you've specified. What have you done for the rest of the senders? -- Far away, across the fields, the tolling of the iron bell calls the faithful to their knees to hear the softly spoken magic spells.
Re: postscreen_dnsbl_action "drop" not working correctly?
On 05 Mar 2019, at 13:50, Mayhem wrote: > I also have nginx/apache and sql running on the same dedicated machine, There will use much more of your system that all of postfix, including your dovecot (or whatever), and the DNS lookups are a minuscule portion of what postfix does. My very low-spec machine occasiaonly sees a single IMAP process as high as 0.12% and master might be at 0.05%. Heck, my logging system used more resources than Postfix does. CPU: 0.5% user, 0.0% nice, 0.6% system, 0.0% interrupt, 98.9% idle Try running top -Sz (or top -c a, depending on your system.top version) on your system and see what is using a lot; bet you find it is perl (assuming you are running spamassassin). -- "Let's get back to syntax of procmail and forget the syntax of fools.” Don
Re: postscreen_dnsbl_action "drop" not working correctly?
On 05 Mar 2019, at 10:00, Dominic Raferd wrote: > Fail2ban is (as you know) a way to tackle it. At 1000 connections a day I don’t think fail2ban or sshguard or whatever is going to save you anything at all. Hundreds of thousands? Maybe? -- Suddenly the animals look shiny and new
Re: Is there any way to add whitelist to ranges or ips domains so that dnsbl are skipped?
On 4 Mar 2019, at 02:55, Francesc Peñalvez wrote: > > Gmail has its ips stuck in almost all dnsbl spam and for that reason I do not > receive any mail from gmail Really? I've haven't found gmail servers to be in RBLs in a long time and wouldn't use a RBL that listed gmail servers. What lists are you using? And how are you using them? If you are blocking gmail servers based on RBLs, then that's on you, you put them there. postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.[2..255]*5 list.dnswl.org=127.0.[0..255].0*-2 list.dnswl.org=127.0.[0..255].1*-3 list.dnswl.org=127.0.[0..255].2*-4 list.dnswl.org=127.0.[0..255].3*-5 -- It's Tchaikovsky's 'Another One Bites the Dust'," said Crowley, closing his eyes as they went through Slough.
Re: Unexpected directories in virtual_mailbox_base
On 01 Mar 2019, at 07:21, Thomas Seilund wrote: > -- Once a day for each user I clear the bayes files and rebuild bayes files > with: You are removing the bases entries daily and rebuilding them based on a very few (if any) messages in your LaernAs folders? That’s the same as not using bayes at all. -- "...Life is not a journey to the grave with the intention of arriving safely in one pretty and well-preserved piece, but to slide across the finish line broadside, thoroughly used up, worn out, leaking oil, and shouting GERONIMO!!!" -- Bill McKenna
Re: downgrading from postfix-3.4 fails - unix-dgram
> On 1 Feb 2019, at 01:19, Eray Aslan wrote: > > Downgrading from postfix-3.4 fails with: What exactly do you mean by "Downgrading? And how, exactly, did you attempt to do this? > 3.3.2/image//usr/share/man/man8/virtual.8... > bin/postconf: fatal: invalid type field "unix-dgram" in "postlog unix-dgram > n - n - 1 postlogd" looks like unix-gram is unknown in postfix 3.3.2? Is downgrading a supported action? Is this a postfix issue or a ports/apt-get issue? -- Can I borrow your underpants for 10 minutes?
Re: Blocked by yahoo.com
On 30 Jan 2019, at 16:26, Philip wrote: > had this exact issue when I first started warming up the IP I was sending my > company email from. Any email going to a Yahoo server you need to throttle > heavily as if you try and send to much too quickly you will get your IP > blocked. I "solved" this issue a long time ago by rejecting all mail to or from Yahoo. When they connect to my server they get a failure notice that I don't accept connections from a company that leeks 3 billion people's passwords. There's been no fallout from this at all, other than I know some people have abandoned yahoo.com because of it. I do not trust yahoo one bit, and I won't allow them on my network. Long before I decide to blacklist them, they were absolutely horrible anyway. A constant stream of spam and malware, no response to enquiries, and making persona mail from users in the yahoo serf's mailbox as spam for reasons no one could ever explain The only company nearly as bad was rr.com, whom I also blacklisted. periodically I check my logs to see what is going on and I am happy to report I see very few connections form Yahoo and, as I expect, they are all obvious spam. May not work for anyone else, but it works for my server. -- When you come to the fork in the road, take it
Re: Postfix vs. OpenSSL on Debian "buster".
On 24 Jan 2019, at 18:07, Viktor Dukhovni wrote: > This may be especially important with submission, where various > peripheral devices (fax-to-email, printers, ...) may only support > TLSv1. So the "buster" system-wide default of TLSv1.2 and up may > cause problems. The least likely to be patched most likely toe hacked mail clients. Hmmm. -- 'The trouble with my friend here is that he doesn't know the difference between a postulate and a metaphor of human existence. Or a hole in the ground.' --Pyramids
Re: Postfix logging without syslogd
On 21 Jan 2019, at 22:13, Viktor Dukhovni wrote: > 12. The version numbering scheme for Berkeley DB changed from a > five-part number to a three-part number of the form > ... This release is numbered 18.1.x, Do you know why the current version in FreeBSD ports is 6.2.32_1? (or the older db5 is still current as well) -- Can I borrow your underpants for 10 minutes?
Re: Assistance to protect from spam flood
On 12 Jan 2019, at 07:52, Nick Howitt wrote: > Unfortunately I don't have access to the MX Backup service. It is provided by > my DNS provider. Honestly, you should not have an MX server outside of your control. If your server is routinely down for several days, then you shouldn't be running your own server. -- The reaper does not listen to the harvest. --Reaper Man
Re: Postscreen concurrency limits
On 20 Dec 2018, at 11:08, Viktor Dukhovni wrote: > Viruses can come from any source. OK, But I am pretty sure I’ve never seen a virus from mail chimp. I don’t have a large enough load to worry about not scanning, but if I did the first thing I would stop scanning is gmail incoming and the large remailers like mail chimp as they both are highly motivated not to send viruses. Granted, since most my mail accounts use Macs, I care a lot less. -- Honesty may be the best policy, but it's important to remember that apparently, by elimination, dishonesty is the second-best policy.
Re: dnsbl postscreen - not blocking
On 20 Dec 2018, at 06:46, Kai Schaetzl wrote: > Using Sorbs is dangerous, anyway, we abandoned it years ago. If you want > to use it then use it in the way it is intended for weighted RBLs. e.g. do > not use it as the sole source of blocking. I keep parring down my list and am considering going to simply using zen only for blocking and dnswl for whitelisting. Something like zen.spamhaus.org=127.0.0.[4..11]*5 zen.spamhaus.org=127.0.0.[2..3]*1 list.dnswl.org=127.0.[0..255].0*-2 list.dnswl.org=127.0.[0..255].1*-3 list.dnswl.org=127.0.[0..255].2*-4 list.dnswl.org=127.0.[0..255].3*-5 And a threshold of 3. None the others seem to be particularly effective. -- Truth is seen through keyholes
Re: Postscreen concurrency limits
On 18 Dec 2018, at 16:58, Viktor Dukhovni wrote: > The solution is perhaps in part to throw some more CPU at the > problem, but alternatively, assuming that mailchimp et. al. > are not abusing reasonable concurrency limits, you can reduce > the impedance mismatch by increasing the input latency, by > doing the A/V scan "on-line' via a milter. Am I wrong in thinking that doing an A/V scan on mail from Mailchimp and/or cosntantcontact is a waste of time? They are not sending viruses. Hell, they are not even sending spam. -- What the hell's goin' on in the engine room? Were there monkeys? Some terrifying space monkeys maybe got loose?
Re: Problem with filter
> On 13 Dec 2018, at 20:05, Paul Schmehl wrote: > > --On December 13, 2018 at 9:00:06 PM +0100 Benny Pedersen > wrote: > >> Paul Schmehl skrev den 2018-12-13 20:45: >> The user does not exist until "ls -l" is able to correctly identify the files as belonging to the user. >>> >>> Hmmm...thank you, Victor. I'll try to sort that out. >> >> if its more simple, change to use spampd so spamassassin is smtp content >> filter seen from postfix >> >> its have being rock solid for me, and i only use clamav-milter for virus >> scanning, and opendmarc, opendkim, spf-policyd, thats all i need :=) > > That's what I've been doing, but apparently my /etc/passwd file is screwed up. I had a similar issue when I moved from 10.x to 11.x where a user account line in the passwd field was mangled in some minor way and it cause the rest of the passed file to not be processed. I do not recall the details, but I think on UID was changed from something like 1015 to 115? So, look at the passwd file and move the ‘filter’ user earlier in the file, If that fixes it, you can then use the id command to check each UID later in the file to narrow down where the problem is. -- "A politician is a man who approaches every problem with an open mouth.”
Re: New install - Temporary lookup failures when trying to send
> On 6 Dec 2018, at 02:00, Matus UHLAR - fantomas wrote: > >> On Mon Dec 03 2018 04:27:43 Matus UHLAR - fantomas >> said: >>> pleaase, get a decent MUA, not applemail that tries to encode everything as >>> internet links (and messes up thge plaintext version of mail). > > On 04.12.18 13:47, @lbutlr wrote: >> What do you base this statement on? I’ve been using Apple’s Meal.app since >> around 2003 or so, and I’ve never had it encode everything as Internet >> links more mess up plaintext mail. > > based on sender's > X-Mailer: Apple Mail (2.3445.102.3) > > and the result I have quoted that is also visible on: > > https://marc.info/?l=postfix-users&m=154380074926895&w=2 > > the HTML parts may be encoded properly, but the plaintext version of sent > mail contains useless crap where > > > > is converted to: > > mailto:jlbr...@bordo.com.au>> > > and: > > mail.bordo.com.au > > is converted to: > > mail.bordo.com.au <http://mail.bordo.com.au/> But I have never seen Mail.app (neither my own nor someone else's) do that. It is far more likely that the problem lies in something the poster has done than in a program used by about a billion people across macOS and iOS. -- THERE WAS NO ROMAN GOD NAMED "FARTICUS" Bart chalkboard Ep. 5F06
Re: New install - Temporary lookup failures when trying to send
On 5 Dec 2018, at 07:34, Bill Cole wrote: > On 2 Dec 2018, at 20:31, James Brown wrote: > >> I’m trying to set up a new mail server on macOS Mojave and it almost works. >> Dovecot for IMAP is working. > > This is a bad idea. Mojave (like High Sierra and Sierra before it) is unfit > for server duty due to the intentional mangling of logging by Apple. Without > proper logs, detecting subtle problems is difficult and troubleshooting any > blatant problem like this is impossible. Apple's logging is not mangled, it is simply using a different logging method. All the information is there, it's just harder (well, harder for me) to get to. However, you can easily do some pretty complex queries against it (as I understand it). But I thought we were talking about Apple Mail.app *sending* mail? > You can get something like a proper mail log by running this command > persistently (i.e. using launchd or batch or whatever else works...) > > log stream --info --predicate 'senderImagePath CONTAINS "postfix"' --style > syslog >> /var/log/mail.log > > That will give you useful information in a standard-ish format in > /var/log/mail.log. > > Without such logging, it is infeasible to troubleshoot your problem. Well, it is feasible because you can query the logs anytime you want (using collect will even generate a log file for your query across the whole logging system without having to go searching trough many files). That said, I don't use my Macs as servers. postfix runs on FreeBSD. Apache runs on FreeBSD. MySQL runs on FreeBSD. Etc. # log show --info --start "2018-12-06 16:00:00" --end "2018-12-06 16:45:00" --predicate 'senderImagePath CONTAINS "sshd" AND messageType=info' --style syslog Filtering the log data using "senderImagePath CONTAINS "sshd" AND logType == 1" Timestamp (process)[PID] 2018-12-06 16:17:28.311749-0700 localhost sshd[1649]: Connection closed by 130.162.96.208 port 18696 [preauth] 2018-12-06 16:20:14.692208-0700 localhost sshd[1822]: Did not receive identification string from 63.143.42.244 port 10643 2018-12-06 16:25:14.528760-0700 localhost sshd[2100]: Did not receive identification string from 63.143.42.244 port 17916 2018-12-06 16:30:14.586075-0700 localhost sshd[2378]: Did not receive identification string from 63.143.42.244 port 33134 -- A bartender is just a pharmacist with a limited inventory.
Re: client incorrect greeting error, how to resolve?
On Wed Dec 05 2018 05:24:33 Voytek said: > > so if I have 25 clients on a NATed LAN, that's my connection count limit, > isn't it ? No. -- 2+2=5 for sufficiently large values of 2.
Re: New install - Temporary lookup failures when trying to send
On Mon Dec 03 2018 04:27:43 Matus UHLAR - fantomas said: > > pleaase, get a decent MUA, not applemail that tries to encode everything as > internet links (and messes up thge plaintext version of mail). What do you base this statement on? I’ve been using Apple’s Meal.app since around 2003 or so, and I’ve never had it encode everything as Internet links more mess up plaintext mail. -- "A musicologist is a man who can read music but can't hear it." - Sir Thomas Beecham (1879 - 1961)
ClamAV-milter
Trying to configure clamav-milter with postfix-current-3.4.20181105,5 under
FreeBSD 11.2-RELEASE, but I’ve missed something since no mail is actually
getting processed by ClamAV-milter, including the EICAR test mails which sail
through without triggering anything.
I’ve tried to provide everything that could be relevant (mostly in an effort to
re-examine everything) but at this point I’m stumped.
smtpd_milters =
unix:/var/run/spamass-milter.sock,
unix:/var/run/clamav/clmilter.sock
# sockstat | grep milter
root spamass-mi 24145 4 stream /var/run/spamass-milter.sock
clamav clamav-mil 59293 3 stream /var/run/clamav/clmilter.sock
# gnc /usr/local/etc/clamav-milter.conf
MilterSocket /var/run/clamav/clmilter.sock
FixStaleSocket yes
User clamav
PidFile /var/run/clamav/clamav-milter.pid
ClamdSocket unix:/var/run/clamav/clamd.sock
OnInfected Quarantine
LogFile /tmp/clamav-milter.log
LogFileUnlock yes
LogFileMaxSize 20M
LogTime yes
LogSyslog yes
LogFacility LOG_MAIL
LogVerbose yes
# clamscan -I eicar.txt
eicar.txt: Eicar-Test-Signature FOUND
# psa clamav
clamav 56889 0.0 14.3 553736 505868 - Is Sun17 4:03.54
/usr/local/sbin/clamd
clamav 57990 0.0 0.1 12268 5280 - Is Sun17 0:28.11
/usr/local/bin/freshclam --daemon -p /var/run/clamav/freshclam.pid
clamav 59293 0.0 0.1 2 4540 - Ss Sun17 0:02.39
/usr/local/sbin/clamav-milter -c /usr/local/etc/clamav-milter.conf
# ls -lsR /var/run/clamav/
total 48
8 drwxr-x--- 3 clamav postfix 512 Nov 28 08:57 .
8 drwxr-xr-x 15 rootwheel1024 Nov 28 09:11 ..
8 -rw-rw-r-- 1 clamav clamav6 Nov 25 17:44 clamav-milter.pid
8 -rw-rw-r-- 1 clamav clamav6 Nov 25 17:44 clamd.pid
0 srw-rw-rw- 1 clamav clamav0 Nov 25 17:44 clamd.sock
0 srwxrwxrwx 1 clamav clamav0 Nov 25 17:44 clmilter.sock
8 -rw-rw 1 clamav clamav6 Nov 25 17:44 freshclam.pid
8 drwx-- 2 clamav clamav 512 Nov 24 11:57 quarantine
/var/run/clamav/quarantine:
total 0
# tail clamav/clamd.log clamav/freshclam.log
==> clamav/clamd.log <==
Wed Nov 28 07:47:29 2018 -> Database correctly reloaded (6722408 signatures)
Wed Nov 28 07:57:53 2018 -> SelfCheck: Database status OK.
Wed Nov 28 08:08:30 2018 -> SelfCheck: Database status OK.
Wed Nov 28 08:21:53 2018 -> SelfCheck: Database status OK.
Wed Nov 28 08:33:50 2018 -> SelfCheck: Database status OK.
Wed Nov 28 08:44:55 2018 -> SelfCheck: Database status OK.
Wed Nov 28 08:55:38 2018 -> SelfCheck: Database status OK.
Wed Nov 28 09:06:16 2018 -> SelfCheck: Database status OK.
Wed Nov 28 09:16:44 2018 -> SelfCheck: Database status OK.
Wed Nov 28 09:28:14 2018 -> SelfCheck: Database status OK.
==> clamav/freshclam.log <==
--
Received signal: wake up
ClamAV update process started at Wed Nov 28 07:47:03 2018
main.cvd is up to date (version: 58, sigs: 4566249, f-level: 60, builder:
sigmgr)
Downloading daily-25161.cdiff [100%]
daily.cld updated (version: 25161, sigs: 2163162, f-level: 63, builder: neo)
bytecode.cld is up to date (version: 327, sigs: 91, f-level: 63, builder: neo)
Database updated (6729502 signatures) from database.clamav.net (IP:
104.16.185.138)
Clamd successfully notified about the update.
———
There is nothing in any other logs about clamav.
So it seems like it is installed and running. Freshclam has updated
successfully.
--
"How good bad music and bad reasons sound when we march against an
enemy." - Friedrich Nietzsche
===
function psa () {
ps auxww | grep -i $* | grep -v grep
}
alias gnc='grep -v "^\($\|#\|\/\)" '
Re: Convert quoted-printable headers
On 24 Nov 2018, at 14:37, Richard Damon wrote: > If you might be using characters beyond an 8-bit character set, then UTF-8 is > the best way to go. If there is even the slightest possibility that you will be using characters beyond the basic *7* bit character set, I would say that UTF-8 is the best choice because there is no code-table issue with UTF-8. We’ve all seen messages (or web pages) munged because something assumes a specific code page. That doesn’t happen with UTF-8. Thankfully there are fewer and fewer places where UTF-8 doesn’t work, though it looks like mail headers will be 7 bit until the heat death of the universe. -- No taxation without misrepresentation.
Re: Error on make of the latest 3.3.1 source at dict_db.c
On 8 Nov 2018, at 01:18, Robert Chalmers wrote: > Hi, I can see what the error message says . But I confess at this moment, I’m > at a loss as to how to fix it? > Where is it looking for this db? Postix used Berkely db for hash tables (files end in .db) nosema,ly the virtual file and the alias file: # file etc/postfix/*.db etc/postfix/aliases.db: Berkeley DB 1.85 (Hash, version 2, native byte-order) etc/postfix/virtual.db: Berkeley DB 1.85 (Hash, version 2, native byte-order) You probably have an different version installed that postfix is expecting. How did you build postfix? -- THERE WAS NO ROMAN GOD NAMED "FARTICUS" Bart chalkboard Ep. 5F06
Re: A better way to do secure SMTP
On 01 Nov 2018, at 13:48, Alice Wonder wrote: > Opportunistic TLS is a concept I do not like. DANE fixes the issues for > system admins willing to implement DNSSEC and add a TLSA record but it seems > many are not, so MTA-STS was invented. > > MTA-STS has the same flaw as opportunistic TLS. It uses an insecure channel > to determine if it should use a secure channel. Since the MTA tp MTA communication does not involve secure information like logins, passwords, etc, there is no issue with either opportunistic TLS nor with using an insecure channel to determine if security should be used. After all, if the encryption fails, the mail is sent in the clear. -- It was a fifty-four with a mashed up door and a cheesy little amp with a sign on the front said "Fender Champ" and a second-hand guitar it was a Stratocaster with a whammy bar
Re: Enabling TLSv1.2 support in postfix 2.8.2
On 25 Oct 2018, at 05:11, Ralph Seichter wrote: > Please don't try to spread your personal misjudgement as gospel, It is not mine, but thanks for playing. -- So now you know the words to our song, pretty soon you'll all be singing along, when you're sad, when you're lonely and it all turns out wrong…
Re: TLSv1.2 only for auth connection
On Oct 25, 2018, at 15:04, @lbutlr wrote: > Authentication port 25 is often simply opportunistic Sorry. I meant to type encryption, not authentication. -- This is my signature. There are many like it, but this one is mine.
Re: TLSv1.2 only for auth connection
On Oct 25, 2018, at 06:08, Thomas Bourdon wrote: > > My goal : All auth connections must be done with tlsv1.2 minimum. Others > connections can be done with tlsv1.0 minimum. This is fine. Authentication port 25 is often simply opportunistic and does not imply identify, only securing the data transfer. You could even allow SSL an poet 25 as long as you force submission to your TLSv1.2 connection on 587 or 466. -- This is my signature. There are many like it, but this one is mine.
Re: Enabling TLSv1.2 support in postfix 2.8.2
On Oct 24, 2018, at 09:19, Benny Pedersen wrote: > > do not disable tlsv1 I couldn’t disagree more. TLSv1.2 has been out for a decade and there is no reason to be running v1 or v1.1. At all. I’ve been running with TLSv1.2 only for over a year. -- This is my signature. There are many like it, but this one is mine.
Re: check if envelope from and from is the same
On 04 Oct 2018, at 00:00, Tobi wrote: > if your auth senders spoof from headers: block their login account and > terminate their service Nothing necessarily wrong with spoofing From: noreply@ is a spoofed From: >> we're running a small smtp send only service for authenticated users >> only. Even though we only accept allowed combinations of authenticated >> user and pre-defined envelope from addresses with access_maps, some >> smartasses started to spoof From: addresses so we got bad reputation at >> receiver sites. I don’t think that’s how it works. >> Is this a good idea to check if envelope from and from matches Not especially. I wouldn’t use a service that did that. -- And Super Heroes come to feast To taste the flesh not yet deceased And all I know is still the beast is feeding.
Re: BCC to a local account
On 21 Sep 2018, at 10:07, Stephen Carville wrote: > Add a procmail recipe One of these days, and a joyous day it will be, someone is going to take up the mantle of procmail maintainer and rewrite it to be modern, fast, and stable, No no, I hear your protests, but it's going to happen. Someday. (totally random, but oddly appropriate, signature follows) -- The thing standing in the way of your dreams is that the person having them is *you* https://xkcd.com/1027/
Re: Patch: eliminate postfix-script warnings about symlinks
On 06 Sep 2018, at 12:19, Luc Pardon wrote: > However, although symlinks inside the Postfix dirs were not needed in > the past, that has changed by now. They have become necessary because > OpenSSL needs them to find its certificates, so we can't just tell the > admin to get rid of them. The way I deal with certs is that when the cert renews, it fires off a post script that copies the certs to the places it needs to be. Symlinking seems to fail more often than not due to permission issues anyway. -- '(...) And the Patrician has been ironical at me,' said Mr. Clete. 'I'm not having that again.’
Re: Blocking spammers who spoof From: addresses from my domain
> On 13 Aug 2018, at 06:28, Bastian Blank > wrote: > > On Mon, Aug 13, 2018 at 05:19:18AM -0600, @lbutlr wrote: >> On 12 Aug 2018, at 17:29, Stuart Longland wrote: >>> We have a problem where some smart-arse spammers/phishers are spoofing >>> the From address, specifying our domain as their from address. In one >>> case, the person in question uses my personal address in the From, To >>> and Return-Path. In others, they pretend to be a scanner sending a >>> supposedly "scanned document". >> >> Don’t accept mail from local users coming from a foreign server? >> That’s what I do. > > Header vs. envelope. You should know that. What un my post gives you the impression that I don’t know that? > A mail with your e-mail in the From header comes from the mailing list. That doesn’t describe the OP, where which from is being spoofed was not specified. -- In other news, Gandalf died. -- Secret Diary of Boromir
Re: Blocking spammers who spoof From: addresses from my domain
On 12 Aug 2018, at 17:29, Stuart Longland wrote: > We have a problem where some smart-arse spammers/phishers are spoofing > the From address, specifying our domain as their from address. In one > case, the person in question uses my personal address in the From, To > and Return-Path. In others, they pretend to be a scanner sending a > supposedly "scanned document". Don’t accept mail from local users coming from a foreign server? That’s what I do. -- 99 percent of lawyers give the rest a bad name.
Re: is possible modify the source address based on the subject?
On 07 Aug 2018, at 04:53, Wietse Venema wrote: > Maybe some Procmail rule can do all this. I don't use Procmail. You can, with enough staples and duct tape, do *anything* in procmail. However, it is old, krufty, not under development<1>, has several bugs, doesn’t understand mime, and I don’t recommend it to anyone. All said, I’m still using it. <1> Last update was in 2001, site is dead. -- There is a road, no simple highway, between the dawn and the dark of night
Greylisting (Was Re: Fall back to relay after [some] 5XX repl[ies] from destination?)
On 07 Aug 2018, at 04:49, Luc Pardon wrote: > but in any case it serves no useful purpose (unlike greylisting, SAV, etc. Are people still finding grey listing to be useful? I found it caused far more problems than it solved and the endless game of scanning logs for sites like Amazon that resend from different machines or many banks that will never resend was time consuming and tedious. -- If lawyers are disbarred and clergymen defrocked, doesn't it follow that electricians can be delighted, musicians denoted?
Re: TLS not offered by host
On 1 Aug 2018, at 11:59, Viktor Dukhovni wrote: >> status=deferred (TLS is required, but was not offered by host > > Here, the "level" is "none". The remote site did not support STARTTLS. Ah. Yes, that makes sense, it just didn't occur to me a server in 2018 would do that, I figured it just had crappy security levels. Thanks. >> smtp_tls_security_level = encrypt > > The last of these is too strict as a default for all domains. Yes, probably, but on the other hand, two servers in the last week, and one of those is a 'web board reply" discourse email, and those are janky at the best of times anyway. > The sensible settings are either "may", or if you have a local (loopback) > validating resolver, "dane" (see TLS_README for details). > >> tls_preempt_cipherlist = yes >> tls_ssl_options = no_ticket, no_compression > > Why do you disable session tickets? There was a reason, I think. But most of these settings have been there for years, so I should revise that. I want to say it was a recommendation from dovecot list? (I last modified main.conf when I moved to postfix 3.x. -- Silence filled the University in the same way that air fills a hole. Night spread across the Disk like plum jam, or possibly blackberry preserve. But there would be a morning. There would always be another morning. --Sourcery
TLS not offered by host
When connecting to a server that does not offer TLS (or the right level) does postfix log (or can it) the level of security that was offered? status=deferred (TLS is required, but was not offered by host (I get very few of these (two servers in the last week), but I'd like to be able to tell the admin of the server what low-level security they are offering). my smtp_tls* settings: smtp_tls_exclude_ciphers = MD5, aDSS, kECDH, kDH, SEED, IDEA, RC2, RC5 smtp_tls_loglevel = 1 smtp_tls_security_level = encrypt and tls_preempt_cipherlist = yes tls_ssl_options = no_ticket, no_compression -- Angie, Angie, when will those clouds all disappear? Angie, Angie, where will it lead us from here? With no lovin' in our soul and no money in our coats You can't say we're satisfied But Angie, Angie--You can't say we never tried
Re: Open Relay on local lan
On 24 Jul 2018, at 11:31, Software Information wrote: > Recently though, auditors made a deal that the server is an open relay. Based on the rest of this thread, it sounds very much like the auditors are incompetent. I mean, not knowing what an open relay is is concerning.
Re: Defer mail instead of bounce
On 28 Jun 2018, at 16:10, li...@mbchandler.net wrote: > I agree about the nameserver, but unfortunately I don't have a choice. I'm > required to use this one. Explain to the non-technical person mandating this, possibly using very small words, why the will result in lost mail. Your initial post is a good starting point o explain this persons error in thought. DNS servers that lie about DNS are not usable DNS servers. Reporting NXDOMAIN for valid domains is what is known as "a lie" and things will break. -- I got a question. If you guys know so much about women, how come you're here at like the Gas 'n' Sip on a Saturday night completely alone drinking beers with no women anywhere?
Re: Blocking TLDs with check_sender_access
On Jun 26, 2018, at 09:10, Viktor Dukhovni wrote: > No, it works substantially better in check_sender_access, and very poorly > in header_checks. It works very well for me, and has for years. -- This is my signature. There are many like it, but this one is mine.
Re: Blocking TLDs with check_sender_access
On 25 Jun 2018, at 14:45, Alex wrote: > I have a check_sender_access restriction that blocks many TLDs like > .red and .space. Problem is that we have one legitimate .red customer > (what was he thinking?) that needs to send us mail. How can I allow > this single domain? I use header checks: /.*\.example.top/ DUNNO /.*\.FriendwithJokeDoamin.xxx/ OK /.*\.(com|net|org|edu|gov|ca|mx|de|dk|fi|uk|us|tv|info|biz|eu|es|il|it|nl|name|jp|host|au|nz)$/ DUNNO /.*\.*/ 550 Mail to or from this TLD is not allowed But this should basically work much the same in check_sender_access red 500 This TLD sends spam good.red DUNNO -- A bartender is just a pharmacist with a limited inventory.
Re: available: multiple deliveries per TLS-encrypted connection
On 18 Jun 2018, at 12:08, Wietse Venema wrote: > Wuetse Ah, Mondays! -- Is it my imagination, or do buffalo wings taste like chicken?
Re: your mail
On 5 Jun 2018, at 02:22, Matus UHLAR - fantomas wrote: > in postyfix queue each mail does have its unique ID. However, when pushed > through any kind of content filter, the ID changes. > Also, when mail gets forwarded, the ID changes. A new ID will be ADDED, but the original one remains in the headers, at least for filters. Received: by mail.covisp.net (Postfix, from userid 58) id 410Ptl2kC1zbRcb; Tue, 5 Jun 2018 02:22:39 -0600 (MDT) Received: from russian-caravan.cloud9.net (russian-caravan.cloud9.net [168.100.1.4]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.covisp.net (Postfix) with ESMTPS id 410Ptj3CtMzbRbb for ; Tue, 5 Jun 2018 02:22:37 -0600 (MDT) The top header is after spamd with a new ID and the bottom shows the initial ID after it was received by my mail server. It's not an issue to get the 'right' ID from the header, depending on which ID you consider the right one. -- The hippo of recollection stirred in the muddy waters of the mind.
Re:
On 4 Jun 2018, at 14:34, Greg Strange wrote: > I am trying to track a single email throughout the entire postfix process. > The idea is that when a customer calls us and says that a certain email never > reached them, we can quickly trace the email through the logs and see that it > died due to RBL, virus threshold, etc. I send a daily mail report to the very few users who are super paranoid about missing mail. Each day they get a report that shows all the messages that were rejected, and all the messages that were accepted. the accepted email has the QueueID in the table, and the rejected emails show the IP and helo name that was rejected. It's not very efficient, but it's good enough for the handful of those who want it.
Re: Emails from localhost
On 03 Jun 2018, at 16:08, Proxy wrote: > I'm confident that CentOS security team does a good job providing latest > security patches RedHat releases including those related to Postfix. Are you under the impression that CentOS is writing security patches for obsolete and unsupported versions of Postfix? That is not the case. There is a big difference between bleeding edge and obsolete, and you are firmly in the obsolete (as in not support, not patched, not secure) camp. The last update to 2.6 was over 5 years ago (Feb 2014) and that is a significantly newer version that you are running (Mar 2010). -- 'They were myths and they were real,' he said loudly. 'Both a wave and a particle.' --Guards! Guards!
Re: [Postfix] Question about disabling SSLv2 and SSLv3 and Opportunistic TLS
On 29 May 2018, at 11:57, Viktor Dukhovni wrote: > The collation rules for "en_US" are abominable. I always set: > > LC_CTYPE=en_US.UTF-8 LANG=C Yep, strongly agree with this. I foolishly had LANG=en_US some time back thinking it was sensible. It is not. Everything breaks.
Re: Question about disabling SSLv2 and SSLv3 and Opportunistic TLS
On 2018-05-29 (02:35 MDT), Dirk Stöcker wrote: > > Do you maybe also have a command to show only changed parameters? This is doable, but it takes a bit more processing than a single line. Basically, a shell script that parses the output of join <(postconf -n) <(postconf -d | sed 's/=/(default:/; s/$/)/') | grep -v "(default:)" and filters it with the output of comm -1 -2 <(postconf -n) <(postconf -d) as Stefan provided. I mean, it's probably possible in awk, but then again, what isn't? I do have one question that I've never noticed before. The settings for mydomain and myhostname show that they are at the default values. Where is postfix getting the defaults for this and does it mean the settings really aren't needed unless your hostname is, for some reason, different? (Not sure I could bring myself to not specify them). - Because you can't cotton to evil. No Sir. You have to smack evil on the nose with the rolled-up newspaper of justice and say, 'Bad evil. Bad BAD evil"'
Re: Question about disabling SSLv2 and SSLv3 and Opportunistic TLS
On 2018-05-28 (11:26 MDT), Viktor Dukhovni wrote: > > join <(postconf -n) <(postconf -d | sed 's/=/(default:/; s/$/)/') That's nifty! -- "you'd think you could trust a horde of hungarian barbarians"
Re: advice on postscreen setup / exception / dnsbls
On 26 May 2018, at 23:27, Voytek wrote: > On Sun, May 27, 2018 3:22 am, /dev/rob0 wrote: > >> The obvious solution, if dnsbl.spfbl.net is blocking real mail, is to >> stop using that list, or possibly to lower its score below your [unstated] >> threshold score. > > Thanks for all replies and comments! > > I guess my starting point should be that, lower the score ? No, your starting point should be to not use an RBL if you don’t know what it is doing. Blacklisting a domain for not having a valid rDNS is something you can do right in postfix, without needing to reach out to an RBL. reject_unknown_reverse_client_hostname or reject_unknown_client_hostname, but these have significant impact on some server for legitimate mail. You can search the archives (or google) for various discussions on these two settings, how they differ, and which you might want to use, if either. > postscreen_dnsbl_sites = zen.spamhaus.org*5, psbl.surriel.com*2, > bl.spamcop.net*2, dnsbl.spfbl.net*2, > db.wpbl.info, dnsbl.dronebl.org, pofon.foobar.hu, > bl.ipv6.spameatingmonkey.net*2,dnsbl6.anticaptcha.net, > bl.spameatingmonkey.net*2, bl.mailspike.net, b.barracudacentral.org*2, > dnsbl.sorbs.net, ubl.unsubscore.com, truncate.gbudb.net, > list.dnswl.org*-3, zz.countries.nerd.dk=127.0.3.58*-1 Treating all replies from the RBLs as the same is, IMHO, a mistake. This is what I have: postscreen_dnsbl_threshold = 9 postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.[4..11]*9 hostkarma.junkemailfilter.com=127.0.0.2*5 zen.spamhaus.org=127.0.0.[2..3]*4 hostkarma.junkemailfilter.com=127.0.0.3*2 hostkarma.junkemailfilter.com=127.0.2.1*4 hostkarma.junkemailfilter.com=127.0.2.2*2 hostkarma.junkemailfilter.com=127.0.0.2*4 hostkarma.junkemailfilter.com=127.0.1.2*4 hostkarma.junkemailfilter.com=127.0.0.1*-4 hostkarma.junkemailfilter.com=127.0.0.5*-2 hostkarma.junkemailfilter.com=127.0.2.3*-2 For example, I score zen differently for 127.0.0.2-3 (much lower) than for 4-11. (.2 is the SBL which hits more ‘false’ positives than the other for my mailstream and .3 is similar) while 4-11 are server that should never be sending mail (DHCP ISP machines, exploited servers, etc). I *do not* recommend you copy/paste these into your setup. For one thing, I haven’t evaluated them in quite a while since zen hits nearly everything that gets blocked, so I’m not really sure how the downstream ones are performing right now, but mostly because every server is a bit different. -- Like the moment when the brakes lock/And you slide towards the big truck/You stretch the frozen moments with your fear
Re: Question about disabling SSLv2 and SSLv3 and Opportunistic TLS
On 26 May 2018, at 12:59, Benny Pedersen wrote: > just kidding, i would like to see main.cf smaller, so postconf -n gives more > settings as default from -d > > as it is now setting is more or less random default from main.cf > > keep main.cf minimal is good sense I’m not sure what you mean, the only things you need to put in main.cf are settings that differ from the defaults. At a minimum you need maybe 20-30 lines? My postconf -n is 102 lines, and I suspect some of those could be eliminated if I went through and check the defaults (that is, the defaults would be close enough). Some of the settings probably date from when the mail server was on a T1 and I did some rate limiting and such and could be updated or eliminated. Now, I suspect that there are some defaults that should be updated (swap_bangpath allow_percent_hack are two that spring to mind) but I suspect there are reasons they haven’t. At least it looks like those two would never realistically come into play on a modern install, based on the restriction on rewrite in postfix 2.2, so it is quite possible there is no need to change these defaults at all. It might be useful, but probably not, to have a version of postconf -n that showed the default value along sinde the changed value: mailbox_size_limit = 52428800 (5120) This is a setting I could easily eliminate as the difference between my setting ant the default is much closer than I thought it was, and it’s irrelevant on my setup because postfix doesn’t write a mailbox file. The only reason I’d need to change it is if I increased the message_size_limit beyond the 25MB it is set to currently, and that’s not going to happen. -- Secret to a happy relationship: when you're wrong, admit it. When you're right, shut up.
Re: Question about disabling SSLv2 and SSLv3 and Opportunistic TLS
On 2018-05-26 (10:59 MDT), /dev/rob0 wrote: > Perhaps this could be reworded to be less confusing? Since "-d" > doesn't look at main.cf, s/main.cf/"Postfix internal"/? I dunno, I think "Print main.cf default parameter settings instead of actual settings." is very clear. -- We will fight for Bovine Freedom and hold our large heads high We will run free with the Buffalo or die
