Re: smtpd_reject_footer and smtps

2018-04-26 Thread Wietse Venema
micah:
> Noel Jones  writes:
> 
> > Spaces are not directly supported in master.cf arguments.
> 
> Yes, of course... I should have realized that.
> 
> > If you have postfix 3.0 or newer, you can enclose the option in braces.
> >   -o { smtpd_reject_footer = ... }
> 
> I don't have 3.0 (yet!)
> 
> > or for any postfix version, you can reference a macro in main.cf
> >
> > # main.cf
> > submit_reject_footer = ...
> >
> > # master.cf
> >   -o smtpd_reject_footer=$submit_reject_footer
> 
> I tried this and was told
> 
> postfix[20227]: /usr/sbin/postconf: warning: /etc/postfix/main.cf: unused 
> parameter: submit_reject_footer=\c For further help, contact support

The postconf command still needs special code to look inside
submit_reject_footer, because that setting may contain things like
$localtime and $client_address that aren't main.cf parameters.

(it needs custom code for each 'type RAW' parameter).

I have added a TODO, and may fix this in the near future.

> postfix/smtpd[21083]: warning: unknown macro name "submit_reject_footer" in 
> expansion request

That may be because there was no main.cf setting at the time.

Wietse


Re: smtpd_reject_footer and smtps

2018-04-26 Thread Viktor Dukhovni


> On Apr 26, 2018, at 2:40 PM, micah  wrote:
> 
> I tried this and was told
> 
> postfix[20227]: /usr/sbin/postconf: warning: /etc/postfix/main.cf: unused 
> parameter: submit_reject_footer=\c For further help, contact support
> postfix/smtpd[21083]: warning: unknown macro name "submit_reject_footer" in 
> expansion request
> 
> (this is postfix 2.11)

Ignore the warning. So long as the parameter *is* used in master.cf, you're 
fine.
I don't recall when the warning code started to look for use in master.cf, so
do check that your master.cf use is syntactically correct, ...

-- 
Viktor.



Re: rsyslogd and postfix

2018-04-26 Thread @lbutlr
On 2018-04-26 (06:46 MDT), Mike  wrote:
> 
> I have a similar log strategy but I let postfix do it for me.
> 
> For example, my postscreen entry in master.cf is:
> 
> 
> smtp  inet  n   -   n   -   1   postscreen
>   -o syslog_facility=local2
> 
> 
> 
> That sends the postscreen logging to the local2 log facility.

Sure that's a perfectly workable solution, but I am able to log the specific 
information that I nearly never need into a specific log file without having to 
keep track of which of the nearly identically named local1 local2 etc 
facilities is setup for what. It's also easy for me to add other data that I 
don't need in the logs (like I have one automated user who logins in ever 3 
minutes. The only thing I ever need to know is if that login fails for some 
reason or all the warnings about hosts not resolving (but not any other 
warnings)). there's a lot more flexibility in configuring rsyslog than there is 
in simply using local1-local6.

But, whatever works for you is fine. I was just sharing what worked for *me* in 
case it was of use to someone else.

-- 
'Are you Death?' IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE
SCYTHE.



Re: smtpd_reject_footer and smtps

2018-04-26 Thread micah
Noel Jones  writes:

> Spaces are not directly supported in master.cf arguments.

Yes, of course... I should have realized that.

> If you have postfix 3.0 or newer, you can enclose the option in braces.
>   -o { smtpd_reject_footer = ... }

I don't have 3.0 (yet!)

> or for any postfix version, you can reference a macro in main.cf
>
> # main.cf
> submit_reject_footer = ...
>
> # master.cf
>   -o smtpd_reject_footer=$submit_reject_footer

I tried this and was told

postfix[20227]: /usr/sbin/postconf: warning: /etc/postfix/main.cf: unused 
parameter: submit_reject_footer=\c For further help, contact support
postfix/smtpd[21083]: warning: unknown macro name "submit_reject_footer" in 
expansion request

(this is postfix 2.11)

micah


Re: smtpd_reject_footer and smtps

2018-04-26 Thread Noel Jones
On 4/26/2018 7:14 AM, micah anderson wrote:
> 
> Hello,
> 
> I tried to add a smtpd_reject_footer to submission and smtps as an
> option in my master.cf:
> 
> submission inet n   -   n   -   -   smtpd -o 
> smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_reject_footer=\c 
> For further help, contact the support desk
> smtps inet  n   -   n   -   -   smtpd -o 
> smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o 
> smtpd_reject_footer=\c For further help, contact the support desk
> 
> the submission one took, but with smtps, I got an error:
> 
> "fatal: unexpected command-line argument: For"
> 
> why is it that this does not work for smtps?
> 

Spaces are not directly supported in master.cf arguments.

If you have postfix 3.0 or newer, you can enclose the option in braces.
  -o { smtpd_reject_footer = ... }


or for any postfix version, you can reference a macro in main.cf

# main.cf
submit_reject_footer = ...

# master.cf
  -o smtpd_reject_footer=$submit_reject_footer


http://www.postfix.org/master.5.html
http://www.postfix.org/postconf.5.html



  -- Noel Jones


smtpd_reject_footer and smtps

2018-04-26 Thread micah anderson

Hello,

I tried to add a smtpd_reject_footer to submission and smtps as an
option in my master.cf:

submission inet n   -   n   -   -   smtpd -o 
smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_reject_footer=\c 
For further help, contact the support desk
smtps inet  n   -   n   -   -   smtpd -o 
smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o 
smtpd_reject_footer=\c For further help, contact the support desk

the submission one took, but with smtps, I got an error:

"fatal: unexpected command-line argument: For"

why is it that this does not work for smtps?

thanks,
micah


Re: rsyslogd and postfix

2018-04-26 Thread Mike
On 4/25/2018 2:08 PM, @lbutlr wrote:
> This might be of use to others out there. I decided that monitoring mail.log 
> was too much of a pain with all the postscreen and dnsblog 'noise' from 
> obscuring the information that I wanted to see, so I split those log events 
> into their own log file using rsyslogd with the following lines in 
> rsyslogd.conf (before the lines that log mail.log)
> 
> if $syslogtag contains 'postscreen' then /var/log/postscreen.log
> if $syslogtag contains 'postscreen' then ~
> if $syslogtag contains 'dnsblog' then /var/log/postscreen.log
> if $syslogtag contains 'dnsblog' then ~
> 
> This lets me keep mail.log for quite a while and rotate off postscreen.log 
> very quickly since it is not something I need to check very often at all.
> 
> I've been doing this for a week or two now and found it useful enough I 
> thought it worth passing along.

I have a similar log strategy but I let postfix do it for me.

For example, my postscreen entry in master.cf is:


smtp  inet  n   -   n   -   1   postscreen
-o syslog_facility=local2



That sends the postscreen logging to the local2 log facility.


Re: Virtual Alias and To header rewrite

2018-04-26 Thread Wietse Venema
Wietse Venema:
> Dominic Raferd:
> > >
> > > Diagnostic information for administrators:
> > > Generating server: FFExchange3.jellybelly.net
> > > original_email_addr...@accounts.jellybelly.com...
> > 
> > The log entry placed by postfix/smtp (in e.g. /var/log/mail.log), and
> > which contains the rejection response from the remote server, should
> > contain both the original and remapped mail addresses. Something like:
> > 
> > 2018-03-29 16:21:07 yourserver postfix/smtp[2041]: 3127960764:
> > to=, orig_to=,
> > relay=gmail-smtp-in.l.google.com[66.102.1.27]:25, delay=0.73,
> > delays=0.02/0.02/0.47/0.21, dsn=5.7.0, status=bounced (host
> > gmail-smtp-in.l.google.com[66.102.1.27] said: 552-5.7.0 This
> > message...  - gsmtp (in reply to end of DATA command))
> 
> Unfortunately the bounce report quoted above (with "Diagnostic
> information for administrators") is not produced by Postfix.
> 
> The Postfix bounce report would say "Original-Recipient:
j...@yourdomain.tld
> 
>   Wietse
> 


Re: Virtual Alias and To header rewrite

2018-04-26 Thread Wietse Venema
Dominic Raferd:
> >
> > Diagnostic information for administrators:
> > Generating server: FFExchange3.jellybelly.net
> > original_email_addr...@accounts.jellybelly.com...
> 
> The log entry placed by postfix/smtp (in e.g. /var/log/mail.log), and
> which contains the rejection response from the remote server, should
> contain both the original and remapped mail addresses. Something like:
> 
> 2018-03-29 16:21:07 yourserver postfix/smtp[2041]: 3127960764:
> to=, orig_to=,
> relay=gmail-smtp-in.l.google.com[66.102.1.27]:25, delay=0.73,
> delays=0.02/0.02/0.47/0.21, dsn=5.7.0, status=bounced (host
> gmail-smtp-in.l.google.com[66.102.1.27] said: 552-5.7.0 This
> message...  - gsmtp (in reply to end of DATA command))

Unfortunately the bounce report quoted above (with "Diagnostic
information for administrators") is not produced by Postfix.

The Postfix bounce report would say "Original-Recipient:
janedoe998...@gmail.com".

Wietse


Re: user unknown in virtual mailbox table

2018-04-26 Thread wilfried.es...@essignetz.de
Am 25.04.2018 um 19:44 schrieb Alfredo De Luca:
> Hi guys. any clue on this issue?

Not really, only some thougt:

Testing arel...@mydomain1.com   returns  "user unknown"

Testing arel...@mydomain2.com   returns  arel...@mydomain1.com

Where comes @mydomain1.com from? Thinks you provided doesn'g give an
idea. Maybe from extending "areluca" from parameters like mydomain /
myorigin / remote_header_rewrite_domain = $mydomain?

Where go mails to arel...@mydomain2.com? Possibly they go into what
postfix thinks is local mailbox of areluca? What the logs are saying for
that case?

You could try whats described under
http://www.postfix.org/ADDRESS_REWRITING_README.html#debugging



Have a good time!

Willi

> 
> /Alfredo
> 
> On Fri, 20 Apr 2018, 17:24 Alfredo De Luca, 
> wrote:
> 
>> Hi all. I had a run with postmap and these are the founding
>>
>> so we have mydomain1.com which is the original domain.and
>> mydomain2.com which is the actual domanin of our company.
>> So when I do the following
>>
>> - postmap -q arel...@mydomain1.comregexp:./domain_rewriting ldap:./
>> ldap-virtual-maps.cf
>>areluca basically doesn't exist with my mydomain1.com so...I get a
>> message back with *user unknown*
>>
>> - postmap -q arel...@mydomain2.comregexp:./domain_rewriting ldap:./
>> ldap-virtual-maps.cf
>> returns arel...@mydomain1.com..which DOESN\t exist. but cause it
>> find a result anyway I dont get any mail back saying *user unknown*
>>
>> So it's something in the ldap that I need to add or trigger.
>>
>> Maybe mailacceptinggeneralid will do the job accordingly to 
>> *http://www.postfix.org/LDAP_README.html#config?
>> ??*
>>
>>
>> Thanks
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Apr 20, 2018 at 4:03 PM, Viktor Dukhovni <
>> postfix-us...@dukhovni.org> wrote:
>>
>>>
>>>
 On Apr 20, 2018, at 8:03 AM, @lbutlr  wrote:

 The biggest issue between regex (POSIX) and PCRE is that POSIX regex is
>>> greedy. that is, it matches the longest possible left, while PCRE matches
>>> the shortest possible left.
>>>
>>> That's false (example uses a Bash in-line file):
>>>
>>>$ postmap -q aaa pcre:<(printf '%s\n' '/(a*)(a)/ $1:$2')
>>>aa:a
>>>
>>> however, PCRE does also provide non-greedy "*" and "+" variants:
>>>
>>>   $ postmap -q aaa pcre:<(printf '%s\n' '/(a+?)(a)/ $1:$2')
>>>   a:a
>>>
>>>   $ postmap -q aaa pcre:<(printf '%s\n' '/(a*?)(a)/ $1:$2')
>>>   :a
>>>
>>> --
>>> Viktor.
>>>
>>>
>>
>>
>> --
>> *Alfredo*
>>
>>
> 


-- 
Wilfried Essig
Narzissenstraße 6
75031 Eppingen (Adelshofen)
07262 / 20002
0151 / 50843898


SV: Postfix set up with postfixadmin, trying to create /dev/null account

2018-04-26 Thread K F
I decided to keep the mailbox, and now I've created a loop test in PRTG, so 
that it sends to the smtp server, which forwards to another of out mailservers 
(thus testing the forward), and it's now picked up from there. That will test 
it more thoroughly.Thankyou for the help! 

Den 14:29 onsdag den 25. april 2018 skrev "wilfried.es...@essignetz.de" 
:
 

 Hi,


suggest you to tell your postfix to accept mail for bounce.localdomain
for local delivery (http://www.postfix.org/postconf.5.html#mydestination)


Willi

Am 25.04.2018 um 11:11 schrieb K F:
> Hi All
> As I wrote above, this mailserver is set up with postfixadmin and mysql.
> I'm trying to set up a /dev/null mail account.So I've created an 
> aliasdevnull: /dev/nullAnd I've created a virtual mailbox on one of the 
> domains
> If I look in the MySQL database I see:
> select * from alias where address='relayt...@my.ownserver.com';
> +---+-+-+-+-++
> | address   | goto    | domain  | 
> created | modified    | active |
> +---+-+-+-+-++
> | relayt...@my.ownserver.com | devnull | my.ownserver.com | 2018-04-25 
> 10:18:24 | 2018-04-25 10:18:24 |  1 |
> +---+-+-+-+-++
> But if I look in the maillog I see this:Apr 25 10:28:13 bounce 
> postfix/smtp[61347]: 6A23E40ED1F2: to=, 
> orig_to=, relay=none, delay=22, 
> delays=22/0.01/0.02/0, dsn=5.4.4, status=bounced (Host or domain name not 
> found. Name service error for name=bounce.localdomain type=A: Host not found)
> The servers hostname is bounce.
> So what should I do?I tried changing the goto to devnull@localhost and also 
> devnull@bounce.localdomain but I still get errors.
> I hope somebody can help me out?
> Best wishesKenneth
> 


   

Re: Virtual Alias and To header rewrite

2018-04-26 Thread Dominic Raferd
On 25 April 2018 at 19:25, Gary Smith  wrote:
> Hi Everyone,
>
> It's been a long time since something in postfix has stumped me.  I am using 
> virtual alias rewrites to handle 50k incoming email addresses that expand to 
> 1+n recipients.  The recipients are the line managers and lower level people 
> that handle those accounts.  The virtual alias has been working in a general 
> sense, lately I have been receiving bounces from Comcast and google with 
> invalid recipients.  Normally this would be expected if a manager entered the 
> wrong email for a line member (these are outside consultants using gmail, 
> Comcast, etc).  The bounce however shows the original email address and not 
> the alias email address, so it's really hard to track down the email issue 
> this way.
>
> So I would like to either rewrite the "to" field or add a header with the 
> exploded virtual alias mapping.  From reading a few external articles the 
> email should already have the to field set in the header, but that 
> contradicts what I have read in the postfix virtual readme.  I have also 
> tried using a header_check to and a new header (which I can do for the 
> original address, but not the virtual alias mapped address).
>
> When it's bounces via gmail I get the bounce below, which shows the original 
> TO and not the expected virtual alias mapped.  I have several gmail accounts 
> that are successful however.
>
> What I would really like to do is add the envelope TO field to the TO header 
> of the outgoing emails.  Is this possible?  This would let us at least track 
> the bounces.  Is there a better approach?
>
> Bounce message:
>
> mx.google.com rejected your message to the following email addresses:
> original_email_address (original_email_addr...@accounts.jellybelly.com)
> The email address you entered couldn't be found. Please check the recipient's 
> email address and try to resend the message. If the problem continues, please 
> contact your email admin.
> mx.google.com gave this error:
> The email account that you tried to reach does not exist. Please try 
> double-checking the recipient's email address for typos or unnecessary 
> spaces. Learn more at https://support.google.com/mail/?p=NoSuchUser 
> p25si12399124pgd.395 - gsmtp
>
>
> Diagnostic information for administrators:
> Generating server: FFExchange3.jellybelly.net
> original_email_addr...@accounts.jellybelly.com...

The log entry placed by postfix/smtp (in e.g. /var/log/mail.log), and
which contains the rejection response from the remote server, should
contain both the original and remapped mail addresses. Something like:

2018-03-29 16:21:07 yourserver postfix/smtp[2041]: 3127960764:
to=, orig_to=,
relay=gmail-smtp-in.l.google.com[66.102.1.27]:25, delay=0.73,
delays=0.02/0.02/0.47/0.21, dsn=5.7.0, status=bounced (host
gmail-smtp-in.l.google.com[66.102.1.27] said: 552-5.7.0 This
message...  - gsmtp (in reply to end of DATA command))