Re: Black magic rejecting header Subjects
Lukas, On 8/4/2009 1:02 AM, Lukas Ruf wrote: On Monday 03 August 2009 15:34:59 Lukas Ruf wrote: I cannot understand why Postfix/cleanup rejects particular Subject lines, since I have been searching for the respective regexps but haven't found what I've been looking for. My question is simple: why are subject lines rejected that I cannot find definitions for? Probably because they match expressions in your undisclosed [!!] file of header_checks(5). Please find attached the header_checks file currently in use: When I comment the line in main.cf header_checks = pcre:/etc/postfix/header_checks.pcre everything works for me as expected. Thus, I strongly assume there must be a bug somewhere in the definitions Thanks for your support! wbr, Lukas This header_checks file is out of control. It rejects many perfectly reasonable Subjects: $ postmap -q 'Subject: I need a hand please' \ pcre:/tmp/map REJECT $ postmap -q 'Subject: for election news' \ pcre:/tmp/map REJECT Your question re: matching 'ferte e': $ postmap -q 'Subject: ferte e' pcre:/tmp/map REJECT <--- matched HERE whiche come from (the modified): /^Subject: .*F.R.E.E/ REJECT <--- matched HERE Spend some time learning about REs. And consider instead of this monstrosity header_checks file a content filter or other more sufficient means. If you must use header_check rules, include unique identifiers at the end of your REJECTs so that you can find which ones hit. See example with < HERE above. See: http://www.postfix.org/header_checks.5.html http://www.postfix.org/access.5.html http://www.postfix.org/CONTENT_INSPECTION_README.html
Re: How to read maillog
Velvet Pixel wrote: > > A grep of smtp returns two types of entries. A postfix/smtp and a > postfix/anvil. > > When I grep the ID of a sample of each they look like this: > > postfix/smtp: > Jul 29 20:14:11 vps postfix/smtp[21650]: A85225A08723: > to=<[EMAIL PROTECTED]>, > relay=gmail-smtp-in.l.google.com[209.85.199.27]:25, delay=1.2, > delays=0.02/0.06/0.09/1, dsn=2.0.0, status=sent (250 2.0.0 OK 1217387662 > k2si695106rvb.4) You are seeing: - message queue id - the recipient (to), - relay (in this case, remote MTA), - time delay(s), - delivery status notification (2.0.0 = successful delivery, 4xx = tmp reject, 5xx = perm reject) - status of message (sent, bounced, deferred) - remote mta's reply (250 ...) > > postfix/anvil: > Jul 29 21:11:31 vps postfix/anvil[17821]: statistics: max connection > rate 1/60s for (smtp:81.12.170.122) at Jul 29 21:04:42 > Jul 29 21:11:31 vps postfix/anvil[17821]: statistics: max connection > count 1 for (smtp:81.12.170.122) at Jul 29 21:04:42 > Jul 29 21:11:31 vps postfix/anvil[17821]: statistics: max cache size 2 > at Jul 29 21:08:09 > These are anvil's stats. Anvil is used for rate control. See man anvil. > There are quite a few of the anvil types of entries. Are they just > connection attempts that were denied but not successful? No, not denied. You're seeing the max rate of connections, and count of connections, and the client that hit the max rate shown. Eg: client 81.12.170.122 connected at most 1 per 60 seconds, and connected at most 1 time simultaneously. > > The postfix/smtp type seem accurate for what should be the results of > what is being sent by my system so is that the correct info to keep an > eye on if I want to make sure my system is not sending anything it > shouldn't? > > Thanks :) > Cameron Smith >
Re: How to read maillog
Velvet Pixel wrote: > I think I understand what anvil is now. > > So to be clear, all listings in postfix/anvil are clients trying to > connect to use my system to send and has nothing to do with messages > received (such as spam) by my system or is it both? > Right, clients connecting to your system. See log lines such as: ... postfix/smtpd[26704]: connect from example.com[10.0.0.1]
Re: How to read maillog
Velvet Pixel wrote: > > Whoa that's a lot of unauthorized people trying to connect! If you run a publicly available mail server, you've authorized the world connect. > Is it normal to have tons of unauthorized connect attempts in this > wonderful world of spammers looking for a hole? Yes sadly, and yes. > I have hundreds of groupings like this which add up to thousands of > attempts per day: Isn't mail fun. > > Jul 29 10:42:05 vps postfix/smtpd[28365]: warning: 91.196.61.254: > hostname vpn-91.196.61.254.uch.net verification failed: Name or service > not known > Jul 29 10:42:05 vps postfix/smtpd[28365]: connect from > unknown[91.196.61.254] > Jul 29 10:42:07 vps postfix/smtpd[28365]: 011185A087AC: > client=unknown[91.196.61.254] > Jul 29 10:42:09 vps postfix/smtpd[28365]: disconnect from > unknown[91.196.61.254] > > Should I just ignore these or is there something I can do to block them? > Post output from postconf -n and you'll get lots of good feedback about how to configure your anti-spam measures. MrC
Re: mail delivery via alternate IP gateway
Luigi Rosa wrote: > mouss said the following on 31/07/08 09:02: > >> so you also need to play with "advanced" routing to make sure the >> packets go out of eth2. > > Such as? > > I just need a hint on what I have to search in the documentation, either > Postfix or Linux. What do you mean with "advanced" routing? > Hint: iproute2 http://lartc.org/howto/index.html > > Ciao, > luigi >
Re: Postfix header_checks and Lsoft listserv
Jim McIver wrote: > My header_checks file contains: > # Disallow sender-specified routing. This is a must if you relay mail > #for other domains. > /[EMAIL PROTECTED]@]/ 550 Sender-specified routing rejected > This seems prone to many false positives. Many headers have such patterns. Eg: X-Amavis-OS-Fingerprint: Linux 2.4-2.6 (NAT!) (firewall!) (up: 815 hrs), From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Perhaps you need to be more restrictive, matching only a particular header, and allow for valid email addresses as above.
Re: Attachments with email from command line?
Uwe Dippel wrote: > Aside of hacks, I *think* that it might make sense to have a non-hacked > solution. As system administrators, we, at least I, send quite a number > of items with mail (cronjobs). > Therefore, IMHVHO, a tool distributed with *nix or *fix (wrapping around > mail) might be useful? > > Uwe man mutt nail NAME mutt - The Mutt Mail User Agent SYNOPSIS mutt [-nRyzZ] [-e cmd] [-F file] [-m type] [-f file] mutt [-nx] [-e cmd] [-a file] [-F file] [-H file] [-i file] [-s subj] [-b addr] [-c addr] addr [...] mutt [-n] [-e cmd] [-F file] -p mutt -v[v] DESCRIPTION Mutt is a small but very powerful text based program for reading electronic mail under unix operating systems, including support color terminals, MIME, and a threaded sorting mode. OPTIONS -a file Attach a file to your message using MIME. ... Name nail - send and receive Internet mail Synopsis nail [-BDdFintv~] [-s subject] [-a attachment ] [-c cc-addr] [-b bcc-addr] [-r from-addr] [-h hops] [-A account] [-S variable[=value]] to-addr . . . nail [-BDdeHiInNRv~] [-T name] [-A account] [-S variable[=value]] -f [name] nail [-BDdeinNRv~] [-A account] [-S variable[=value]] [-u user] Description Nail is an intelligent mail processing system, which has a command syntax reminiscent of ed(1) with lines replaced by messages. It is based on Berkeley Mail 8.1, is intended to provide the functionality of the POSIX nail command, and offers extensions for MIME, IMAP, POP3, SMTP, and S/MIME. Nail provides enhanced features for interactive use, such as caching and disconnected operation for IMAP, message threading, scoring, and filtering. It is also usable as a mail batch language, both for sending and receiving mail. The following options are accepted: -A name Executes an account command (see below) for name after the startup files have been read. -a file Attach the given file to the message.
Re: Unknown SASL Authentication
Asai wrote: > Greetings, > > In the server log files I got back this morning, I see in the records > this entry: > > 1Unknown >1 Unknown >1218.30.101.41unknown > > > Normally this will give me an email address on top, the AUTH type next, > and the IP at the bottom with the reverse DNS there. I checked the IP > address and it's in China, so it's definitely not one of our users. Can > anyone tell me how to interpret this, and to plug any holes which might > be allowing this? > This looks like partial postfix-logwatch output. Show the log line in question, and the Section header from where this output came. [ edit: I see you've already shared log lines ] I believe this is the SaslAuthRelay section. The first level is the SASL sender (and user if available). The second level is the SASL method (or Unknown if not available). The third level is the host IP and the Postfix reported host name (in this case, it was unknown). But, your entry discovered a bug in the parsing of the sasl_sender= portion of smtpd's client= log line. The output should look like: 1 SASL authenticated relayed messages -- 1 [EMAIL PROTECTED] (*unknown) 1 *unknown 1218.30.101.41unknown I've corrected the bug in 1.37.08: http://www.mikecappella.com/logwatch/ MrC
Re: Unknown SASL Authentication
mouss wrote: > MrC a écrit : >> [snip] >> But, your entry discovered a bug in the parsing of the sasl_sender= >> portion of smtpd's client= log line. The output should look like: >> >>1 SASL authenticated relayed messages -- > > This may be misleading. something like "claimed SASL sender" would be > "more clear"? You're right as usual mouss - thanks for the clarification. I recall reading the RFC some time ago, but I wasn't clear about the circumstances for the use of sasl_sender. I'll update for the next release. Thanks > >>1 [EMAIL PROTECTED] (*unknown) >>1 *unknown >>1218.30.101.41unknown >> >> I've corrected the bug in 1.37.08
Re: Confirmation of TLS/SASL operation?
Victor Duchovni wrote: > > It is interesting to see an MUA negotiate an anonymous session. Clearly > T-Bird did not care to ask for or verify the server certificate. Did > it require special configuration to enable this, or is this default > T-Bird behaviour? I see the same in my logs - default setup + submission port. Oct 21 22:00:53 glacier postfix/smtpd[2914]: Anonymous TLS connection established from zion.mikecappella.com[10.0.0.10]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) > > When I added support for anonymous TLS ciphers in Postfix, I expected > these to mostly get used in MTA-to-MTA opportunistic TLS sessions. >
