Re: need help with honeypot
On Thu, Oct 19, 2023 at 09:05:56AM +0300, kasak wrote: > In traps file I have list of spoiled addresses for example aa...@tvema.ru > But mail is not accepted :( This sounds like you are more or less trying to imitate the greytrapping feature of OpenBSD spamd. You might want to read this article of mine (gosh, it's been 11 years) and links therein for inspiration: https://bsdly.blogspot.com/2012/05/in-name-of-sane-email-setting-up-spamd.html (also newly available trackerless but with even uglier formatting as https://nxdomain.no/~peter/in_the_name_of_sane_email.html), assuming, as usual that your system runs OpenBSD (also applicable with minor adjustments on FreeBSD or NetBSD) - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
smtpctl spf walk chokes on macros - is it possible to work around this?
Watching indly while I run the script that refreshes my nospamd data[1] I see
several occurences of messages like
processing verticalresponse.com
smtpctl: lookup_record: %{i}._spf.mta.salesforce.com contains macros and can't
be resolved
digging through the dig $domain txt output turns up the salesforce.com record is
_spf.salesforce.com.3512IN TXT "v=spf1
exists:%{i}._spf.mta.salesforce.com -all"
is there a way to shoehorn this into something useful in our context?
All the best,
Peter
[1] Described in
https://bsdly.blogspot.com/2018/11/goodness-enumerated-by-robots-or.html
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: unable to send mail from desktop mail client to remote email addresses
On Wed, Oct 02, 2019 at 11:33:58PM -0700, Kevin wrote: > Hi all, > > Having just followed the setup instructions on Gilles HOWTO page here: > > > https://poolp.org/posts/2019-09-14/setting-up-a-mail-server-with-opensmtpd-dovecot-and-rspamd/ > > > ...I'm unable to send mail from my new OpenSMTPD server on OpenBSD 6.6-beta > (OpenBSD 6.6-beta (GENERIC) #320: Mon Sep 30 21:24:24 MDT 2019); however, > other deliveries (and mail retrieval) work. > > The pertinent log message looks like this: > > Oct 2 23:21:33 mx smtpd[25067]: bf1c57bab7fcd344 smtp envelope > evpid=2c41c5fc4a7e6c06 from= to= > Oct 2 23:21:33 mx smtpd[25067]: bf1c57bab7fcd344 smtp disconnected > reason=quit > Oct 2 23:21:38 mx smtpd[25067]: bf1c57b6b057c6ef mta error > reason=Connection timeout Connection timeout sounds very much like your machine is not allowed to send outgoing mail via SMTP. Check for firewalls and the like. Also, [Thu Oct 03 09:24:37] peter@skapet:~$ host example.app Host example.app not found: 3(NXDOMAIN) [Thu Oct 03 09:24:43] peter@skapet:~$ host mx.example.app Host mx.example.app not found: 3(NXDOMAIN) Among the things you need in order to deliver mail, a valid domain is in the top few. I think the basic requirements are indeed listed in the article (under "Requirements"), please go back and re-read, check that you have all of those set up properly. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Report Domain: dotbit.ro Submitter: fastmail.com Report-ID:2018.10.15.155619520
To me it looks like the fastmail site sees mail purporting to be from your domain but coming from 212.83.129.132 which is not in your SPF record as an allowed sender. What you could be seeing here is that a mailing list is configured to do traditional forwarding (which breaks with SPF enabled, sorry). I unfortunately see a lot of that. The other possibility is that what is getting reported is an attempt at a joejob or similar such as sending with a made up user name in hour domain but this report like most DMARC reports disregard local-parts (usernames) so it's hard to tell. There are ways to configure mailing lists to not trigger SPF/DMARC reports like this, but AFAIK it will need to be done on a per-list basis and for that reason is kind of a hassle for list admins. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Reject Senders by IP address - SMTPD
On Fri, Sep 28, 2018 at 08:30:55AM +, Antonino Sidoti wrote: > table shithole file:/etc/mail/blacklist > > The file ‘blacklist’ contain the IP addresses that I wish to block, one per > line. I also have added a reject statement to my ‘smtpd.conf’ like so; > > reject from source for any > > What I notice is that it does not block the IP address and it continues to > attempt a connection to the mail server. The IP address in question is > showing up in ‘/var/log/maillog’ like so; > > Sep 28 18:22:12 obsd-svr3 smtpd[68949]: b6ab24ef369520cc smtp > event=failed-command address=185.xxx.xxx.254 host=185.xxx.xxx.254 > command="AUTH LOGIN" result="503 5.5.1 Invalid command: Command not supported” > > Any idea why the reject statement does not work? Well, the mail does get rejected, doesn't it? it's possible that a simple pf.conf with a table you block from, fed from the file you already have would be the solution your're looking for. Perhaps supplemented with a spamd(8) setup. a couple of writeups of mine that you might find useful: https://bsdly.blogspot.com/2017/04/forcing-password-gropers-through.html https://bsdly.blogspot.com/2013/05/keep-smiling-waste-spammers-time.html It's also possible that the enumerated badness from https://bsdly.blogspot.com/2018/08/badness-enumerated-by-robots.html could usefully supplement your data sources. All the best, Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: How to deal with spam and opensmtpd
On Wed, Apr 18, 2018 at 08:44:19AM +, Mik J wrote: > I'm using Openbsd and Opensmtpd + Spamd. I have been able to reduce the spam. > However there are some marketing companies that constantly change their IPs > and pass through the greylisting, they really attempt to send the mail > (multiple times). > I looked at bogofilter and it looks nice.However I would like to know if > there's a way for opensmtpd to work with bogofilter.So that the mails can be > trashed or classified as spam. > First I read that bogofilter works at the user level, I'd like it to work at > the server mail level. > What other (not spamd and spamassassing) do you use ? I know you said not spamassassin, but please do take a peek at Aaron Poffenberger's BSDCan slides about a working OpenSMTPD setup with content filtering: https://github.com/akpoff/talks/tree/master/slides/2016/bsdcan_2016/2016_smtpd - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Fail2Ban filter for OpenSMTPD
On 06/17/17 11:57, mabi wrote: > Does anyone have a fail2ban filter for OpenSMTPD? > > I would like to block the many many AUTH LOGIN attempts as you can see > here from the logs: > > Jun 17 11:55:49 gw smtpd[594]: 7eeebcc95623efe1 smtp > event=failed-command command="AUTH LOGIN" result="503 5.5.1 Invalid > command: Command not supported" > Jun 17 11:55:52 gw smtpd[594]: 7eeebcc95623efe1 smtp event=closed > reason="io-error: Connection reset by peer" It's been a while since I tried to tweak fail2ban at all but as long as you're on OpenBSD or some other system with PF, it's fairly trivial to autoban such silliness via a cron job that greps for the noisemakers and add them to a table that's already referenced in a block rule. Examples in the most recent PF tutorial start at https://home.nuug.no/~peter/pftutorial/#44 and there is a oneliner that would be an easy starting point for adapting to your needs at the bottom of https://home.nuug.no/~peter/pftutorial/#46 - that one is taken from a cron job I run somewhere that will not ever need a wordpress install. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Failing to relay to gmail
On 10/18/16 20:16, Christian Kellermann wrote: > * Peter N. M. Hansteen [161018 18:01]: >> and, I recently discovered >> >> * a google-site-verification record with a key they've generated for >> your domain. > > And wth should one get this thing? Like the other items I mentioned, this one also has its own kind of DNS TXT record. The procedure involves going to Google's postmaster tools site, requesting a key they generate and then claim the domain there after you've updated your zone with that key in the required format. It looks to me like this popping up was essentially an admission that the SPF-DKIM-DMARC combo wasn't quite as effective as expected, and potentially a way for Google to identify domains that are expected to send larger than usual volumes of mail. Whether it actually achieves that or any other objective is anybody's guess. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Failing to relay to gmail
On 10/18/16 15:05, José Romildo Malaquias wrote: > I have been using opensmtp on gentoo linux for some time, but lately > relaying to GMail lis not working. > > The current version of opensmtp is 6.0.2p1. > > The log file of running > > # smtpd -vd 2>&1 | tee /var/tmp/smtpd.log > > and send a message with the command > > $ MSG="Test #43" && echo "$MSG" | mutt -s "$MSG" malaqu...@gmail.com > romi...@operamail.com gmail is fairly picky about quite a few things, so while this may or may not be related to your actual problem, but I'm pretty much convinced that gmail would bounce or possibly eat and discard that message unless * the IP address gmail sees as trying to deliver mail is one that matches operamail.com's SPF records. * the message has a DKIM signature that matches the published data * the domain has a valid DMARC record and, I recently discovered * a google-site-verification record with a key they've generated for your domain. Even with all those in place, gmail occasionally sees fit to bounce the ouput of the hourly cron job that exports my list of greytrapped addresses and reports on some related data, such as the ones in https://home.nuug.no/~peter/googlefail/ Thanks for reminding me that I will need to write this up in a nicer form sometime. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Greylisting
On 09/12/16 20:49, Silvio Siefke wrote: > On Sat, 10 Sep 2016 23:06:54 +0200 > Mischa Peters wrote: > >> Have a look at spamd. >> https://www.openbsd.org/spamd/index.html >> >> Also runs on non-OpenBSD. > > Yes spamassassin is running with amavisd-new. I think you may be confusing the OpenBSD spamd(8) program described at that URL with the program that comes with the spamassassin content-filtering system. They are two distinct and quite different programs, but it's more than possible for them to co-exist (even on the same machine if needed, they install to different paths) and they complement each other quite well in such setups. Yes, it is kind of unfortunate that two very different programs come with a binary with the same name, and it has lead to exactly that kind of confusion at times. If you're already using spamassassin, that's fine. If you put the OpenBSD spamd in default greylisting mode in front of spamassassin or other content filtering, the load on your content filtering will almost certainly go down significantly. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. signature.asc Description: OpenPGP digital signature
Re: Greylisting
On 09/10/16 19:10, Silvio Siefke wrote: > I search with google but I found nothing with greylisting and most about > spam is with shell scripts and pf. If all you've found is 'shell scripts and pf' I don't think you've looked very closely. As Mischa mentioned earlier, on OpenBSD and other OSes with PF there's spamd(8), which was (for example) quite capable of shielding all my users from the recent 'voicemail' scam using only its default greylisting (see http://bsdly.blogspot.com/2016/08/the-voicemail-scammers-never-got-past.html about that particular incident, links to other articles about spamd(8) greylisting and related topics therein). - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: spamd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/01/15 15:21, Craig Skinner wrote: > For google's bizzare random sending servers, you'll need to > increase spamd's greyexp time to 2+ days in /etc/rc.conf.local, > restart spamd & wait 2+ days. Either that or use the nospamd feature (see man 8 spamd and the rules example) and fill up the table from a useful source. I've accumulated some in my nospamd file which I make available at http://www.bsdly.net/~peter/nospamd, based on various episodes and some digging out of spf records (dig -ttxt domain.tld). A 2012 article of mine, newly updated: http://bsdly.blogspot.no/2012/05/in-name-of-sane-email-setting-up-spamd.html - - Peter - -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVvM4EAAoJELJiGF9h4Dyev3MQAKEpbOT5ciHkGxphuVyP4O+p MnyyOtjfk91+y5zOJKJhoTLCa903fzWUUN0gD1c/3EzmC7auctFFlJ1cQxi2DBjY u67653gXr8xKomd5C5IgHkyp591WsYpcy28xxv0zQUJYCdHNFEGQ2X+PiZ7eyCq8 q32IL/d1f6t2A2RoD4Tld+niqia6V4pgBi/0IgpmqZhI7iZSIWC7sAIk8yRw9HPo yAsz07T5d6egRjym48JDrayeeHGZJw173kterws6131IVNN1bgWWNbMhrrP2UCi9 Nz9gur4cHkoKwNu30vc2ovgVOS8YnHiW+DMso6O76NSsUF8gMrbsIwjuuGavTK1A wZkfzi8EGkCEOZ8c4gIeXzNQkEwn9C+B90SZ5iKWqx8p5bXnvgSjz57P74Qi8qBo 1Wiwxxd78Jw5pJ7aPC8iBDlGpp9+dtCdM4cUVZ7auxRoJAjiZi/e7lA5GI4gtaCt sD9WsqDKujYK3rd1FLCAR1ovu2hEyBTLcvHmR2e9XDsn37XvULzOPgQ7ZIadFAOY e2wX7lW5NS7jFynAPCLcd+V+7ZKAhoVdJkVzqqj1Zvrlr0tk/6+4XkAWv8ISGqul o7HMXb5HswAq2j3CfrbZvEgcEWprY1fIuKcNtRbQhuWUZ5PffV+hXdE4pujQaS9C KvuOO/220Lly2u4V+rqt =IKNb -END PGP SIGNATURE- -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Question
On Tue, May 19, 2015 at 09:10:59AM +0200, Gilles Chehade wrote: > OpenSMTPD does not support "bad rcpt throttling" as a specific mechanism > but supports a more generic "bad command throttling" where a bad command > is any command that has not helped moved the session forward. > > If you accumulate enough bad commands in a row and that your session has > not moved forward, you get kicked, which is a hard disconnect. > See bottom of this mail. > > Bad clients can then be blocked with a packet filter (just an example): > > pass inet proto tcp from any to any port smtp flags S/SA keep state \ > (max-src-conn 10, max-src-conn-rate 15/5, overload > flush global) On OpenBSD at least, it should also be possible to periodically run a script that parses smtpd logs for the IP addresses of misbehaving hosts and calls spamdb(8) to add those to spamd(8)'s local greytrap blacklist. In my setup I have some of that as well as automatic harvesting of bad addresses in the local domains for inclusion in the local traplist (see eg [1] and references therein). Also, for the bruteforce table members, I have accumulated some anecdotal evidence that 'block drop from probability 90%' may have them shut up faster than just your regular block drop (but further studies and data massaging are required for firm conclusions). [1] http://www.bsdly.net/~peter/traplist.shtml -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: pre-queue spam check
Joerg Jung writes: > I also know about spamd, but that is not really an option for now as the > server speaks v6 and STARTTLS, moreover I have legacy users which AUTH > on port 25 as well. This does not play well with spamd. spamd doesn't even attempt smtp auth, but then once the sender is whitelisted (as a valid sender should be), the problem would go away. Your regular and valid correspondents would not see spamd at all -- after all spamd is supposed to simply slow down the obvious spambots. In your scenario (as in most others) it's likely useful to explore the nospamd option, as in maintain a table of IP addresses or ranges that are simply never redirected to spamd. It's even in the spamd man page (first pf.conf ruleset example). - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: How can I stop this spammer?
On Tue, Feb 17, 2015 at 07:39:22AM +, Ultramedia Libertad wrote: > How can I stop this spammer?, you have filled my /var/log/maillog with your > logs > > > Feb 17 01:28:41 hosting-openbsd smtpd[10574]: smtp-out: Connecting to > smtp+tls://173.194.65.27:25 (ee-in-f27.1e100.net) on session > 9c66add9434290d1... > Feb 17 01:28:41 hosting-openbsd smtpd[10574]: smtp-out: Connected on > session 9c66add9434290d1 > Feb 17 01:28:42 hosting-openbsd smtpd[10574]: smtp-out: Started TLS on > session 9c66add9434290d1: version=TLSv1/SSLv3, > cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128 > Feb 17 01:28:42 hosting-openbsd smtpd[10574]: smtp-out: Server > certificate verification succeeded on session 9c66add9434290d1 > Feb 17 01:28:42 hosting-openbsd smtpd[10574]: smtp-in: Failed command > on session 9c66add4c2fd6a1e: "RCPT TO: " => 550 > Invalid recipient Assuming you're not actually running yahoo.com.tw's mail service and you run on a reasonably recent OpenBSD version, you could do worse than try to use spamd(8)'s mechanism for dealing with attempted relay-raping. Some ways down the spamd man page in the GREYTRAPPING section, you have The file /etc/mail/spamd.alloweddomains can be used to specify a list of domainname suffixes, one per line, one of which must match each destination email address in the greylist. Any destination address which does not match one of the suffixes listed in spamd.alloweddomains will be trapped, exactly as if it were sent to a spamtrap address. Comment lines beginning with `#' and empty lines are ignored. followed by some enlightening examples which contains some strings that have provoked comment by the so-inclined. TL;DR: list the domains you actually serve, one per line, any attemtped deliveries to other domains incoming on the interface where spamd listens will be greytrapped (blacklisted, stuttered at). It's a very useful addition to your spamd config if you're already using it, otherwise it's a good starting point. (for more fun & games with spamd and greytrapping, you can check out my blog - main url in the .signature). - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
