Re: www.postfix.org site appears to be down.

[LuKreme]

On Jul 3, 2021, at 00:53, Dominic Raferd  wrote:
> 
> On 03/07/2021 07:48, @lbutlr wrote:
>> When going to https://www.postfix.org I get, after an invalid certificate 
>> error,...

> The correct address is http://www.postfix.org (no https...)

Then it really should not be responding to https or redirecting it, no? 
Especially with the browsers starting to default to checking https and and 
others supporting extensions to check https first.

I’ll check when I get back to the computer. 

Re: Cloud9.net related responses

[LuKreme]

On Feb 12, 2021, at 06:54, Jaroslaw Rafa  wrote:
> 
> Maybe because people who send these use actual mailing list software for
> that?

Could be but I don’t consider marketing spam to be a mailing list and don’t 
consider list ids with dozens or hundreds of random-ish characters to be a 
legitimate list-ID. Ymmv, of course.

-- 
My main job is trying to come up with new and innovative and effective ways to 
reject even more mail. I'm up to about 99% now.

Re: Bounce mails manually

[LuKreme]

> You said in your message "lack of MX record", not "nullMX".

Read the entire thread?

>> postfix/smtp[53472]: 47yz7m5Jj2zg4gL: to=, relay=none, 
>> delay=0.29, delays=0.06/0/0.22/0, dsn=5.1.0, status=bounced (Domain 
>> hotmal.com does not accept mail (nullMX))

Re: Mail shows being queued, but not in queue

[LuKreme]

> On Dec 23, 2019, at 12:24, Mark ADAMS  wrote:
> Here is my config for postfix main.cf:
> 
> less main.cf

The correct command is postconf-n which lets people see the settings that are 
not default without having to wade through everything else.

There is no mention in the configuration you showed of dovecot at all, nor any 
transport maps, lmtp, or anything that would indicate you are using dovecot. It 
appears your mail is being stored as mbox files in /var/spool/mail/


-- 
My main job is trying to come up with new and innovative and effective ways to 
reject even more mail. I'm up to about 97% now.

Re: config check

[LuKreme]

On Dec 9, 2019, at 12:58, Viktor Dukhovni  wrote
> Please don't impute false crises.  There is no "security hole", though the
> configuration is a mess, unauthenticated loopback (and other "mynetworks")
> traffic is normal.

The configuration as posted, and specifically the line I quoted directly above 
my comment, allowed unauthenticated traffic from anything on the LAN. This 
means random printers, IOT devices, android phones, etc were allowed to send 
mail unchecked. I consider that a security hole.

Re: How to block mail coming from a domain

[LuKreme]

On Sep 26, 2019, at 03:51, Henrik K  wrote:
> Obviously these will only work for envelope sender.  Most likely needing
> header_checks /^From:.*\.monster/ here..

Yep. I use header checks to block most top level domains, letting only a dozen 
or so through and rejecting all the rest since it is impossible to keep up with 
all the new tlds and most of then are cesspits of spammer scum.


Or wretched hives of villainy, if you prefer.

Re: Hi.how to set up "bounce unix - - n - 0 bounce" by using Postconf

[LuKreme]

On Sep 26, 2019, at 00:18, feier8097  wrote:
> 
> The postfix system will return back an email with  subject "Undelivered Mail 
> Returned to Sender"

No, ALL mail servers will do this if they cannot deliver mail they accepted.

> But I don't want it send this message.

Then do not accept mail you cannot deliver or don’t run a mail server. 
Swallowing undelivered mail without notifications is an evil best left to 
companies like Verizon (which has done this in the past).

Re: Domain cannot be found?

[LuKreme]

On Aug 14, 2019, at 10:12, Matus UHLAR - fantomas  wrote:
> 
> or get the bank to fix it. One rarely needs multiple PTR records.

That would be ideal, but in 37 years of dealin with banks, fixing their 
stupidity is not something they do. 

Sent from my iPhone

Re: Question on Relay Host conf

[LuKreme]

On Mar 8, 2019, at 10:00, sse450  wrote:
> This mails originates from Apache through (I think) php mail. Obviously, my 
> server is compromised.

Not obvious at all, no. But the php script to sent mail to users may not be 
properly configured for your new settings. It should be setup to use submission 
with authentication.

But that has nothing to do with postfix.

-- 
My main job is trying to come up with new and innovative and effective ways to 
reject even more mail. I'm up to about 97% now.

Re: Maximum simultaneous outbounds ?

[LuKreme]

On Mar 3, 2019, at 16:17, Ronald F. Guilmette  wrote:
> You wouldn't happen to have the names of any products that fall
> into that other category that you just described would you?

rsync done this to my system in the past.

-- 
My main job is trying to come up with new and innovative and effective ways to 
reject even more mail. I'm up to about 97% now.

Re: Source of spam

[LuKreme]

On May 4, 2018, at 12:33, Proxy  wrote:
> This website have some form for contacting me

This is almost certainly where the fault lies. How is this form protected? How 
does it authenticate with your server? How ancient is the code used for the 
form? How do you verify a human?

-- 
My main job is trying to come up with new and innovative and effective ways to 
reject even more mail. I'm up to about 97% now.

Root user's sent mail

[LuKreme]

The root user sends out some periodic mails to users. These mails get placed in 
/root/sent (an mbox file) instead of in /root/Maildir/.Sent/ (a Maildir 
directory).

It’s not a big deal, but it makes clearing the mails periodically slightly more 
difficult.

The mails are sent via a crontab entry much like this:
  | mutt -e 'set content_type=text/html' -s "DMR  $($YDAY)" 
u...@kreme.com -b adminu...@kreme.com

main.cf:home_mailbox = Maildir/

But I suspect the issue here is mutt and not postfix?

-- 
ADVANCE TO THE REAR!

Re: Not receiving messages from mail servers

[LuKreme]

On Apr 17, 2018, at 07:58, Dominic Raferd  wrote:
> What do the 'dovecot: imap-login' messages signify?

That wouldn't be involved. This wasn’t a user logging in, this was mail 
delivering from the dovecot list

> Judging from the final smtpd log message, STARTTLS wasn't attempted,

Yep, that was the clue.

I seem to have fixed it. I had an errant !TLSv1.1 in the protocols list. I 
guess I got a little distracted when I was locking down Apache... :/

-- 
My main job is trying to come up with new and innovative and effective ways to 
reject even more mail. I'm up to about 97% now.

Re: question about envelop from.

[LuKreme]

On Mar 13, 2018, at 09:17, Viktor Dukhovni  wrote:
>> smtpd_tls_exclude_ciphers = eNULL, aNULL, LOW, EXP, MEDIUM, ADH, AECDH, MD5, 
>> DSS, ECDSA, CAMELLIA128, CAMELLIA256, 3DES
> 
> This too is unwise.  Remove this setting.

In general, or these specific exclusions?

I've had

smtpd_tls_exclude_ciphers = MD5, SEED, IDEA, RC2, RC4

For a pretty long time now 

-- 
My main job is trying to come up with new and innovative and effective ways to 
reject even more mail. I'm up to about 97% now.

Re: Reducing logging

[LuKreme]

On Mar 13, 2018, at 02:35, Christian Schmidt 
 wrote:
> In addition, you could add the option "-o syslog_name=postfix-587" (or
> "25") to the corresponding entry in master.cf. This will make postfix
> "label" the logfile entries - and maybe enable your syslog service to
> direct them into separate files.

Labeling isn't the issue, I can already grep out the things I don't want, it's 
just a lot do do whenever I want to get certain information out (just as one 
example, I want to check for errors and warnings, but I *never* care about the 
“does not resolve” warnings which will be 90% of the output looking for 
warnings and errors if I don't specifically grep that out...

In fact, I may simply run a task to strip some things out of the logfiles and 
put others into other files after the files roll over.

But I’ll take a look at rsyslogd first.

-- 
My main job is trying to come up with new and innovative and effective ways to 
reject even more mail. I'm up to about 97% now.

Reducing logging

[LuKreme]

I may have asked this before, but if so I can't find the thread.

I'd like to either reduce the amount that postfix logs or redirect certain 
events to a secondary log file (that I can put on a shorter rotation than the 
full mail log).

Is there anyway to redirect, for example, post screen events to a different log 
file or the warning hostname does not resolve messages?

-- 
My main job is trying to come up with new and innovative and effective ways to 
reject even more mail. I'm up to about 97% now.

Re: Disable submission on port 25

[LuKreme]

On Mar 3, 2018, at 14:31, Ben Lavender  wrote:
> I’m looking to disable submission on port 25 and therefore have postfix as a 
> relay only server.

You SHOULD disable submission on port 25, but that doesn't mean you have to be 
a relay-only server. Put submission on port 587.

(Or disable submission entirely, of course)

-- 
My main job is trying to come up with new and innovative and effective ways to 
reject even more mail. I'm up to about 97% now.

Re: ETRN use and Postfix configuration

[LuKreme]

On Feb 27, 2018, at 18:29, J Doe  wrote:
> postscreen_discard_ehlo_keywords
>smtpd_discard_ehlo_keywords

Isn't ETRN a good thing? What's the benefit from disabling it?
-- 
My main job is trying to come up with new and innovative and effective ways to 
reject even more mail. I'm up to about 97% now.

Re: Question regarding smtpd DNS resolution

[LuKreme]

On Feb 5, 2018, at 05:26, Allen Coates  wrote:
> 
> Is this a reliable bad-host detector?

It is a very good indicator of spam. It is also an indicator of a misconfigured 
mail server (in the case of spammers, intentionally so). Anyone kitting this 
error on your postfix is going to be unable to send mail to the majority of 
mail servers.

OT: I'd love an option to split these kinds of errors into a separate log file. 
I keep maillogs for a long time, but this Gary age I'd love to dump after a day 
or two).

-- 
This is my signature. There are many like it, but this one is mine.

Re: Cyrus vs Dovecot for SASL AUTH and IMAP

[LuKreme]

On Jan 23, 2018, at 03:04, Peter  wrote:
> I would still use Dovecot for the server side and just install those very few 
> libs that are necessary from Cyrus for the client SASL support.


Agree. After switching to dovecot years ago I'm never going back to Cyrus.

-- 
This is my signature. There are many like it, but this one is mine.

Copying IMAP messages instead of Forwarding?

[LuKreme]

Is there a method to use IMAP to move messages to another account on another 
server for which I have login credentials on delivery instead of simply 
forwarding? Or would this be a question for the Dovecot list?

I am trying to get around various spam checking and DKIM failures for a local 
user who uses gmail but whose address is on my server. She wants all her mail 
to end up in Gmail, but forwarding it fails too often.

The other option that I am looking at is to enable POP3 so that gmail can 
simply get the messages, but I haven’t allowed POP3 in ages and am reluctant to 
do so now, though that is probably the simplest thing.

The user isn’t really savvy enough to manage two IMAP accounts herself.



-- 
This is my signature. There are many like it, but this one is mine.

Re: Using a date in a bcc map

[LuKreme]

On Sep 8, 2017, at 05:30, Ralf Hildebrandt  wrote:
> 
> Try creating the recipient_bcc.pcre using a script, and let the scipt
> insert the date.

So recipient_bcc.pcre is not simply loaded at startup? Is it read each time 
(seems unlikely) or simply periodically refreshed, or does my script to write 
the map need to thump postfix?

> Nice idea!

Thanks. It seems like it will be useful.

-- 
This is my signature. There are many like it, but this one is mine.

Re: Copy mail from specific email address to specific email address to other accounts

[LuKreme]

On Feb 7, 2016, at 14:12, Wietse Venema  wrote:
> Viktor Dukhovni:
>> 
>>> On Feb 7, 2016, at 3:16 PM, @lbutlr  wrote:
>>> /usr/local/etc/postfix which has a symlink at /etc/psotfix and
>>> 
 That is unlikely.
>>> 
>>> $ ls -lsd /etc/postfix   
>>> 0 lrwxr-xr-x  1 root  wheel  22 Jul 20  2015 /etc/postfix -> 
>>> /usr/local/etc/postfix
>> 
>> In that case s/unlikely/unwise/ or perhaps "unlikely to be 
>> useful/work-as-intended".
> 
> No, it is unlikely, because he said it was linked to /etc/psotfix.

I said that /usr/local/etc/postfix HAS a symlink at /etc/postfix/.

> The email had errors in command (postmap -q -q) and pathname
> (/etc/psotfix) information. If someone else wants to give it
> a try, they are most welcome.

All config files are in /usr/local/etc/postfix/, /etcpostfix is just a link.

Postmap -q returns th correct value, postfix itself does not access the virtual 
table for the header_checks or sender_bcc_maps or check_sender_access. I've 
provided unmunged postmap and master.cf. there are no errors or warnings in the 
logs.

I don't know what to do now, and I don't understand at all why you think I am 
lying.

Re: moving configs from /usr/local/etc/postfix to /etc/postfix

[LuKreme]

On Jan 30, 2016, at 22:42, Curtis Villamizar  wrote:
> It would be:
> 
>  cd /usr/local/etc
>  mv postfix postfix.old
>  ln -s ../../../etc/postfix postfix

 No, it most certainly would not. Your configuration files ARE in local, if you 
want to pretend they are in /etc, then create a link in etc.  I've done this 
for years. Works just fine.

> And yes I did try that.

And what you tried will not work.

Re: Adding a noreply address

[LuKreme]

On Jan 26, 2016, at 09:22, Wietse Venema  wrote:
> transport_maps = inline:{u...@example.com=discard:}

O, that is nifty!

-- 
Suck it, Firefox!

Incomplete received header

[LuKreme]

I am getting some messages with an incomplete received header, they all seem to 
come from bronto.com:

Received: from ms045.bronto.com (unknown)
   by mail.covisp.net(Postfix 2.11.4/8.13.0) with SMTP id unknown;
   Sun, 19 Apr 2015 15:00:38 -0600
   (envelope-from cl3q5hr7hjponyd66fmt70m4u3kvtoi...@bounce.bronto.com)

I don't know why postfix is not generating a SMTP id or reporting the helo name 
or IP address. 

Ideas?

-- 

Re: Incomplete received header

[LuKreme]

On Apr 21, 2015, at 08:49, Wietse Venema wie...@porcupine.org wrote:
 
 The Postfix SMTP id is the queue file name. The most likely explanation
 is that the Received: header was modified with a header_checks rule or
 content filter.

Thanks, I'll look at my header_checks, though I suspect it's spamass-milter. 
Would I see that change logged if I turn on debugging?

Getting messages from queue

[LuKreme]

When I have a message in the mailq how do I get just the message out to, for 
example, feeding to SpamAssassin? With postcat -bh there is no From  header.

(I'm not sure if SA uses the From  header or not)


-- 

Re: Getting messages from queue

[LuKreme]

On Mar 3, 2015, at 08:30, Noel Jones njo...@megan.vbhcs.org wrote:
 
 To manually test a message, use something like:
 postcat -bhq QUEUEID | spamassassin

I was surprised that postcat requires a full path to the file, but thanks for 
the info in the From  header.

Re: detecting encryption for outgoing mail

[LuKreme]

 On 15 Feb 2015, at 07:56 , John j...@klam.ca wrote:
 
 On 2/15/2015 9:40 AM, Mauricio Tavares wrote:
 On Sun, Feb 15, 2015 at 9:12 AM, John j...@klam.ca wrote:
 A couple of the  servers I support are medical offices, and for patient
 confidentiality reasons they need to send email out encrypted.
 After a lot of discussion they have come to the conclusion that in order to
 avoid accidentally sending confidential data unencrypted, all email must be
 encrypted.
 What they would like is a filter on outgoing email that checks for
 encryption and refuses anything not encrypted. They need to err on the side
 of caution.
 
 So far Google has not been my friend.
 
 Does anybody know of a way of enforcing encryption, or detecting unencrypted
 email.
 
   Stupid question: is the entire email supposed to be encrypted or
 just part of it (Hi Bubba. Please see attached an encrypted doc
 containing an update.)? Also, which encryption did they settle down
 on?

 Why is this a stupid question?

Not your question. Mauricio was asking a question he prefaced with “stupid 
question:“

 All email sent must be encrypted, they plan on using SMIME mainly because it 
 is more common than PGP. The MUAs are a mixture of Outlook and Thunderbird.

I’d assume there would be something in the headers to indicate the message was 
encrypted. Probably some sort of milter running on your submission port would 
be able to check this?

Might even already be in mime-defang?

-- 
'They were myths and they were real,' he said loudly. 'Both a wave and a
particle.' --Guards! Guards!

helo_checks

[LuKreme]

Has anyone had any sort of issue with a check like this:

/(unknown|localhost|localdomain|lan|home|example|local|lokal)$/ REJECT 
Mailserver name in private namespace

I’ve noticed a lot of commercial non-spam email hitting this recently (for 
example, landmarktheatres ticket confirmations, a local restaurant's email 
verification for signup, and some others along those lines). In fact, the split 
between obvious spam and no-spam seems to be about 80/20 with low hitrate 
either way.

Yes, I know their mail servers are mis-configured.

-- 
The quality of our thoughts and ideas can only be as good as the quality
of our language.

Re: helo_checks

[LuKreme]

On 14 Feb 2015, at 04:39 , li...@rhsoft.net wrote:
 Am 14.02.2015 um 11:30 schrieb LuKreme:
 Has anyone had any sort of issue with a check like this:
 
 /(unknown|localhost|localdomain|lan|home|example|local|lokal)$/ REJECT 
 Mailserver name in private namespace
 
 I’ve noticed a lot of commercial non-spam email hitting this recently (for 
 example, landmarktheatres ticket confirmations, a local restaurant's email 
 verification for signup, and some others along those lines). In fact, the 
 split between obvious spam and no-spam seems to be about 80/20 with low 
 hitrate either way.
 
 Yes, I know their mail servers are mis-configured
 
 put any PTR and HELO checks at the *bottom* of your restrictions and conigure 
 the SPF check as well as much as possible DNSWL to skip them

Hmm. I usually put cheap checks first.

Reading on SPF in postfix I see:

http://www.postfix.org/SMTPD_ACCESS_README.html
 The greylisting and SPF policies are implemented externally,

Which I thought was no longer true.

# postconf -d | grep spf
spf_explanation =
spf_global_whitelist = no
spf_local_policy =
spf_mark_only = no
spf_patch_version = 1.1.0
spf_received_header = yes
spf_reject_code = 550
spf_reject_dsn = 5.7.1

I haven’t setup SPF in postfix, but those are the default setting. Searching 
postfix.org site for spf_local_policy returns no hits so I’ve not found the 
documentation on these settings. It may be on my computer.

https://www.google.com/search?q=spf_local_policy+site:postfix.org

 hence no real problems here while we update the checks automatically once per 
 day by the current http://data.iana.org/TLD/tlds-alpha-by-domain.txt to not 
 miss new TLD's and jeject any non-existing

Well, .local is definitely a non-existing tld, and any mail server using that 
as it’s helo is badly broken. It used to be a 100% spam indicator for me, but 
now it is less so.

 /etc/python-policyd-spf/policyd-spf.conf

Ah, I will ook at installing that package. Thanks.

-- 
Lobotomy means never having to say you're sorry -- or anything else.

Re: helo_checks

[LuKreme]

 On 14 Feb 2015, at 15:47 , li...@rhsoft.net wrote:
 
 
 
 Am 14.02.2015 um 23:37 schrieb LuKreme:
 On 14 Feb 2015, at 04:39 , li...@rhsoft.net wrote:
 Am 14.02.2015 um 11:30 schrieb LuKreme:
 Has anyone had any sort of issue with a check like this:
 
 /(unknown|localhost|localdomain|lan|home|example|local|lokal)$/ REJECT 
 Mailserver name in private namespace
 
 I’ve noticed a lot of commercial non-spam email hitting this recently (for 
 example, landmarktheatres ticket confirmations, a local restaurant's email 
 verification for signup, and some others along those lines). In fact, the 
 split between obvious spam and no-spam seems to be about 80/20 with low 
 hitrate either way.
 
 Yes, I know their mail servers are mis-configured
 
 put any PTR and HELO checks at the *bottom* of your restrictions and 
 conigure the SPF check as well as much as possible DNSWL to skip them
 
 Hmm. I usually put cheap checks first
 
 me too, hence that all comes before milters
 
 Reading on SPF in postfix I see:
 
 http://www.postfix.org/SMTPD_ACCESS_README.html
 The greylisting and SPF policies are implemented externally,
 
 Which I thought was no longer true.
 
 # postconf -d | grep spf
 spf_explanation =
 spf_global_whitelist = no
 spf_local_policy =
 spf_mark_only = no
 spf_patch_version = 1.1.0
 spf_received_header = yes
 spf_reject_code = 550
 spf_reject_dsn = 5.7.1
 
 that's a *not offical* postfix with discouraged pacthes

Is it? dammit.

I built with 
SYSLIBS = -L/usr/local/lib -lpcre -L/usr/local/lib -lsasl2 -lpam -lcrypt 
-L/usr/local/lib -Wl,-rpath,/usr/local/lib -lssl -lcrypto -L/usr/local/lib 
-lspf2 -L/usr/local/lib/db5 -ldb-5.3 -L/usr/local/lib/mysql -lmysqlclient -lz 
-lcrypt -lm -L/usr/local/lib -lldap -llber -L/usr/local/lib -lcdb

Via portmaster. I guess -lspf2 is the not official and discouraged portion?

-- 
Competent? How are we going to compete with that?

Re: How do I get User/Password authentication on 587 only for relaying

[LuKreme]

On 14 Feb 2015, at 07:13 , Nick Howitt n...@howitts.co.uk wrote:
 Unfortunately this opens up user/pass authenticated relaying to port 25 as 
 well as 587 and is vulnerable to to being brute forced. It appears at the 
 moment that just about all brute forcing happens on port 25. Is there any 
 combination or parameters which will deny user/pass authentication for 
 relaying on 25, allow it on 587 and will allow permitted networks (my LAN and 
 Webmail server) without authentication?

Yes, but why to simply use submission for everyone as that is what it is for?

What you need to do is remove the ssl from port 25 (that is, your main config) 
and enable it only on the submission port in master.cf

submission inet  n   -   n   -   -   smtpd
 -o smtpd_tls_security_level=encrypt
 -o smtpd_sasl_auth_enable=yes
 -o smtpd_sasl_type=dovecot
 -o smtpd_sasl_security_options=noanonymous
 -o smtpd_sasl_path=private/auth
 -o smtpd_client_restrictions=permit_sasl_authenticated,reject
 -o smtpd_data_restrictions=
 -o 
smtpd_relay_restrictions=permit_sasl_authenticated,reject_unauth_destination,reject
 -o smtpd_helo_restrictions=
 -o 
smtpd_recipient_restrictions=permit_sasl_authenticated,reject_unauth_destination,reject
 -o syslog_name=submit-tls

(watch out for line wrap)

This is how I have my submission port configured. I do not allow submission on 
port 25 for anyone other than localhost.

-- 
Though it's cold and lonely in the deep dark night I can see paradise by
the dashboard light.

Re: helo_checks

[LuKreme]

On 14 Feb 2015, at 15:49 , Wietse Venema wie...@porcupine.org wrote:
 % postconf -d|grep spf
 % 
 
 And I run the latest Postfix version. I take no responsibility for
 bugs that are added after I release Postfix.

Yes, I will rebuild from the 2.11 source.

-- 
++?++ Out of Cheese Error. Redo From Start.

Re: Process mail before Palais processing?

[LuKreme]

On Feb 12, 2015, at 10:06, Wietse Venema wie...@porcupine.org wrote:
 
 LuKreme:
 I have a account that is managed via sql and has an alias in 
 
 mysql_virtual_alias_maps.cf
 
 I would like to do some processing on emails before they are
 forwarded along to the alias, but I don?t see a way to interject
 some process (say, procmail or spam or clamav) in that part of the
 process.
 
 That is correct. Virtual aliases are processed while mail is received.
 
 To process mail outside Postfix before virtual alias expansion, you
 would need to use an after queue content filter, with virtual
 alias expansion disabled before the filter, and virtual alias
 expansion enabled after the filter.

That's what I thought.

 It's kind-of kludgy with many moving parts:
 
 http://www.postfix.org/FILTER_README.html
 http://www.postfix.org/postconf.5.html#receive_override_options
 http://www.postfix.org/postconf.5.html#content_filter

I think it's going to be easier to just process the mail and then use pro mail 
to forward it along. Oh well, it was an idea.

spamass-milter

[LuKreme]

I believe I have the spams-milter working with postfix

main.cf
milter_default_action = accept
smtpd_milters = unix:/var/run/spamass-milter.sock

The spams-milter is running:
spamd32770   0.2  3.3  82164 67496 ??  S 1:14PM  0:11.22 spamd 
child (perl)
root 32769   0.0  3.0  73972 61176 ??  Ss1:14PM  0:02.95 
/usr/local/bin/spamd -u spamd -H /var/spool/spamd -d -r 
/var/run/spamd/spamd.pid (perl)
spamd32771   0.0  3.1  78068 63020 ??  I 1:14PM  0:00.79 spamd 
child (perl)
root 52035   0.0  0.5  30704  9608 ??  Is4Feb15  0:10.49 
/usr/local/sbin/spamass-milter -f -p /var/run/spamass-milter.sock

And messages are getting tagged as spam.

Feb 12 13:17:10 mail spamd[32769]: prefork: child states: II 
Feb 12 13:17:10 mail spamd[32770]: spamd: connection from localhost [::1]:35582 
to port 783, fd 6 
Feb 12 13:17:10 mail spamd[32770]: spamd: processing message 
75d769e5b2e49dd09bd8c43836b66aaf.13392617.20035...@nicesexytummy.us for 
kreme:58 
Feb 12 13:17:11 mail spamd[32770]: spamd: identified spam (9.7/5.0) for 
kreme:58 in 0.7 seconds, 9260 bytes. 
Feb 12 13:17:11 mail spamd[32770]: spamd: result: Y 9 - 
BAYES_99,BAYES_999,HTML_FONT_LOW_CONTRAST,HTML_IMAGE_ONLY_32,HTML_MESSAGE,MPART_ALT_DIFF,RCVD_IN_BRBL_LASTEXT,SPF_HELO_PASS,SPF_PASS,T_REMOTE_IMAGE,T_RP_MATCHES_RCVD,URI_TRY_USME
 
scantime=0.7,size=9260,user=kreme,uid=58,required_score=5.0,rhost=localhost,raddr=::1,rport=35582,mid=75d769e5b2e49dd09bd8c43836b66aaf.13392617.20035...@nicesexytummy.us,bayes=1.00,autolearn=no
 autolearn_force=no 

Two questions. Wouldn’t the log show the milter instead of spamd? And now that 
this is working, how do I reject incoming messages based on their score (for 
example, say I wanted to reject all spam scoring 9.0 or higher)?


-- 
'Charity ain't giving people what you wants to give, it's giving people
what they need to get.'

Re: cyrus imapd, lmtp, postfix and case sensitivity in domain names

[LuKreme]

On 12 Feb 2015, at 15:33 , Carl Brewer c...@bl.echidna.id.au wrote:
 
 Last question! (I hope ...)
 
 I also posted this on the cyrus mailing list but more aimed at a proper fix. 
 I have a problem with cyrus lmtp delivery and case sensitive domain names(!).
 
 This gets through : u...@domain.foo
 This does not : u...@domain.foo
 
 with lmtp_downcase_rcpt: 1 set in imapd.conf
 
 I know (think, anyway ...) it's a cyrus issue (the above should lowercase the 
 whole thing?)

It’s been a while since I ran cyrus, but I think that lowercases the username.

http://www.leaky.org/cyrus/guide/admin/twofive-defaults.html

References the local part specifically.

-- 
Commander: Seems odd you'd name your ship after a battle you were on
the wrong side of. 
 
Mal: May have been the losing side. Still not convinced it was the
wrong one.

Re: spamass-milter

[LuKreme]

On 12 Feb 2015, at 16:08 , Noel Jones njo...@megan.vbhcs.org wrote:
 On 2/12/2015 4:56 PM, LuKreme wrote:
 On 12 Feb 2015, at 13:42 , Noel Jones njo...@megan.vbhcs.org wrote:
 spamass-milter uses the standard spamassassin spamc/spamd interface.
 I believe you can enable additional spamass-milter logging on its
 startup command line.
 
 There are startup flags you can add to spamass-milter to reject mail
 over a certain score.
 
 I’m guessing that setting a reject flag would require that I also change the 
 value of milter_default_action from accept to tempfail? If I’m reading the 
 docs right, accept will pass the mail on for delivery regardless of the 
 milter?
 
 No, the default action is what postfix does if the milter ist
 unavailable (eg. not running, no answer).  Using accept will allow
 all mail to pass if the milter doesn't answer requests for any reason.

Excellent. I see how I misread that.

It seems to be rocking along very nicely so far.


-- 
Don't be nice. It's Creepy.

Re: Tracking down a mail forwarding loop

[LuKreme]

On 12 Feb 2015, at 08:25 , Noel Jones njo...@megan.vbhcs.org wrote:
 On 2/12/2015 12:43 AM, LuKreme wrote:
 
 On Feb 11, 2015, at 6:20 PM, Wietse Venema wie...@porcupine.org wrote:
 
 LuKreme:
 Received: from thenewestsecret.net (unknown [170.130.246.215])
   by mail.covisp.net (Postfix) with ESMTP id 00E42212DC0
   for *bob*@covisp.net; Tue, 10 Feb 2015 08:53:22 -0700 (MST)
 Delivered-To: *bob*@covisp.net
 Received: by 170.130.246.215 with SMTP id 
 998S7h4.33K03w6s2R18O2.22351x4s23d1n26;
   Tue, 10 Feb 2015 08:51:05 -0700 (PST)
 X-Received: by 170.130.246.215 with SMTP id 134G6f10K6Z34b712c43li;
   Tue, 10 Feb 2015 08:51:05 -0700 (PST)
 Received: from thenewestsecret.net (thenewestsecret.net. )
   by mx.google.com with ESMTP id 
 59333u4l19.1C4P11z.147.0.5.1.2.5.5.5.1.0.7.0.4
   for *bob*@covisp.net;
   Tue, 10 Feb 2015 08:51:05 -0700 (PST)
 Mime-Version: 1.0
 Date: 
 Message-Id: 235.946781y2r0b6qn6-c...@thenewestsecret.net
 To: *bob*@covisp.net
 
 This message contains a Delivered-To: *bob*@covisp.net header.
 Apparently, the sender added this to trigger a delivery error.
 Apparently, the sender, c...@thenewestsecret.net, wants to receive
 a bounce message. That message would confirm that *bob*@covisp.net
 is a valid email address.
 
 Does it make sense to reject messages with a Delivered-To: header?
 
 Yes.  Incoming mail with that header cannot be delivered by postfix,
 regardless whether it's really looping or not.
 
 Although in this particular case it might be better to reject the
 spammy-looking client.

Yes, but my postscreen is already aggressive enough that I had to tone it down 
a tad to let some legitimate mail (well, mail I wanted) in.

 Why does it generate a mail loop in my local postfix?
 
 The presence of that header triggers the loop detection in postfix.
 The sender is adding that header either in a misguided attempt to
 improve delivery, or to intentionally cause a bounce to verify the
 address.

What is interesting is that I see these *only* for one specific user, which is 
what made me think it was something on my end.

 We don't know the motive of the sender. We do know this isn't really
 a loop and it looks like spam to me.

Oh, they are all spam so far.

Thanks.

-- 
'Luck is my middle name,' said Rincewind, indistinctly. 'Mind you, my
first name is Bad.' --Interesting Times

Process mail before Palais processing?

[LuKreme]

I have a account that is managed via sql and has an alias in 

mysql_virtual_alias_maps.cf

I would like to do some processing on emails before they are forwarded along to 
the alias, but I don’t see a way to interject some process (say, procmail or 
spam or clamav) in that part of the process.


-- 
It was sad music. But it waved its sadness like a battle flag. It said
the universe had done all it could, but you were still alive.

Re: Tracking down a mail forwarding loop

[LuKreme]

 On Feb 11, 2015, at 6:20 PM, Wietse Venema wie...@porcupine.org wrote:
 
 LuKreme:
 Received: from thenewestsecret.net (unknown [170.130.246.215])
by mail.covisp.net (Postfix) with ESMTP id 00E42212DC0
for *bob*@covisp.net; Tue, 10 Feb 2015 08:53:22 -0700 (MST)
 Delivered-To: *bob*@covisp.net
 Received: by 170.130.246.215 with SMTP id 
 998S7h4.33K03w6s2R18O2.22351x4s23d1n26;
Tue, 10 Feb 2015 08:51:05 -0700 (PST)
 X-Received: by 170.130.246.215 with SMTP id 134G6f10K6Z34b712c43li;
Tue, 10 Feb 2015 08:51:05 -0700 (PST)
 Received: from thenewestsecret.net (thenewestsecret.net. )
by mx.google.com with ESMTP id 
 59333u4l19.1C4P11z.147.0.5.1.2.5.5.5.1.0.7.0.4
for *bob*@covisp.net;
Tue, 10 Feb 2015 08:51:05 -0700 (PST)
 Mime-Version: 1.0
 Date: 
 Message-Id: 235.946781y2r0b6qn6-c...@thenewestsecret.net
 To: *bob*@covisp.net
 
 This message contains a Delivered-To: *bob*@covisp.net header.
 Apparently, the sender added this to trigger a delivery error.
 Apparently, the sender, c...@thenewestsecret.net, wants to receive
 a bounce message. That message would confirm that *bob*@covisp.net
 is a valid email address.

Does it make sense to reject messages with a Delivered-To: header?

Why does it generate a mail loop in my local postfix?

Could it have anything to do with the always_bcc setting?

$ postconf always_bcc
always_bcc = backups@*otherlocaldomain*.com

Would some other MTA deliver the message anyway, or this simply a spam 
harvesting tactic? The messages don’t seem to generate a valid bounce to a 
valid address…


-- 
S is for SUSAN who perished of fits
T is for TITUS who flew into bits

Re: Behavior when mailbox limit is reached

[LuKreme]

On Jan 14, 2015, at 17:20, Mullis, Josh (CCI-Atlanta) josh.mul...@cox.com 
wrote:
 Is there a way to configure postfix to remove old mail when the mailbox size 
 limit is reached instead of new mail being rejected?

As others have said, this is a function of the LDA, but it is also a terrible 
idea. Disk space is cheap. Set a reasonable limit on the size of email 
(10-25MB) and you shouldn't have any trouble. If you do have trouble with 
specific users, deal with that.

 The basic need is limiting the amount of disk space mailbox files are using 
 without rejecting mail.

What you want to do is delete mail from users without notification or recourse 
in preference to accepting mail. The proper method is to reject mail since that 
notifies the sender the mail could not be delivered, and that is a recoverable 
act.

Re: TLSv1 and SSLv3

[LuKreme]

On Feb 7, 2015, at 10:51 PM, Viktor Dukhovni postfix-us...@dukhovni.org wrote:
 On Sat, Feb 07, 2015 at 10:18:11PM -0700, LuKreme wrote:
 
 # postconf -n | grep _tls_
 smtp_tls_security_level = may
 smtpd_tls_cert_file = /etc/ssl/certs/postfix.pem
 
 Fine so far.
 
 smtpd_tls_ciphers = high
 
 This is too high for opportunistic TLS.  Anything more than
 medium is too restrictive for opportunistic TLS on port 25.
 
 On the submission port (587) you can be more strict.
 
 # is smtp_tls_exclude needed?
 smtpd_tls_exclude_ciphers = aNULL, DES, 3DES, MD5, DES+MD5, RC4
 
 The defaults are fine.  Why do you feel compelled to tune these?
 
 smtpd_tls_loglevel = 2
 
 Too verbose.  Stick with 1
 
 smtpd_tls_protocols = TLSv1, !SSLv2, !SSLv3
 
 Why exclude TLSv1.1 and TLSv1.2?  See the documentation.
 The default is fine, but if you must tweak, exclude just
 SSLv2.
 
smtpd_tls_protocols = !SSLv2
 
 On the submission port (587) you can be more strict.

OK, thank you for the feedback. Some of the settings were simply leftovers I 
never changed, and I thought we wanted to exclude SSLv3 now.


-- 
'I warn you, dragon, the human spirit is-' They never found out what it
was, or at least what he thought it was, although possibly in the dark
hours of a sleepless night some of them might have remembered the
subsequent events and formed a pretty good and gut-churning insight, to
whit, that one of the things sometimes forgotten about the human spirit
is that while it is, in the right conditions, noble and brave and
wonderful, it is also, when you get right down to it, only human.

TLSv1 and SSLv3

[LuKreme]

 # postconf -n | grep _tls_
smtp_tls_security_level = may
smtpd_tls_cert_file = /etc/ssl/certs/postfix.pem
smtpd_tls_ciphers = high
# is smtp_tls_exclude needed?
smtpd_tls_exclude_ciphers = aNULL, DES, 3DES, MD5, DES+MD5, RC4
smtpd_tls_key_file = /etc/ssl/private/postfix.pem
smtpd_tls_loglevel = 2
smtpd_tls_protocols = TLSv1, !SSLv2, !SSLv3
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:$data_directory/smtpd_sessions
smtpd_tls_session_cache_timeout = 1800s

 # openssl s_client -connect 127.0.0.1:993
 … stuff … 
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1
Cipher: DHE-RSA-AES256-SHA
Session-ID: 74C111205F8DC120D0A5ABAFD1CA5BE88523F775B5DCF0D13529D685369CF2ED
Session-ID-ctx: 
Master-Key: 
ED4BB02DA0BDD821E96B0EAE1A6B3BA1E5147473A637A651B8D1B72CD72470512F6842652F61A37952FEC01DF321D20F
Key-Arg   : None
Start Time: 1423372148
Timeout   : 300 (sec)
Verify return code: 18 (self signed certificate)
---
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE 
AUTH=PLAIN AUTH=LOGIN] Dovecot ready.

Doesn’t New, TLSv1,SSLv3” indicate that SSLv3 is still allowed?

-- 
the first man to hear the voice of Om, and who gave Om his view of
humans, was a shepherd and not a goatherd. They have quite different
ways of looking at the world, and the whole of history might have been
different. For sheep are stupid and have to be driven. But goats are
intelligent and have to be led. (Small Gods)

Re: TLSv1 and SSLv3

[LuKreme]

On 07 Feb 2015, at 22:28 , Peter pe...@pajamian.dhs.org wrote:
 On 02/08/2015 06:18 PM, LuKreme wrote:
 # openssl s_client -connect 127.0.0.1:993
 
 Port 993 is IMAPS which is not provided by postfix.

Yes, of course. Sorry.

-- 
Gods don't like people not doing much work. People who aren't busy all
the time might start to think.

Re: Tracking down a mail forwarding loop

[LuKreme]

On Feb 6, 2015, at 3:43 PM, LuKreme krem...@kreme.com wrote:
 On 06 Feb 2015, at 15:05 , Wietse Venema wie...@porcupine.org wrote:
 NORMALLY, that header is present AFTER mail is delivered to b...@covisp.net.
 
 If it is present BEFORE mail is delivered to b...@covisp.net, then you have
 a loop (or the sender has added this header to trigger an error).
 
 Ah, right. I’ve added it and am eagerly awaiting another of these emails.

As the old saying goes:

A watched pot never delivers a mail loop causing message.

-- 
'We get that in here some nights, when someone's had a few. Cosmic
speculation about whether the gods exist. Next thing, there's a bolt of
lightning through the door with a note wrapped round it saying, Yes, we
do and a pair of sandals with smoke coming out.' (Small Gods)

Re: Tracking down a mail forwarding loop

[LuKreme]

On 06 Feb 2015, at 15:05 , Wietse Venema wie...@porcupine.org wrote:
 NORMALLY, that header is present AFTER mail is delivered to b...@covisp.net.
 
 If it is present BEFORE mail is delivered to b...@covisp.net, then you have
 a loop (or the sender has added this header to trigger an error).

Ah, right. I’ve added it and am eagerly awaiting another of these emails.

-- 
C code. C code run. Run, code, run.

Re: Tracking down a mail forwarding loop

[LuKreme]

Only other thing I can think of is that this is somehow related to always_bcc?


-- 
A dyslexic walks into a bra...

Re: Tracking down a mail forwarding loop

[LuKreme]

On 05 Feb 2015, at 05:07 , Wietse Venema wie...@porcupine.org wrote:
 Have you considered the possibility that the mail was sent with a
 bogus Delivered-To: header (i.e. the header is present, but not
 added by Postfix).

Yes, but I’m unsure how to diagnose that.

Here is a full dump of one of these files (with only the user name munged)

https://www.dropbox.com/s/mvdg1f48fo640g3/768FC212C05.txt?dl=0

-- 
Thank you for sending me a copy of your book; I'll waste no time
reading it. - Moses Hadas

Re: Forwarding to Gmail

[LuKreme]

On 04 Feb 2015, at 08:45 , li...@rhsoft.net wrote:
 just setup SpamAssassin and ClamAV as *milter* and they are filtered 
 unconditional until you define no_milters in master.cf for a specific 
 service

Ah, right, that sounds familiar. Reading documentation now. Thanks.

-- 
Well, we know where we're goin'
But we don't know where we've been
And we know what we're knowin'
But we can't say what we've seen

Tracking down a mail forwarding loop

[LuKreme]

I have a local user who is generating occasional mail forwarding loop errors, 
which are causing forged emails to cause NDNs and fill up mailq.

Jan 30 13:46:08 mail postfix/local[44147]: 7020950D4D4: to=*bob*@covisp.net, 
relay=local, delay=0.65, delays=0.59/0/0/0.06, dsn=5.4.6, status=bounced (mail 
forwarding loop for *bob*@covisp.net)

The only place that “*bob*” is mentioned in virtual is in line like this:

bill...@covisp.net  bob,fred,george

Where bob, fred, and george are all local users.

bob doesn’t have a .forward, and I looked at his .procmailrc and it’s not 
forwarding mail anywhere.

Where else do I look?

postmap -q b...@covisp.net /etc/postfix/virtual doesn’t return any results.

-- 
Behind every great man there's a woman with a vibrator -- Hawkeye Pierce

Re: Tracking down a mail forwarding loop

[LuKreme]

On 04 Feb 2015, at 07:38 , Wietse Venema wie...@porcupine.org wrote:
 
 LuKreme:
 I have a local user who is generating occasional mail forwarding loop 
 errors, which are causing forged emails to cause NDNs and fill up mailq.
 
 Jan 30 13:46:08 mail postfix/local[44147]: 7020950D4D4: 
 to=*bob*@covisp.net, relay=local, delay=0.65, delays=0.59/0/0/0.06, 
 dsn=5.4.6, status=bounced (mail forwarding loop for *bob*@covisp.net)
 
 The only place that ?*bob*? is mentioned in virtual is in line like this:
 
 bill...@covisp.net  bob,fred,george
 
 Where bob, fred, and george are all local users.
 
 bob doesn?t have a .forward, and I looked at his .procmailrc and it?s not 
 forwarding mail anywhere.
 
 Where else do I look?
 
 Other opportunities for forwarding, such as postconf mailbox_command”?

Yeah, that’s why I checked procmailrc.

I do see that the modification date on the procmailrc is quite recent. Maybe he 
munged something and got it fixed. I’ll keep watching.


-- 
Growing up leads to growing old, and then to dying/And dying to me don't
sound like all that much fun.

Forwarding to Gmail

[LuKreme]

Quite a few users are forwarding their mail to either yahoo or gmail, which is 
causing a lot of trouble because both services see spam being forwarded and 
blacklist the sending server (me). Gmail at least seems to calm down after a 
little while, but delays on some mail can be many hours.

These are users who are setting their own forwarding up via postfixadmin and 
getting forwarded by postfix based on the mysql lookup in 
proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf, so the messages aren’t 
getting filtered at all (beyond what postscreen can do, of course).

Is there anything that I can do about this on my end? Someway I can at least 
run spamassassin over the mail so I can not forward obvious spam? And if I AM 
forwarding obvious spam its at least marked as such by SA which might help.

The gmail issues are mailq entries that look like this:

D210621494D12700 Tue Feb  3 21:30:55  n...@dontyoudropthat.com
(host alt1.gmail-smtp-in.l.google.com[74.125.22.26] said: 421-4.7.0 
[75.148.37.66  15] Our system has detected an unusual rate of 421-4.7.0 
unsolicited mail originating from your IP address. To protect our 421-4.7.0 
users from spam, mail sent from your IP address has been temporarily 421-4.7.0 
rate limited. Please visit 421-4.7.0 
http://www.google.com/mail/help/bulk_mail.html to review our Bulk 421 4.7.0 
Email Senders Guidelines. z39si14220069gz.97 - gsmtp (in reply to end of DATA 
command))

That message eventually delivered at 03:09 today. Now, in this case it looks 
like it was probably spam and so the delay doesn’t matter, but sometimes the 
mail that is delayed is not spam.

The only thing I can say at this point is “Google is delaying your mail” which 
is true, but not very useful.


-- 
There is a road, no simple highway, between the dawn and the dark of
night

Re: Am I backscattering?

[LuKreme]

On Jan 31, 2015, at 9:29 PM, Bill Cole 
postfixlists-070...@billmail.scconsult.com wrote:
 Which doesn't mean you don't have some other Postfix binaries lurking...

Good point.

There are files in /usr/sbin/ and in /usr/local/sbin/ and it appears that the 
command directory is set to the latter, which appears to be 2.10.5

Seeing what breaks if I switch the command directory.

I would *never* have found that.


-- 
'Begone From This Place Or I Will Smite Thee!' he [the god] commanded.
'Why?'

Re: TLS Library Problem

[LuKreme]

On Jan 31, 2015, at 7:15 PM, Viktor Dukhovni postfix-us...@dukhovni.org wrote:
 On Sat, Jan 31, 2015 at 05:16:33PM -0700, LuKreme wrote:
 
 The start was just date stamp info and PID:
 
 Jan 31 01:52:10 mail postfix/smtpd[62297]: warning: TLS library problem: 
 error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad 
 certificate:s3_pkt.c:1293:SSL alert number 42:
 
 Which confirms that the problem is with your SMTP server as expected.

It does? I don’t know what in the error (especially with the addition of Jan 
31 01:52:10 mail postfix/smtpd[62297]:” would show where the error is. I am not 
questioning you, just saying I don’t understand the warning. It LOOKS like the 
other server is rejecting my self-signed key for opportunistic TLS.

 Assume away, or look more carefully at your own certificate chain.

$ posttls-finger mail.covisp.net
posttls-finger: Connected to mail.covisp.net[75.148.37.66]:25
posttls-finger:  220 mail.covisp.net ESMTP Postfix 2.11.3
posttls-finger:  EHLO mail.covisp.net
posttls-finger:  250-mail.covisp.net
posttls-finger:  250-PIPELINING
posttls-finger:  250-SIZE 26214400
posttls-finger:  250-ETRN
posttls-finger:  250-STARTTLS
posttls-finger:  250-AUTH PLAIN LOGIN
posttls-finger:  250-AUTH=PLAIN LOGIN
posttls-finger:  250-ENHANCEDSTATUSCODES
posttls-finger:  250-8BITMIME
posttls-finger:  250 DSN
posttls-finger:  STARTTLS
posttls-finger:  220 2.0.0 Ready to start TLS
posttls-finger: mail.covisp.net[75.148.37.66]:25 Matched CommonName 
mail.covisp.net
posttls-finger: certificate verification failed for 
mail.covisp.net[75.148.37.66]:25: self-signed certificate
posttls-finger: mail.covisp.net[75.148.37.66]:25: subject_CN=mail.covisp.net, 
issuer_CN=mail.covisp.net, 
fingerprint=A9:27:59:D2:B0:43:AD:21:38:B9:CC:20:30:EF:7F:A1:98:4E:1B:CD, 
pkey_fingerprint=75:D3:56:46:97:6C:FB:7A:A3:FC:75:7D:82:C5:FD:67:AE:56:EA:B4
posttls-finger: Untrusted TLS connection established to 
mail.covisp.net[75.148.37.66]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

I know the cert is self-signed, and that’s unlikely to change. If that is the 
source of these warnings then I can ignore them.If it’s something else, though, 
and it’s something I can/should fix, then I’d like to fix it.

 Looking at the previous line,
 
 Jan 31 01:52:10 mail postfix/smtpd[62297]: SSL_accept error from 
 mail-luna36.mailgun.org[173.193.210.36]: 0
 
 Is that what you were looking for?
 
 Yes.  http://www.mailgun.com/
 
$ posttls-finger mailgun.org
posttls-finger: Connected to mxb.mailgun.org[50.56.21.178]:25
posttls-finger:  220 ak47 ESMTP ready
 
 Perhaps their email ammunition includes some blanks.

There cert fails as well:

posttls-finger: mxa.mailgun.org[50.56.21.178]:25: Matched subjectAltName: 
*.mailgun.org
posttls-finger: mxa.mailgun.org[50.56.21.178]:25: Matched subjectAltName: 
mailgun.org
posttls-finger: mxa.mailgun.org[50.56.21.178]:25 CommonName *.mailgun.org
posttls-finger: certificate verification failed for 
mxa.mailgun.org[50.56.21.178]:25: untrusted issuer /C=US/O=GeoTrust 
Inc./CN=GeoTrust Global CA
posttls-finger: mxa.mailgun.org[50.56.21.178]:25: subject_CN=*.mailgun.org, 
issuer_CN=RapidSSL CA, 
fingerprint=5E:CF:E0:76:D5:DE:D3:E7:A8:4A:A2:2D:3D:51:0B:A6:C6:07:79:6A, 
pkey_fingerprint=F8:51:2B:C8:22:08:63:42:90:C6:0B:6B:A0:68:A0:55:57:0C:EC:F6
posttls-finger: Untrusted TLS connection established to 
mxa.mailgun.org[50.56.21.178]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)



-- 
A balanced diet is a cookie in each hand.

Re: hostname does not resolve

[LuKreme]

 On Jan 31, 2015, at 8:59 PM, Bill Cole 
 postfixlists-070...@billmail.scconsult.com wrote:
 
 I do not use that rejection criteria but instead use 
 reject_unknown_reverse_client_hostname,

I do use that, and have for a long time.

 which only requires that a PTR exists. On other systems I manage, I mostly DO 
 use reject_unknown_client_hostname

OK, I’ll keep that in mind then. I think, at this point, i need to look more. 
I’m not getting overwhelmed with them.

Thanks for the input.

-- 
Well, if crime fighters fight crime and fire fighters fight fire, what
do freedom fighters fight? They never mention that part to us, do they?

Re: Am I backscattering?

[LuKreme]

On 01 Feb 2015, at 03:13 , li...@rhsoft.net wrote:
 if you build software from source build native packages for your OS, that 
 cleans up things and avoids the system pulling the OS vendors version which 
 conflicts with something below /usr/local

I normally do that, but in this case I was upgrading everything in preparation 
for moving to FreeBSD 9.3. I made sure to tell portmaster to install into 
/usr/sbin and /etc/postfix instead of /usr/local/… but I had forgotten that 
years ago I’d installed postfix in /usr/local/… in the first place.

2.11 has been painless so far, and the ability to specify two delimiters has 
been worth the effort.

-- 
I do not feel obliged to believe that same God who endowed us with
sense, reason, and intellect had intended for us to forego their use.

Re: TLS Library Problem

[LuKreme]

On 01 Feb 2015, at 05:41 , DTNX Postmaster postmas...@dtnx.net wrote:
 By the way, CA-signed certificates start at less than $10/year, so if you 
 ever do run into an issue which might be resolved by getting one, and your 
 configuration isn't too complex, I would suggest spending that little bit of 
 money.
 
 Not the case here though, as far as I can tell :-)

Thanks for the detailed response. The issue with the certs is not the cost, but 
rather the maintenance of them. I don’t do this full-time and the interval 
between expiry is long enough that I get to learn everything over from first 
principles every time I have to replace a cert.

I’m looking forward to the EFF’s CA plan later this year to see if it will work 
for me. Removing the pain points of cert management would be great.

-- 
IT IS NOT YET MIDNIGHT?  'I shouldn't think it's more than a quarter
past eleven.' THEN WE HAVE THREE-QUARTERS OF AN HOUR 'How can you be
sure?' BECAUSE OF DRAMA, MISS FLITWORTH.. THE KIND OF DEATH WHO POSES
AGAINST THE SKYLINE AND GETS LIT UP BY LIGHTNING FLASHES, said Bill
Door, disapprovingly, DOESN'T TURN UP AT FIVE-AND-TWENTY PAST ELEVEN IF
HE CAN POSSIBLY TURN UP AT MIDNIGHT.

Re: Am I backscattering?

[LuKreme]

 On Jan 31, 2015, at 4:55 PM, LuKreme krem...@kreme.com wrote:
 
 
 On Jan 31, 2015, at 4:23 PM, Wietse Venema wie...@porcupine.org wrote:
 
 LuKreme:
 Jan 26 14:49:53 mail postfix/pipe[44273]: E64DA50D3A1: 
 to=oq6+2nbq@*munged*.com, orig_to=oq6_2nbq@*munged*.com, relay=dovecot, 
 delay=0.13, delays=0.1/0.01/0/0.03, dsn=5.1.1, status=bounced (user unknown)
 
 That will produce backscatter. Why did you accept an unknown recipient?
 
 I don’t know, that’s what I was trying to find.
 
 Everything I have about queue ID E64DA50D3A1 in maillog was posted in the 
 original message.
 
 Oh, wait, i think I just found it in an old pre map. Off to test.

Yes, the old PCRE map was the problem. IN trying to fix it, I went to change 
the recipient_delimiter

$ postfix reload 
postfix/postlog: fatal: bad string length 2  1: recipient_delimiter = +_
postsuper: fatal: bad string length 2  1: recipient_delimiter = +_
 mail /etc/postfix] $ postconf recipient_delimiter mail_version
recipient_delimiter = +_
mail_version = 2.11.3


-- 
Q: Does anyone know how many LOCs were in the Space Shuttle' codebase?
A: 45. It was written in perl (paraphrased Slashdot discussion)

TLS Library Problem

[LuKreme]

Since I am not seeing a load of these, I am assuming this is indicating the 
error is on the other end?

TLS library problem: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert 
bad certificate:s3_pkt.c:1293:SSL alert number 42:


-- 
'There has to be enough light,' he panted, 'to see the darkness.'

hostname does not resolve

[LuKreme]

What should I do about these warnings? Is there any reason not to reject the 
IPs in question? And if not, how do I do so? mail_version = 2.11.3

warning hostname 102-253-144-216.static.reverse.lstn.net does not resolve to 
address 216.144.253.102 hostname nor servname provided, or not known
warning hostname 138-128-178-101.static.dimenoc.com does not resolve to address 
138.128.178.101 hostname nor servname provided, or not known
warning hostname 158-33-143-63.static.reverse.lstn.net does not resolve to 
address 63.143.33.158 hostname nor servname provided, or not known
warning hostname 174-120-162-69.static.reverse.cascompany.com does not resolve 
to address 69.162.120.174 hostname nor servname provided, or not known

How about:

correctextract.com does not resolve to address 104.206.41.110
correctextract.com does not resolve to address 104.206.41.111
correctextract.com does not resolve to address 104.206.41.112
correctextract.com does not resolve to address 104.206.41.113
correctextract.com does not resolve to address 104.206.41.114
correctextract.com does not resolve to address 104.206.41.115

??

-- 
Indecision is the key to flexibility.

Re: Am I backscattering?

[LuKreme]

 On Jan 31, 2015, at 4:23 PM, Wietse Venema wie...@porcupine.org wrote:
 
 LuKreme:
 Jan 26 14:49:53 mail postfix/pipe[44273]: E64DA50D3A1: 
 to=oq6+2nbq@*munged*.com, orig_to=oq6_2nbq@*munged*.com, relay=dovecot, 
 delay=0.13, delays=0.1/0.01/0/0.03, dsn=5.1.1, status=bounced (user unknown)
 
 That will produce backscatter. Why did you accept an unknown recipient?

I don’t know, that’s what I was trying to find.

Everything I have about queue ID E64DA50D3A1 in maillog was posted in the 
original message.

Oh, wait, i think I just found it in an old pre map. Off to test.

-- 
Ah we're lonely, we're romantic / and the cider's laced with acid / and
the Holy Spirit's crying, Where's the beef? / And the moon is swimming
naked / and the summer night is fragrant / with a mighty expectation of
relief

Re: TLS Library Problem

[LuKreme]

On Jan 31, 2015, at 4:28 PM, Viktor Dukhovni postfix-us...@dukhovni.org wrote:
 On Sat, Jan 31, 2015 at 03:34:35PM -0700, LuKreme wrote:
 
 Since I am not seeing a load of these, I am assuming this is indicating the 
 error is on the other end?
 
 TLS library problem: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert 
 bad certificate:s3_pkt.c:1293:SSL alert number 42:
 
 Was there a good reason to remove the beginning of the log message?
 The IP address of the peer?

The start was just date stamp info and PID:

Jan 31 01:52:10 mail postfix/smtpd[62297]: warning: TLS library problem: 
error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad 
certificate:s3_pkt.c:1293:SSL alert number 42:

 The peer send an SSL alert indicating it is unhappy about your
 certificate.  Presumably, you're on the server end, and the peer
 does not like your certificate contents.
 
 Whether this is your fault or not, depends on whether my assumptions
 are correct, and whether the peer can legitimately expect to be
 able to verify your certificate.

This is the only warning of this sort I see, so I’m assume it’s their issue.

Looking at the previous line,

Jan 31 01:52:10 mail postfix/smtpd[62297]: SSL_accept error from 
mail-luna36.mailgun.org[173.193.210.36]: 0

Is that what you were looking for?

-- 
Eureka, he said. Going to have a bath then?

Re: Am I backscattering?

[LuKreme]

 On Jan 31, 2015, at 5:21 PM, Wietse Venema wie...@porcupine.org wrote:
 
 LuKreme:
 
 On Jan 31, 2015, at 4:55 PM, LuKreme krem...@kreme.com wrote:
 
 
 On Jan 31, 2015, at 4:23 PM, Wietse Venema wie...@porcupine.org wrote:
 
 LuKreme:
 Jan 26 14:49:53 mail postfix/pipe[44273]: E64DA50D3A1: 
 to=oq6+2nbq@*munged*.com, orig_to=oq6_2nbq@*munged*.com, 
 relay=dovecot, delay=0.13, delays=0.1/0.01/0/0.03, dsn=5.1.1, 
 status=bounced (user unknown)
 
 That will produce backscatter. Why did you accept an unknown recipient?
 
 I don?t know, that?s what I was trying to find.
 
 Everything I have about queue ID E64DA50D3A1 in maillog was posted in the 
 original message.
 
 Oh, wait, i think I just found it in an old pre map. Off to test.
 
 Yes, the old PCRE map was the problem. IN trying to fix it, I went to change 
 the recipient_delimiter
 
 $ postfix reload 
 postfix/postlog: fatal: bad string length 2  1: recipient_delimiter = +_
 postsuper: fatal: bad string length 2  1: recipient_delimiter = +_
 mail /etc/postfix] $ postconf recipient_delimiter mail_version
 recipient_delimiter = +_
 mail_version = 2.11.3
 
 No such problems here.
 
 % bin/postconf mail_version recipient_delimiter
 mail_version = 2.11.3
 recipient_delimiter = +_
 # bin/postsuper -v
 # bin/postlog foo
 postfix/postlog: foo
 
 I suppose you have a Frankenstein Postfix installation, with some
 parts coming from different bodies?

I wouldn’t think so unless postmaster did something very odd.

 # postsuper -v
postsuper: name_mask: ipv4
postsuper: inet_addr_local: configured 2 IPv4 addresses
postsuper: queue: defer
postsuper: queue: bounce
postsuper: queue: maildrop
postsuper: queue: incoming
postsuper: queue: active
postsuper: queue: deferred
postsuper: queue: hold
postsuper: queue: flush
 # postlog foo
postfix/postlog: foo
 # postconf recipient_delimiter
recipient_delimiter = +_
 # postfix reload
postfix/postlog: fatal: bad string length 2  1: recipient_delimiter = +_
postsuper: fatal: bad string length 2  1: recipient_delimiter = +_


 #  ls -lsa /usr/sbin/post*
400 -rwxr-xr-x  1 root  wheel 203012 Jan 25 12:21 /usr/sbin/postalias
192 -rwxr-xr-x  1 root  wheel  97216 Jan 25 12:21 /usr/sbin/postcat
520 -rwxr-xr-x  1 root  wheel 262156 Jan 25 12:21 /usr/sbin/postconf
328 -rwxr-sr-x  1 root  maildrop  165092 Jan 25 12:21 /usr/sbin/postdrop
168 -rwxr-xr-x  1 root  wheel  84360 Jan 25 12:21 /usr/sbin/postfix
184 -rwxr-xr-x  1 root  wheel  92804 Jan 25 12:21 /usr/sbin/postkick
176 -rwxr-xr-x  1 root  wheel  89604 Jan 25 12:21 /usr/sbin/postlock
168 -rwxr-xr-x  1 root  wheel  84632 Jan 25 12:21 /usr/sbin/postlog
408 -rwxr-xr-x  1 root  wheel 206036 Jan 25 12:21 /usr/sbin/postmap
192 -rwxr-xr-x  1 root  wheel  97944 Jan 25 12:21 /usr/sbin/postmulti
408 -rwxr-sr-x  1 root  maildrop  206532 Jan 25 12:21 /usr/sbin/postqueue
200 -rwxr-xr-x  1 root  wheel 101720 Jan 25 12:21 /usr/sbin/postsuper
336 -rwxr-xr-x  1 root  wheel 168984 Jan 25 12:21 /usr/sbin/posttls-finger

And yes, the 25th is when I installed postfix 2.11.3




-- 
FRIDAYS ARE NOT PANTS OPTIONAL Bart chalkboard Ep. AABF23

Re: Exempt domain before postscreen tests?

[LuKreme]

On 12 Dec 2014, at 07:24 , Isaac Grover isaac.gro...@gmail.com wrote:
 We have users on a domain who are convinced they are losing emails due to our 
 spam filtering (postscreen, amavis, spamassassin). We have shown them logs of 
 legitimate spam being filtered with no false positives, but they want to be 
 exempt from all spam filtering.

Postscreen filtering doesn’t delete email, it rejects it. The sender would have 
an immediate notification that the mail was not delivered. Unless they can show 
such rejections for legitimate mail I would tell them they need to trust that I 
know what I am doing and that I am not willing to open up my mailserver to 
abuse.

If that’s not good enough, I am sure there are some terrible mailhosts out 
there that will allow all mail to their domain. Or they can get a colo machine 
and run their own mailserver. At some point, it becomes an issue of respect, 
either they trust you to do your job, or they don’t. If they don’t trust you 
and respect you, you’re better off without them.

 Is it possible to exempt their domain from postscreen filtering, so they 
 receive every single email addressed to anyone in their organization, spam or 
 not?

I sure can’t think of a way since many of the post screen tests (well, all of 
them) will be before the destination domain is known, right?


True story: A number of years ago I administered the network for an office 
building with a T1 that included domain and mail hosting as part of the lease 
for each office. One of the people in the building got a new web designer who 
insisted they *had* to move their hosting to somewhere else. No skin off my 
nose, I get paid by the building owner. Anyway, their email volume (well, spam 
volume) on their new host was so massive that we had to rate-limit their access 
to the T1 because simply checking their mail was impacting the other offices. 
Their new host not only did not spam check at all, but also dumped *@domain.tld 
into their “main” mailbox. Their mail volume had increased more than a 
thousandfold, iirc.

Good times. And that was long before postscreen and reliable RBLs.

-- 
No one heard the cry that came back from the dead skull, because there
was no mouth to utter it and not even a mind to guide it, but it
screamed out into the night: CLAY OF MY CLAY, THOU SHALT NOT KILL! THOU
SHALT NOT DIE! --Feet of Clay

Re: Postfix seems to deliver mail and then remove it

[LuKreme]

On Dec 9, 2014, at 12:02 AM, Bernard T. Higonnet bthigon...@gmail.com wrote:
 
 Dec 9 07:11:23 freebsd postfix/local[20502]: 62015C382F:
 to=outjour...@higonnet.net, relay=local, delay=0.17,
 delays=0.15/0.02/0/0, dsn=2.0.0, status=sent (delivered to maildir)
 
 Dec 9 07:11:23 freebsd postfix/qmgr[20416]: 62015C382F: removed

This is perfectly normal, and if you look t the services that are login, it’s 
pretty clear.

Postfix/local delivers the mail. The qmgr removes the “62015C382F queue file.

You need to figure out where the maildir is. In a pinch, you can search your 
disk for files containing “62015C382F” since that queue ID will be in the 
received header.

Received: from russian-caravan.cloud9.net (russian-caravan.cloud9.net 
[168.100.1.4]) 
by mail.covisp.net (Postfix) with ESMTPS id 06FF450D33D

So, for me I could grep for files containing “mail.covisp.net*[QUID]

-- 
You know a thorn can main / But a lover does the same / A gem will
reflect light / And a Fool will marvel at the sight / A fool such as me,
/Who sees not the gold, but the beauty of the shine

Re: delaying mail before passing to next hop

[LuKreme]

On Nov 13, 2014, at 1:02 PM, Noel Jones njo...@megan.vbhcs.org wrote:
 This is exactly why greylisting was invented.  Have you tried that?

Greylisting has a host of problems of its own though. Even with a dedicated 
mail admin who is really trying to keep up on all the mail coming in, you 
*will* lose mail with greylisting.

-- 
Otto: Apes don't read philosophy.
Wanda: Yes, they do Otto, they just don't understand it.

Re: HTML bounces

[LuKreme]

On 17 Oct 2014, at 04:51 , Wietse Venema wie...@porcupine.org wrote:
 The harder you try, the fewer people will read your bounce message.

Honestly, I do not think it is possible for there to be fewer people who read 
bounces.

Customized LOCAL bounce messages would be nifty. I don't want HTML ones but 
customizing the messages for local users would be nice. Some extensibility to 
the variables available might be nice too, to allow more customizations to the 
bounce message.

Not a feature request, per se, but if it showed up somewhere down the line it's 
a feature I'd use.


-- 
'I think, if you want thousands, you've got to fight for one.'

Re: SSL v3

[LuKreme]

On 15 Oct 2014, at 11:08 , Mike Cardwell post...@lists.grepular.com wrote:
 I'd be interested to hear figures regarding how much traffic would
 change from being encrypted to plain text if SSLv3 was dropped for
 SMTP...

Well, my server has it enabled and it's used. I don't think there's a problem 
with it for smtpd.

This is what my home connection to my server looks like:

submit-tls/smtpd[10060]: xx.xx.xx.xx: reloaded session 
EB75...s=submissionl=268439711 from smtpd cache
submit-tls/smtpd[10060]: SSL_accept:SSLv3 read client hello A
submit-tls/smtpd[10060]: SSL_accept:SSLv3 write server hello A
submit-tls/smtpd[10060]: SSL_accept:SSLv3 write change cipher spec A
submit-tls/smtpd[10060]: SSL_accept:SSLv3 write finished A
submit-tls/smtpd[10060]: SSL_accept:SSLv3 flush data
submit-tls/smtpd[10060]: SSL_accept:SSLv3 read finished A
submit-tls/smtpd[10060]: xx.xx.xx.xx: Reusing old session
submit-tls/smtpd[10060]: Anonymous TLS connection established from xx.xx.xx.xx: 
TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
submit-tls/smtpd[10060]: BB44E50D490: client=xx.xx.xx.xx, sasl_method=PLAIN, 
sasl_username=kreme

Is there any sort of vector against smtpd?

-- 
Suddenly the animals look shiny and new

Re: OT: Fail2ban linux

[LuKreme]

On Oct 13, 2014, at 06:48, Markus Benning i...@markusbenning.de wrote:
 The mtpolicyd policy daemon has a plugin for directly adding IPs to
 a fail2ban target without the logging/parsing.
 It directly uses the unix socket for communication with the fail2ban
 daemon.
 
 https://www.mtpolicyd.org/
 
 Plugin:
 
 http://www.mtpolicyd.org/documentation.html#Mail::MtPolicyd::Plugin::Fail2Ban

That sounds excellent. Thanks for the pointer

Re: Is it possible to require authentication based on specific properties of the MUA or its connection?

[LuKreme]

On 14 Oct 2014, at 08:38 , Ben Johnson b...@indietorrent.org wrote:
 Basically, my concern is that most sites have a legitimate need to send
 email in one form or another (notices to admins, CMS system emails, new
 user registrations, web form submissions, etc.), so I'd need to
 whitelist virtually all of the unique PHP users, thereby mitigating the
 usefulness of this type of control (and perhaps even creating additional
 administrative overhead).

You simply make them use standard libraries and authenticated SMTP.

FSVO of “simply”, of course.

 I missed the uid=5027! How foolish of me! *** pssschk!!! slaps own
 face ***
 
 This ties the abuse to a particular website, which is all I really
 wanted. So, THANK YOU!

Glad you got it sorted. The last time this happened to me with php I had a lot 
more trouble finding the source of the problem.

Now I have all the web stuff on a separate machine from the mail, so it is not 
possible for web sites to send mail without doing it properly or using someone 
else’s mail server.

-- 
'I'm just going to kick some arse dear' 'Oh, good. Just be sure you wrap
up well, then.'

Re: Compiling new postfix same as the old postfix

[LuKreme]

On 10 Oct 2014, at 18:42 , Wietse Venema wie...@porcupine.org wrote:
 A few minutes ago I updated the makedefs script so that it documents
 the make makefiles options in a comment at the beginning of the
 file makedefs.out which is usually installed in $config_directory.

Is this something that will help me reconstruct the make flags I used when I 
compiled 2.10 or just a useful feature for the future?

-- 
Oh my god. What can it be? We're all doomed! Who's flying this thing!?
(pause) Oh right, that would be me, back to work.

Re: Postfix 3.0

[LuKreme]

On 10 Oct 2014, at 11:55 , Wietse Venema wie...@porcupine.org wrote:
 However with the incompatible changes in 2), I think that a major
 version number change is necessary. This may cause some delays in
 adoption, but I think it is only fair to people who have come to
 expect that upgrading Postfix is a no-brainer, because due to the
 changes in 2), I think is is not a no-brainer.

It seems reasonable, but it will cause many delays in adoption. First of all, 
there are plenty of people/admins/site that have (at least effectively) 
policies against installing a x.0 release, so many of those will not update 
until 3.1.

I’m not saying that’s a reason to not move to 3.x, but it probably deserves 
consideration that many sites will be stalled on 2.11 for a good long time. Is 
2.11 a good place to be stuck on long-term?

If I were in charge, I think I would look at releasing 2.12 and 3.0 nearly 
concurrently, with the difference being mainly that 2.12 has the backward 
compatible checking of the conf files while 3.0 does not and moves forward with 
the new defaults. Mark 2.12 as a transition release (maybe with a shorter 
TTL/support window).

This is just off-the-cuff, there’s probably a really good reason not to do this 
that I’m not thinking of.

-- 
Sam, I thought I told you never to play--

Re: Thank you, Wietse

[LuKreme]

On 10 Oct 2014, at 18:49 , Stephen Satchell l...@satchell.net wrote:
 Sometimes we just need to say this.

Probably every day, but then the list would get kinda spammy and boring.

But yes, thanks.

-- 
Cecil is made of blood and unfinished leather

Re: valid email addresses being rejected

[LuKreme]

On 11 Oct 2014, at 17:43 , li...@rhsoft.net wrote:
 Am 12.10.2014 um 01:35 schrieb Benny Pedersen:
 On October 10, 2014 11:35:09 PM Robert Lopez rlopez...@gmail.com wrote:
 
 I looked at the Please see.  Thanks!  I will try this out.
 
 postfix stop  postmap hash:/etc/postfix/hashfile  postfix start
 
 Loosy workaround
 
 that is *not* a workaround, that is a joke, you really do not want to hard 
 stop services for updates - never ever

Well… it depends on how much traffic that service gets, really. On a small 
mailserver I’d have no trouble doing that. But honestly, I would probably just 
postmap /etc/postfix/file  postfix reload

 just generate your map file in a temp folder, map it there and move both 
 files to /etc/postfix, you can easily do that for a lot of map files and only 
 if the result have changed compared with the ones in /etc/postfix move them 
 at the end and isse a one time reload

Yes, that is certainly the way to to it right, and really the only choice on a 
busy server.

-- 
I think I found your marbles.

Compiling new postfix same as the old postfix

[LuKreme]

I seem to have mislaid the note file in which I kept the build options that I 
built postfix with, and I am planning on recompiling a new version of postfix 
soon (It was supposed to be last month).

What can I look at to figure out what the build options were for the currently 
installed version so I can try to match them as closely on the new compile?


-- 
You are in my inappropriate thoughts

Re: Another policy server question...

[LuKreme]

On 09 Oct 2014, at 13:50 , Ronald F. Guilmette r...@tristatelogic.com wrote:
 No one sensible would dispute your skill as a software developer,
 but I'll put my own understanding of the English language up against
 your's,

Funniest thing all day. Hurray for Skitt’s Law.

-- 
'I thought we could do it without anyone getting hurt. By using our
brains.' 'Can't. History don't work like that. Blood first, then
brains.' 'Mountains of skulls,' said Truckle. 'There's got to be a
better way than fighting,' said Mr Saveloy. 'Yep. Lots of 'em. Only
none of 'em work.'

virtual_alias_maps order

[LuKreme]

virtual_alias_maps = 
hash:$config_directory/virtual
pcre:$config_directory/virtual.pcre,
pcre:$config_directory/virtual_sql.pcre,
proxy:mysql:$config_directory/mysql_virtual_alias_maps.cf

I want to be sure that the ORDER of declarations in virtual_alias_maps is 
significant. For example, if something matches in virtual it will always match 
and not be overridden by a match in virtual.pcre.

virtual:
u...@d1.tldu...@d1.tld,us...@d1.tld,user-foo...@d2.tld

virtual.pcre
/^user-(.*)@d2\.tld$/ user+${1}@d3.tld

this will *always* cause u...@d1.tld to send a copy to user+foo...@d3.tld, 
u...@d1.tld, and us...@d1.tld

Or, does the order NOT matter because us...@d1.tld and user-foo...@d2.tld 
renter the virtual queue “at the top” and get processed on their own? Come to 
think of it, this makes the most sense.

-- 
Kid 1: What are the four horsemen of the apocalypse?
Dad: War, death, famine and pestilence.
Kid 2: You forgot flatulence!

Re: virtual_alias_maps order

[LuKreme]

On 07 Oct 2014, at 11:24 , Wietse Venema wie...@porcupine.org wrote:
 However, lookup is recursive. The above result from B will be used
 for a subsequent query. That may still query A and B and C, finding
 a result in C.

Excellent! Than you.

-- 
Vader means father in German.
Oh, you know German. Now I know why you don't like fun things.

Re: Discuss: safety net for other compatibility breaks

[LuKreme]

On 07 Oct 2014, at 15:55 , Wietse Venema wie...@porcupine.org wrote:
 As for biff, I haven't used that since I switched from a BSD/OS 
 workstation to a FreeBSD server in 2000. Fourteen years of UDP
 datagrams wasted...

It was pretty cool back in the 90s though, unless you were playing mTrek when 
you got the biff. For some reason, I could never get the screen to redraw 
enough to get rid of all the biff.

Those were the days.

-- 
Why do you wear that stupid bunny suit? Why are you wearing that
stupid man suit?

Re: FYI: blocking attachment extensions

[LuKreme]

 On 03 Oct 2014, at 11:26 , li...@rhsoft.net wrote:
 
 
 Am 03.10.2014 um 19:13 schrieb Philip Prindeville:
 I don’t necessarily trust just the extension of the filename.
 
 I’d also look at the file’s magic (same as the OS does) as well as the 
 content-type.
 Can’t be too thorough
 
 that topic is not a matter of trusting

Exactly.

 it's a matter of put different filters with differenct performance
 and security impact in the right order - if the client announces
 a banned extension you reject there is just nothing for file’s
 magic because you don't reveive it

And checking the file’s magic is expensive (especially if it’s in an archive).

 everybody knows that you must not rely on extensions but keep in mind
 that the file package not only once time had it's own security flaws
 and some of them short ago so receive the attachment and inspect even
 may lead in code execution on your server

The extension check is also the simplest way to exclude files that will 
automatically execute on a Windows system (at least historically, and on far 
too many existing Windows XP installs).

-- 
And she was looking at herself
And things were looking like a movie
She had a pleasant elevation
She's moving out in all directions

Re: Accept mail from non-exsistent users

[LuKreme]

On 30 Sep 2014, at 23:22 , Vijay Rajah m...@rvijay.me wrote:
 I need to send mails from one of my servers, with a sender address that is 
 non-existent (EX: no-re...@mydomain.tld)..
 
 The mail-hub (postfix 2.11) is rejecting the sender address, with
 
 Sender address rejected: User unknown in virtual mailbox table)
 
 I suspect this is because I have smtpd_reject_unlisted_sender = yes in my 
 main.cf

Yes, that would be why. Don’t do that.

-- 
I've had a perfectly wonderful evening. But this wasn't it. - Groucho
Marx

Re: Thanks: Input requested: append_dot_mydomain default change

[LuKreme]

On 26 Sep 2014, at 13:04 , John j...@klam.ca wrote:
 The idea of handing out email addresses that do not have a fully qualified 
 domain in them seems to be rather dumb. 

The issue, as I understand it, is in files like aliases or virtual where you 
may have something like

user...@secondarydomin.tld userbar

userbar is implied to be user...@primarydomain.tld.

-- 
You know what they say about paradigms:  Shift happens.

Re: Add --version option to postfix

[LuKreme]

On 27 Sep 2014, at 09:19 , Charles Marcus cmar...@media-brokers.com wrote:
 On 9/27/2014 11:07 AM, wie...@porcupine.org (Wietse Venema) 
 wie...@porcupine.org (Wietse Venema) wrote:
 Would an updated postfinger command help? Wietse 
 
 Well... if it could provide the output I described, then certainly. The 
 suggestion for a new command was just to illustrate I was saying it didn't 
 have to be a postconf command argument…

Have you run postfinger?

postfinger - postfix configuration on Sun Sep 28 08:54:53 MDT 2014
version: 1.30

Warning: postfinger output may show private configuration information,
such as ip addresses and/or domain names which you do not want to show
to the public.  If this is the case it is your responsibility to modify
the output to hide this private information.  [Remove this warning with
the --nowarn option.]

--System Parameters--
mail_version = 2.10.0
hostname = mail.covisp.net
uname = FreeBSD mail.covisp.net . . .
--Packaging information--

--main.cf non-default parameters--
alias_database = hash:$config_directory/aliases
. . .

--master.cf--
smtp unix  -   -   n   -   -   smtp
smtp inet  n   -   n   -   1   postscreen

. . .

Seems to  do exactly what you want.

-- 
Dinosaurs are attacking! Throw a barrel!

recipient_delimiter in 2.11

[LuKreme]

Is there documentation on how recipient_delimiter is treated in 2.11 if there 
is more than one delimiter defined?

recipient_delimiter = +-_

if an email comes to foo-bar_fee+...@domain.tld, is the precedence left to 
right from the definition, right to left from the definition, first match in 
email, or undefined?

Since postfix only checks for a single delimiter, I assume there is no way to 
check for multiple delimiters during the SMTPD transaction.

-- 
Oh damn, said Maladict.

Re: recipient_delimiter in 2.11

[LuKreme]

On 28 Sep 2014, at 09:14 , Wietse Venema wie...@porcupine.org wrote:
   When  the recipient_delimiter set contains multiple characters (Postfix
   2.11 and later), a [name] is  separated  from its  extension
   by the first character that matches the recipient_delimiter set.

Thanks, I hadn’t found that as I was reading the release notes.

-- 
Otto: Apes don't read philosophy.
Wanda: Yes, they do Otto, they just don't understand it.

Re: Add --version option to postfix

[LuKreme]

 On 28 Sep 2014, at 09:53 , Charles Marcus cmar...@media-brokers.com wrote:
 
 On 9/28/2014 10:57 AM, LuKreme krem...@kreme.com wrote:
 On 27 Sep 2014, at 09:19 , Charles Marcus cmar...@media-brokers.com wrote:
 On 9/27/2014 11:07 AM, wie...@porcupine.org (Wietse Venema) 
 wie...@porcupine.org (Wietse Venema) wrote:
 Would an updated postfinger command help? Wietse 
 
 Well... if it could provide the output I described, then certainly. The 
 suggestion for a new command was just to illustrate I was saying it didn't 
 have to be a postconf command argument…
 Have you run postfinger?
 
 # man postfinger
 No manual entry for postfinger
 # postfinger
 -su: postfinger: command not found

Right. Install it.

 Seems to  do exactly what you want.
 
 Yes, but I've never used it, because it still isn't a part of the normal
 postfix sources at least not in anything I've run up to this point.

Yes, it’s a separate package.

-- 
Rule #5: Get Kirsten Dunst Wet

Rate limiting users?

[LuKreme]

Not sure if this is even a postfix question, but let's say for the sake of 
argument I want to set the following limits for user accounts:

1) maximum 100 mails in x minutes
2) maximum 1000 mails per day
3) maximum X MB output per day
4) exclude some users (for example, mailman)

Where do I start?

-- 
Rincewind had always been happy to think of himself as a racist. The
One Hundred Meters, the Mile, the Marathon -- he'd run them all.

Re: Rate limiting users?

[LuKreme]

 On 24 Sep 2014, at 10:57 , li...@rhsoft.net wrote:
 
 
 Am 24.09.2014 um 18:45 schrieb LuKreme:
 Not sure if this is even a postfix question, but let's say for the sake of 
 argument I want to set the following limits for user accounts:
 
 1) maximum 100 mails in x minutes
 
 not per user but per client IP

Yeah, that won't work. Most users come from a single IP (the webmail server), 
and the rest will come from single IPs with multiple users.

I'm reading about postfwd right now.

-- 
Han : Not a bad bit of rescuing, huh? You know, sometimes I amaze even
myself. Leia: That doesn't sound too hard.

Re: Input requested: append_dot_mydomain default change

[LuKreme]

On 24 Sep 2014, at 11:16 , Ansgar Wiechers li...@planetcobalt.net wrote:
 On 2014-09-23 A. Schulze wrote:
 I already explicit set 'append_dot_mydomain = no'.

 Same here.

Is there any simple way to test if setting this will break things other than 
setting it and watching the logs?

-- 
The way I see it, the longer I put it off, the better it'll end up
being. Heck, school doesn't start for another 43 minutes.

Re: Input requested: append_dot_mydomain default change

[LuKreme]

On 22 Sep 2014, at 12:29 , Noel Jones njo...@megan.vbhcs.org wrote:
 My thought: there are popular distros that have set this explicitly
 to no for years, and yet we get very few questions here where the
 artificial no setting causes a problem. So in a sense it's already
 been tested for us.

Sort of.

Is there a way to test a existing install to see if this will break things?

The way I look at it, someone who has never set the flag to no may have built 
things in their install assuming the default value and have no idea that 
something might break when the default is changed.

Is there anything like warn_if_fail append_dot_mydomain? Should there be?

As for things that COULD break, any lookups COULD break, right?

-- 
Say, give it up, give it up, television's taking its toll That's enough,
that's enough, gimme the remote control I've been nice, I've been good,
please don't do this to me Turn it off, turn it off, I don't want to
have to see

Re: localhost.com

[LuKreme]

On 19 Sep 2014, at 20:58 , Ruben Safir ru...@mrbrklyn.com wrote:
 I used fetchmail to retreive email from the university and it hands off
 the local system which cause the mail to try to be forward to
 localhost.com.  Obviously I've made a big error somewhere, but I can't
 track it down

$ dig localhost.com | grep -A1 ANSWER | tail -1
localhost.com.  5588IN  A   74.125.224.72

Is that your domain and your IP?

Hint: Don’t make up domain names.

-- 
Light thinks it travels faster than anything but it's wrong. No matter
how fast light travels it finds the darkness has always got there first,
and is waiting for it. --Reaper Man

Re: current best practice on the usage of the reject_unknown_hostname

[LuKreme]

On 16 Sep 2014, at 17:59 , Bill Cole 
postfixlists-070...@billmail.scconsult.com wrote:
 It is much safer to use 'reject_invalid_helo_hostname' or 
 'reject_non_fqdn_helo_hostname' or for maximal safety to use a 
 'check_helo_access' map to specifically reject HELO names  patterns that 
 fingerprint spambots (e.g. 'friend', 'ylmf-pc', '[127.0.0.1]', your own local 
 names/IPs, etc.) or gross incompetence (unqualified names, *.local, etc.) and 
 perhaps to exempt special cases where you are willing to tolerate 
 incompetence.

I suspect a lot of people get reject_invalid_helo_hostname and 
reject_unknown_helo_hostname confused.

I think you can always add the following and then look at your logs:

warn_if_reject reject_unknown_helo_hostname

I used to have a helo check, but no longer use it:

$ cat helo_checks.pcre 
/(unknown|localhost|localdomain|lan|home|example|local)$/ REJECT Mailserver 
name in private namespace
/kreme\.com$/ REJECT helo Don't spoof my hostname 
#several more like that for various domains.
/(\d{1,3}[.-]){3}[.-]\d{1,3}/ WARN Too many numbers in your HELO/EHLO (D)
/([[:digit:]]{1,3}[.-]){3}[[:digit:]]{1,3}/ WARN Too many numbers in HELO/EHLO 
(dig)
/\.(dsl|adsl|pool|dynamic|user|hsd|dyn|dial)/ REJECT helo Dynamic . servers not 
allowed
/^(dsl|adsl|pool|dynamic|user|hsd|dyn|dial)/ REJECT helo Dynamic ^ servers not 
allowed
/home\.com$/ REJECT home.com is poisoned


-- 
I'll have what the gentleman on the floor is having.

can check_helo_access go in smtpd_helo_restrictions?

[LuKreme]

Subject kind of says it all, can you put check_helo_access in the 
smtpd_helo_restrictions block or does it need to be in 
smtp_recipient_restrictions?

-- 
Good old Dame Fortune. You can _depend_ on her.

Re: postscreen deep protocol tests and Amazon timeouts

[LuKreme]

On 15 Sep 2014, at 14:31 , Andrew J. Schorr asch...@telemetry-investments.com 
wrote:
 I could be wrong, but if greylisting works reliably,

And there we get to the root of the problem. It does not work reliably because 
it ignores how large companies like Google and Yahoo and Amazon send mail. 
Greylisting, *BY DESIGN* screws up large company email. The entire basis of 
greylisting is that a single mail server sends email, and that is just not how 
email works for large senders.

-- 
BILL: I can't get behind the Gods, who are more vengeful, angry, an
dangerous if you don't believe in them!
HENRY: Why can't all these God just get along? I mean, they're
omnipotent and omnipresent, what's the problem?

Re: postscreen deep protocol tests and Amazon timeouts

[LuKreme]

 On 16 Sep 2014, at 05:41 , Uwe Drießen dries...@fblan.de wrote:
 
 -Ursprüngliche Nachricht-
 Von: owner-postfix-us...@postfix.org [mailto:owner-postfix-
 us...@postfix.org] Im Auftrag von LuKreme
 Gesendet: Dienstag, 16. September 2014 12:48
 An: postfix-users@postfix.org
 Betreff: Re: postscreen deep protocol tests and Amazon timeouts
 
 On 15 Sep 2014, at 14:31 , Andrew J. Schorr aschorr@telemetry-
 investments.com wrote:
 I could be wrong, but if greylisting works reliably,
 
 And there we get to the root of the problem. It does not work reliably
 because it ignores how large companies like Google and Yahoo and Amazon
 send mail. Greylisting, *BY DESIGN* screws up large company email. The
 entire basis of greylisting is that a single mail server sends email, and
 that is
 just not how email works for large senders.
 
 
 If my Server had a problem the big sender becomes the same error like
 greylisting
 If the big sender can not handle it they breaks the RFC not I.
 They  want to SEND a mail to me so I make the rules !!

This is fine if your server serves email to just you.

But when a customer or a executive doesn’t get his email from Amazon or Google, 
you don’t get to say “They are not following the RFCs.”

 E-Mail is not real time communication by design !

You’re living in the 90s. If someone is expecting an email and it’s delayed by 
5 minutes I hear about it.

Greylisting large companies like Google, Yahoo, Amazon, Apple, etc is *stupid*.

-- 
Carlin's Third Commandment: Thou shall keep thy religion to thyself.

Re: current best practice on the usage of the reject_unknown_hostname

[LuKreme]

On 16 Sep 2014, at 15:24 , AndreaML andre...@z80.it wrote:
 Sep 16 06:42:00 server1 postfix/smtpd[4257]: NOQUEUE: reject: RCPT from 
 wr001msr.fastwebnet.it[85.18.95.77]: 450 4.7.1 wr001msr.intranet.fw: Helo 
 command rejected: Host not found; from=VALID_ADDRESS to=VALID_ADDRESS 
 proto=ESMTP helo=wr001msr.intranet.fw
 
 for a transaction of a prefectly valid test email i sent to myself.

Since your helo name does not exist, this is correct.

I see very few rejections (relatively speaking) for non-existing domains or 
hosts. They are, definitionally, invalid emails. I haven’t looked closely, but 
I haven’t had anyone complain in quite a long time about missing mail.

The there most recent are:

1E.bnsfd.com
Nyt.pilisofe.com
friendswhatitappears.in

-- 
An ounce of practice is worth more than tons of preaching. - Mohandas
Gandhi

Re: FYI: blocking attachment extensions

[LuKreme]

 On 16 Sep 2014, at 13:00 , Viktor Dukhovni postfix-us...@dukhovni.org wrote:
 
 On Tue, Sep 16, 2014 at 01:41:36PM -0500, Noel Jones wrote:
 
 I've used the below for a few years with good results.  It's better,
 but surely not perfect.
 
 
 # block windows executables PCRE
 /^\s*Content-(Disposition|Type).*name\s*=\s*?(.*(\.|=2E)(
 ade|adp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|hlp|hta|
 inf|ins|isp|js|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|
 ops|pcd|pif|prf|reg|scf|scr|sct|shb|shs|shm|swf|
 vb|vbe|vbs|vbx|vxd|wsc|wsf|wsh))(\?=)??\s*$/x
 
 This assumes that name or filename is the last attribute in
 the header.  It might instead be followed by a ; and more
 attributes.  So for a bit more generality, try the below:
 
# block windows executables PCRE
/^\s*Content-(?:Disposition|Type): # Header label
  (?:.*?;)? \s*# Any prior attributes
  (?:file)?name\s*=\s*?   # name or filename
   (   # Capture name for response
.*?(\.|=2E)# File basename and .
 (ade|adp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|hlp|hta|
  inf|ins|isp|js|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|
  ops|pcd|pif|prf|reg|scf|scr|sct|shb|shs|shm|swf|
  vb|vbe|vbs|vbx|vxd|wsc|wsf|wsh)  # Capture risky extensions
   )   # Close capture
   (?:\?=)?# Trailer of ad-hoc RFC 2047 
 encoding
   ?  # Optional close quote
   \s*(;|$)# End of attribute or header
 /x
 
 [ untested ]

Hmm. I’ve been using the same check as Noel for many years. More than 10. I’ve 
never received an attachment in that list, so … 

-- 
The Earth is like a tiny grain of sand, only much, much heavier.

Re: Why does EHLO [X.X.X.X] always pass helo restrictions?

[LuKreme]

On 12 Sep 2014, at 13:55 , li...@rhsoft.net wrote:
 Am 12.09.2014 um 21:49 schrieb Philip Prindeville:
 However, any time I connect via telnet to this server and specify
 *any* IP address in the form [X.X.X.X], the smtpd_helo_restrictions
 won't trigger.
 This is both legal and reasonable.
 
 it maybe true but it is *not* reasonable

What do you base that on?

What problem are you having that you are trying to solve?


-- 
'They were myths and they were real,' he said loudly. 'Both a wave and a
particle.' --Guards! Guards!