[pfx] Looking for a neat way to determine the time a mail sits in active queue

[Tobi via Postfix-users]

Hi list

maybe someone has a good idea :-)

I'm looking for a way to reliably determine how long a message sits in
active queue. Currently I use postqueue -j and pipe it to jq, get only
hits from queue_id==active and then get arrival time, sort it by
arrival time, take the oldest and calculate the difference to current
time

> if [ $(sudo postqueue -j | jq 'select(.queue_name=="active")' | wc -
l) -gt 0 ] ; then echo $(( $(date +'%s') - $(sudo postqueue -j | jq
'select(.queue_name=="active") | .arrival_time' | sort | head -n1) )) ;
else echo 0 ; fi

this works well for the first run of the message in active queue but
for subsequent runs doing the diff to arrival_time is a bit biased :-)
As it's not the time in active queue anymore but the time since
arrival.

Any good idea how the get the time of when postfix took the message
into active queue? Beside parsing the whole mail.log as this takes too
long (it's a zabbix check and our zabbix waits at most 3s for a check
to return)

Or would it be possible in future postfix releases to teach the
postqueue command to return the "last time taken into active queue" for
each message in active?

Kind regards and have a good one

tobi
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Enforce TLS in smtp client sender based?

[Tobi via Postfix-users]

Hi Victor

thanks a lot for the hint to the right direction. Tried first with
sender_dependent_relayhost_maps but this one does not like the
transport name without nexthop. But
sender_dependent_default_transport_maps accepts smtps: without nexthop
:-)

Tested it on our testbox and it behaves like we want it :-)

Have a nice weekend

tobi
On Fri, 2024-04-26 at 01:46 -0400, Viktor Dukhovni via Postfix-users
wrote:
> On Fri, Apr 26, 2024 at 07:21:24AM +0200, Tobi via Postfix-users
> wrote:
> 
> > Or would it be possible to use a sender_dependent_relayhost_maps
> > and
> > define just the transport ex smtps: (without nexthop) in there so
> > postfix would use that transport (to be defined in master.cf) and
> > the
> > normal MX of recipient domain? 
> 
> See sender_dependent_default_transport_maps, which is the more
> fully-featured analogue of sender_dependent_relayhost_maps,
> which is therefore no longer needed.
> 

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Enforce TLS in smtp client sender based?

[Tobi via Postfix-users]

Hi

I wonder if it is possible in postfix client to enforce usage of TLS
based on sender. Just like in smtp_tls_policy_maps but based on sender
of the message and not on rcpt or nexthop. The only way I can see so
far is to setup another postfix instance with smtp_tls_security_level =
encrypt and use a sender dependent relayhost map on the sending system
to forward the messages from the sender in question to that new postfix
instance. Or would it be possible to use a
sender_dependent_relayhost_maps and define just the transport ex smtps:
(without nexthop) in there so postfix would use that transport (to be
defined in master.cf) and the normal MX of recipient domain? 

Have a good one

tobi
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Logging of SMTP smuggling mitigation

[Tobi via Postfix-users]

Hello

we use the "new" feature for the mitigation of the SMTP smuggling via

> smtpd_forbid_bare_newline = yes

in main.cf and wanted to ask if it would be possible to log more
information upon such a reject

> bare  received after DATA (0 bytes) from mail-
m121165.qiye.163.com[115.236.121.165]

Would it be possible to log at least the queue-id as well? Also sender
and/or recipient would be nice ;-) Or is it for security that no more
information is logged?

Have a good one

tobi
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Is it possible to add a dynamic value to a heder by header_checks?

[Tobi via Postfix-users]

thinking about your remark I came up that my idea is not well thought 
anyway :-) header_checks are after pre-queue filter and we already have 
a milter app running pre-queue. So a timestamp from the milter app would 
be before the header from postfix, which is more what I look for. We 
will add the header via the milter app then :-)


Cheers

tobi

On 23/03/2023 13:27, Matus UHLAR - fantomas via Postfix-users wrote:

Dnia 23.03.2023 o godz. 12:48:36 Tobi via Postfix-users pisze:

I wonder if the following is possible: can postfix add a header with
a dynamic value? My goal would be to add a header with the current
unix timestamp on the edge system and then check that header against
current time on last system in the delivery chain.


On 23.03.23 13:02, Jaroslaw Rafa via Postfix-users wrote:
Aren't the "Received:" headers already containing the timestamps you 
want?


in standard rfc822/5322 format, so it shouldn't be hard to parse.

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Is it possible to add a dynamic value to a heder by header_checks?

[Tobi via Postfix-users]

Hi there

I wonder if the following is possible: can postfix add a header with a 
dynamic value? My goal would be to add a header with the current unix 
timestamp on the edge system and then check that header against current 
time on last system in the delivery chain.


Have a good one

tobi

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

Re: SMTP Relay

[tobi]

> relayhost = [mx.krowverse.services]

If I got your first post right you only have nat rules for port 465 and 587 but 
the setting above implies usage of port 25. Ever tried to add :587 to your 
postfix relayhost setting?

Am 7. August 2021 11:51:33 UTC schrieb masstransitk...@365stops.org:
>When I replied, I did not notice that Thunderbird had rewritten the header.
>
>At the moment, I need to know what in this configuration could be
>causing the mail to bounce back to me. At the moment, only local mail is
>delivered.
>
>I simply need the mail to exit my server after it is sent without being
>refused. All relevant ports are open on the endpoint I want to send to.
>
>I think I am trying to configure a satellite site but I did not specify
>that during installation.
>
>On 8/6/21 7:23 PM, Viktor Dukhovni wrote:
>> On Fri, Aug 06, 2021 at 10:59:00PM +, masstransitk...@365stops.org wrote:
>>
>>> On 8/6/21 1:00 AM, Viktor Dukhovni wrote:
 On Fri, Aug 06, 2021 at 03:05:03AM +, masstransitk...@365stops.org 
 wrote:

> I followed your advice and now the traffic is hitting my gateway as it
> should. The problem is, now it's getting refused.
>
> Firewall rules specify input interface in DNAT rules now. So instead of
> simply forwarding ports 587 and 465, it is also requiring that the
> public interface is the originating one. Let's call it "enp1s0".
>
> I eagerly await your feedback.

 I eagerly await the relevant log entries (and "postconf -nf" + "postconf 
 -Mf"
 outputs) posted to the list.
>>>
>>> Here are the results for postconf -nf:
>>
>> And what question did you want to ask in relation to this configuration,
>> and where are the relevant logs?  Post your reply to the postfix-users
>> *list*, not to my personal email address.
>>
>>> ###BEGIN OUTPUT###
>>> alias_database = hash:/etc/aliases
>>> alias_maps = hash:/etc/aliases
>>> command_directory = /usr/sbin
>>> compatibility_level = 2
>>> daemon_directory = /usr/lib/postfix/sbin
>>> data_directory = /var/lib/postfix
>>> debug_peer_list = 127.0.0.1
>>> debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
>>>   $daemon_directory/$process_name $process_id & sleep 5
>>> home_mailbox = Maildir/
>>> inet_interfaces = all
>>> inet_protocols = ipv4
>>> local_recipient_maps = unix:passwd.byname $alias_maps
>>> mail_owner = postfix
>>> mailbox_size_limit = 18253611008
>>> mailq_path = /usr/bin/mailq
>>> message_size_limit = 10485760
>>> mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
>>> mydomain = krowverse.services
>>> myhostname = mx.krowverse.services
>>> mynetworks = 127.0.0.0/8 172.16.101.0/27
>>> myorigin = $mydomain
>>> newaliases_path = /usr/bin/newaliases
>>> proxy_interfaces = 172.16.101.4
>>> relay_domains =
>>> relayhost = [mx.krowverse.services]
>>> sendmail_path = /usr/sbin/postfix
>>> setgid_group = postdrop
>>> smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
>>> smtp_tcp_port = submission
>>> smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
>>> smtpd_banner = $myhostname ESMTP
>>> smtpd_helo_required = yes
>>> smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname
>>> smtpd_recipient_restrictions = permit_mynetworks, permit_auth_destination,
>>>   permit_sasl_authenticated, reject_rbl_client cbl.abuseat.org,
>>>   reject_rbl_client bl.spamcop.net, reject_rbl_client sbl.spamhaus.org,
>>>   reject_rbl_client dnsbl-1.uceprotect.net, reject_rbl_client
>>>   zen.spamhaus.org, permit
>>> smtpd_sasl_auth_enable = yes
>>> smtpd_sasl_local_domain = $myhostname
>>> smtpd_sasl_path = private/auth
>>> smtpd_sasl_security_options = noanonymous
>>> smtpd_sasl_type = dovecot
>>> smtpd_tls_cert_file =
>>>   
>>> /import/RAPTORGAZE/LetsEncrypt/live/mx.krowverse.services/fullchain.pem
>>> smtpd_tls_key_file =
>>>   /import/RAPTORGAZE/LetsEncrypt/live/mx.krowverse.services/privkey.pem
>>> smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
>>> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
>>> smtpd_use_tls = yes
>>> unknown_local_recipient_reject_code = 550
>>>
>>> ###END OUTPUT###
>>>
>>> And here is the output of postconf -Mf:
>>>
>>> ###BEGIN OUTPUT###
>>> smtp   inet  n   -   y   -   -   smtpd
>>> submission inet  n   -   n   -   -   smtpd -v
>>>   -o syslog_name=postfix/submission
>>>   -o smtpd_sasl_auth_enable=yes
>>>   -o smtpd_tls_auth_only=yes
>>> smtps  inet  n   -   y   -   -   smtpd
>>>   -o syslog_name=postfix/smtps
>>>   -o smtpd_tls_wrappermode=yes
>>>   -o
>>> smtpd_relay_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination,reject_non_fqdn_sender,reject_non_fqdn_recipient,reject_unknown_recipient_domain
>>>   -o milter_macro_daemon_name=ORIGINATING
>>> pickup unix  n   -   y   60  1   pickup
>>> cleanupunix  n   -   y   

Re: reject_sender_login_mismatch

[tobi]

you could add a sender access map in your relay config which rejects those 
domains. Place it before your sender login  maps

Am 31. Juli 2021 06:06:17 UTC schrieb Simon Wilson :
>A quick query on smtpd_sender_login_maps format.
>
>I have this working well on port 587 to ensure that specified  
>SASL-authenticated users only can send emails from their owned email  
>addresses.
>
>So I have in a file 'controlled_envelope_senders' this, as an example:
>
>  @simonandkate.net   simon
>
>...and I have reject_sender_login_mismatch set in master.cf for port  
>587. Then in main.cf:
>
>  smtpd_sender_login_maps = hash:/etc/postfix/controlled_envelope_senders
>
>Perfect...
>
>I am disabling a couple of email addresses as a first step along the  
>way to deleting some accounts and domain names. I've disabled inbound  
>emails fine, and now need to prevent the users sending, while still  
>being able to access webmail for a few days.
>
>
>The question:
>
>Within the smtpd_sender_login_maps file, is an empty RH side valid so  
>*NO* SASL users can send from that (domain) address? Or does it need  
>to have *something* on the RHS?
>
>
>Thanks
>Simon
>
>
>-- 
>Simon Wilson
>M: 0400 12 11 16

Re: Best current practice to analyze brute force login attempts?

[tobi]

If dovecot is in play as auth backend then weakforced could be a viable option. 
Quite a powerful tool tailored to fight/detect brute force attacks: 
https://github.com/PowerDNS/weakforced

Am 30. Juli 2021 15:12:40 UTC schrieb post...@ptld.com:
>> Unfortunately, the required data, i.e. client IP address and username
>> are distributed in different log files. The IP address is written to
>> postfix's log, while the username is in saslauthd's log in case of
>> failure, with the time stamp as the only link between both.
>> 
>> Is there some best current practice or recommended log config to 
>> analyze
>> persistent login attempts?
>
>
>This is kind of a dovecot thing more than a postfix thing. One option 
>is...
>
>
>In dovecot core conf:
>   auth_verbose = yes
>   auth_verbose_passwords=sha1
>
>
>If using rsyslog for logging you can separate logins to their own log 
>for easier scanning:
>   if $programname == "dovecot" and $msg startswith "auth-worker" then {
> -/var/log/mail/dovecot_auth
> stop
>   }
>
>
>Would give you logs with the user, IP and the hashed password tried to 
>see if its repeating same password (dumb client) vs brute force:
>
>Jul 30 11:05:11 mx dovecot[9737]: auth-worker(12362): conn 
>unix:auth-worker (pid=12361,uid=97): auth-worker<1>: 
>sql(t...@example.com,100.101.102.103,): Password 
>mismatch (given password: )

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[Tobi]

Josh,

On 7/29/21 9:13 AM, Josh Good wrote:
> Well, it's not exactly clear, in the Rhenus notification, whether they
> are just disabling TLS 1.0, or that plus also disabling plain text SMTP.
>
> Viktor thinks it's just the first case. But we should not underestimate
> the push that a checklist-based security audit can exert on an
> overburdened IT Dept.


I bet a beer that they're going the second path: enforce TLS1.2 +
disabling plain text SMTP. Although I think this is not a good idea imho
the first path (enforcing TLS1.2 but still keeping plain) is just plain
stupid ;-) They would not gain anything by doing so, because imho a
TLS1.0 connection is better than a fallback on plain. Do not get me
wrong I think it's a good idea to push towards using only strong TLS
versions/ciphers but the implementation may cause far more problems than
expected.

Just take the case when they loose a huge customer order because
customer still operates an Exchange 2003 server, which by best can talk
TLS 1.0. Then Management will soon show up in IT department and highly
probably ignore the fact that it was them pushing this policy in first
place ;-)

Cheers


tobi




OpenPGP_signature
Description: OpenPGP digital signature

Re: Has rfc2487 been obsoleted and mandatory TLS in smtpd is now kosher?

[Tobi]

Hi


imho this is a single case. Enforcing TLS on a public faced smtp port
makes no sense to me. Except if you want to reject quite a bunch of mail :-)
Sure TLS encrypted connections are preferable but to enforce it on an
incoming smtp server is sportive. They would better leave smtpd
encryption on may and deploy a proper DANE setup instead.

Sure it's their servers so their rules applies. Everyone is allowed to
shot own foot ;-)

Cheers

tobi

On 7/28/21 4:39 PM, Josh Good wrote:
> Hello everybody.
>
> I've been made aware of this communication recently received at some
> site whose email is managed on-premises (i.e., not outsourced to any
> big mailbox provider in the "cloud"):
>
>> From: Rhenus Logistics  
>> Sent: 30 June 2021 17:05
>> To: [omitted]
>> Subject: Email con TLS inferior a 1.2 / Email with TLS less than 1.2
>>  
>> Good Afternoon,
>> We inform you that due to Rhenus security policies, as of 08/01/2021
>> receiving of emails that do not comply with version 1.2 of the TLS 
>> protocol will be restricted.
>> All emails sent in particular to the domain @es.rhenus.com and in 
>> general to any Rhenus domain @*.rhenus.com must be sent with the TLS 
>> 1.2 protocol or higher.
>> Any mail received without fulfilling this condition will be rejected 
>> by our server.
>> Please forward this message to your IT department for consideration 
>> and action.
>> If you have any questions, please head over your Rhenus contact
>>  
>> IT //SERVICES
>
> The above could mean that starting 08/01/2021 their TLS support will
> only support TLS 1.2 (and not any earlier TLS version) with their
> inbound SMTP servers remaining configured in "opportunistic TLS" mode
> --- or it could be read as if they will enable "smtpd_enforce_tls = yes"
> (or "smtpd_tls_security_level = encrypt") in their inbound SMTP servers
> (I don't know if they are using Postfix, but you get what I mean).
>
> If the case is the second one, is that a current trend? Has rfc2487
> been obsoleted and mandatory TLS is now considered "industry standard"
> in publicly-referenced SMTP server?
>
> I've tried to contact Rhenus IT Services to inquire about this, but my
> phone calls haven't gone through. So I thought I may as well ask this
> list if this a single case or the "new normal"...
>
> Regards,
>



OpenPGP_signature
Description: OpenPGP digital signature

Re: Restrict Senders for some recipient addresses

[Tobi]

something like this?
http://www.postfix.org/RESTRICTION_CLASS_README.html#internal

On 4/26/21 10:11 AM, George Papas wrote:
> Hi  list,
>
>
> what the title says actually,   I have an alias  for all current users
> of an SMTP server but
>
> I want to restrict sending to this alias address to some specific
> senders only (the actual
>
> users of the domain plus a small group of external senders ).
>
> What I'm I looking for in the documentation ? Sender/Recipient
> Restrictions
>
> or something different?
>
>
> Thanks in advance
>
> George Papas

Re: timed server greeting

[Tobi]

On 4/23/21 3:33 PM, natan wrote:
> for test I send (this same method) from old server (debian8 postfix
> 2.11.x) and works ok


does the old server have another ip address than the new one? Smells to
me that your new server ip maybe blocked at destination


--

Cheers


tobi

Re: Specific DNS server

[Tobi]

Would it be an option to configure a policy for your DNS server to
**not** send queries from postfix host(s) through the add filter?

Cheers

tobi

On 4/22/21 12:20 PM, Simon Wilson wrote:
> Is there a way to make Postfix/postscreen use a specific DNS server?
>
> Reason for the question:
> My network has an internal (non-ISP forwarding) DNS server for both
> internal and external resolution, and that is default nameserver
> across the network including for the mail server. That DNS server
> includes a broad set of applied RPZ restrictions (which remove the
> vast majority of ads and trackers - a very popular addition). The RPZ
> zone has though on very rare occasions resulted in Postfix getting
> SERVFAIL and rejecting domains (reject_unknown_sender_domain), which
> could be classed as false positives - not for critical emails, but
> occasionally for retail mail-outs etc.
>
> I provide a fully "clean and complete" DNS for spamassassin DNSBL
> lookups by running a recursive caching nameserver on-localhost (SA has
> an defined option to specify a DNS server). As noted above the mail
> server as a whole does not use this - it uses the network-wide local
> nameserver, ensuring that it can resolve local As CNAMEs etc as needed.
>
> Note: I realise one option is that I could probably add local domain
> resolution to the localhost nameserver and use it as the default for
> the mail server... but my first question is whether postfix has or
> could have ability to have a specific nameserver (as Spamassassin
> does), or if this would be a Bad Idea (TM) for reasons unknown to me.
>
> Simon.
>

Re: Possible to "import" a file into postfix queue?

[Tobi]

Wietse,

On 2/11/21 1:49 PM, Wietse Venema wrote:
> sendmail -f sender recipient... < file

We could debug and solve the issue just wonder for next time: does
delivery via sendmail command not change the msg by one bit? Especially
no new or changed headers. Because we found our problem to be the exact
position of a \r\n If this is placed one bit more left or right the
error did not occur. That's why we could not reproduce it via swaks
--data @/file as this adds at least one header which then pushed the
problematic \r\n to an UN-problematic position.
Anyway the error was in our external content filter and is fixed now.
Was an error that had been undetected in our content-filter for more
than 10 years :-)


Cheers


tobi

Possible to "import" a file into postfix queue?

[Tobi]

Hi all

we have a very strange issue with our postfix and its external
content-filter. To debug this we wanted to take an affected
message (postcat -bhq QID >/tmp/file) and use swaks with --data command
to send it again to postfix and through the content filter. But the
swaks message
does NOT trigger our issue and therefore is properly processed.
So we cannot reproduce it over swaks but see in postfix logs that every
try from postfix to deliver the message to the filter gets 450 from
filter. This 450 is intentional as we have some very rare cornercases
where mail gets broken somewhere in the content filter, so to avoid this
cases our filter returns 450 to postfix for such mail.

So we thought it could be possible to somehow "import" such an affected
message directly into postfix queue to leave out swaks which may fix
something in the message. Is there such a postfix command to "import" a
file as message directly into postfix queues?


Thanks for any idea as we really need to be able to reproduce it or else
debugging will be very hard :-)
Cheers


tobi

Re: Segfaults libpcre in cleanup

[Tobi]

Wietse,

Am 14.05.20 um 16:04 schrieb Wietse Venema:
> So your best bet is to rewrite your patterns.

that's what we did now and it saves a lot of cpu cycles :-) As our
pattern matched something at beginning and at the end of the string (all
stuff between matched via patterns with * repetition) the easiest thing
was to add a condition to the map file for the first part and in the if
match the end of the string. That way we could get rid of a lot of the *
between start and end :-)

> if /^Content-(Disposition|Type).*name\s*=\s*/i
> /(\.|=2E)(dmg|cab)\s*(;|$)/   REJECT extension of .$2 is not allowed
> endif

the pattern above now runs without any changes to stack size :-)

--
Cheers

tobi

Re: Segfaults libpcre in cleanup

[Tobi]

Wietse, Viktor

It seems that this is the problematic part of the pcre pattern

>
/^Content-(Disposition|Type).*name\s*=\s*("(?:[^"]|\\")*|[^();:,\/<>\@\"?=<>\[\]\
]*)

I tested by replacing star by star with explicit limits and found that
limits avoid the segfault. I replaced the last two stars with limits up
to 1 chars

>
/^Content-(Disposition|Type).*name\s*=\s*("(?:[^"]|\\"){0,1}|[^();:,\/<>\@\"?=<>\[\]\
]{0,1})

no segfault but I think the whole header has not been processed as its
longer than 10'000 chars. Tried with higher values than 1 but then
postmap issues a warning that the number is too big.

> postmap: warning: pcre map /etc/postfix/mime_header_checks.pcre, line
21: error in regex at offset 63: number too big in {} quantifier

After solving the "too big number" issue postmap said that the pcre
pattern is too big :-)

> postmap: warning: pcre map /etc/postfix/mime_header_checks.pcre, line
21: error in regex at offset 352: regular expression is too large


So the problem is definitely our pattern in combination with a VERY big
mime part header. We're on introducing limits where we can in our patterns.
Anyway I think that this should not end in such an ugly error where
postfix cleanup goes south because of such header/pattern combination.


--
Cheers

tobi

Am 14.05.20 um 09:13 schrieb Viktor Dukhovni:
> On Thu, May 14, 2020 at 08:53:42AM +0200, Tobi wrote:
> 
>> using your suggestion with valgrind I found that the main-stacksize
>> seems to be the problem. By using --main-stacksize with different values
>> I found that the last working value is 59449345, changing to ...344 let
>> postmap segfault:
> 
> But whatever the stacksize, the PCRE library must not segfault.  We need
> to be sure that it returns an error to the caller, rather than blows up.
> 
>>> ==7988== Stack overflow in thread #1: can't grow stack to 0x1ffb74f000
>>
>> We will try allowing more stacksize by /etc/security/limits.conf to
>> postfix and re-design our pcre pattern(s) to avoid (where possible) the
>> usage of .* without any limits :-)
> 
> Keeping your (ir)regular expressions simpler is always a good idea.
> Especially avoid costly use of multiple '.*' patterns in the same
> expression.  Not a good idea:
> 
> /a.*b.*c.*d.*...z/
> 
> Perhaps there's something we can do with default resource limits.
> From the pcre2pattern(2) manpage:
>  
>Setting match resource limits
> 
>The pcre2_match() function contains a counter that is incremented
>every time it goes round its main loop. The caller of
>pcre2_match() can set a limit on this counter, which  therefore
>limits  the  amount  of  computing resource used for a match. The
>maximum depth of nested backtracking can also be limited; this
>indirectly restricts the amount of heap memory that is used, but
>there is also an explicit memory limit that can be set.
> 
>These facilities are provided to catch runaway matches that are
>provoked by patterns with huge matching trees. A common example
>is a pattern with nested unlimited repeats applied to a long
>string that does not match. When one of these limits is reached,
>pcre2_match() gives an error return. The limits can also be set
>by items at the start of the pattern of the form
> 
>  (*LIMIT_HEAP=d)
>  (*LIMIT_MATCH=d)
>  (*LIMIT_DEPTH=d)
> 
>where  d is any number of decimal digits. However, the value of
>the setting must be less than the value set (or defaulted) by the
>caller of pcre2_match() for it to have any effect. In other
>words, the pattern writer can lower the limits set by the
>programmer, but not raise them. If there is more than one setting
>of one of these limits, the lower value is used.  The heap limit
>is specified in kibibytes (units of 1024 bytes).
> 
>Prior to release 10.30, LIMIT_DEPTH was called LIMIT_RECURSION.
>This name is still recognized for backwards compatibility.
> 
>The  heap limit applies only when the pcre2_match() or
>pcre2_dfa_match() interpreters are used for matching. It does not
>apply to JIT. The match limit is used (but in a different way)
>when JIT is being used, or when pcre2_dfa_match() is called, to
>limit computing resource usage by those matching functions. The
>depth limit is ignored by JIT but is relevant  for  DFA matching,
>which  uses  function  recursion for recursions within the
>pattern and for lookaround assertions and atomic groups. In this
>case, the depth limit controls the depth of such recursion.
> 

Re: Segfaults libpcre in cleanup

[Tobi]

Hi Wietse

using your suggestion with valgrind I found that the main-stacksize
seems to be the problem. By using --main-stacksize with different values
I found that the last working value is 59449345, changing to ...344 let
postmap segfault:

> valgrind -s --main-stacksize=59449344 --tool=memcheck postmap -h -q -
> pcre:/etc/postfix/mime_header_checks.pcre 
> ==7988== Stack overflow in thread #1: can't grow stack to 0x1ffb74f000

We will try allowing more stacksize by /etc/security/limits.conf to
postfix and re-design our pcre pattern(s) to avoid (where possible) the
usage of .* without any limits :-)

Thanks a lot for your appreciated help

--
Cheers

tobi

Am 13.05.20 um 16:05 schrieb Wietse Venema:
> Tobi:
>> Hi
>>
>> as usual: thanks to Wietse :-)
>>
>> Adding the info rule to the pcre maps solved more than expected. After
>> adding the info rule postfix cleanup did not segfault anymore and the
>> mail could be accepted --> we have the source now.
>> From what I see that is a massively oversized mime part header. I
>> counted about 500 times the filename= in the mime part header as well as
>> name= contains hundreds of values. All nicely utf8
>>
>> Like
>>
>>> Content-Type: image/png; name="=?UTF-
>>> 8?B?xILChMOCwoLEgsKCw4LChMOEwoLDgsKCxILCgsOCwoLEgsKEw4LCgsSC?=
>>> =?UTF-8?B?woLDgsKCw4TCgsOCwoLEgsKCw4LChMOEwoLDgsKExILCgsOCwoLDhMKC?=
>>> =?UTF-8?B?w4LCgsSCwoLDgsKCxILChMOCwoLEgsKCw4LCgsOEwoLDgsKCxILCgsOC?=
>>
>> and
>>
>>> Content-Disposition: inline; filename*0*=UTF-8''%C4%82%C2%84%C3%82%C2
>>> %82%C4%82%C2%82%C3%82%C2%84%C3%84;
>>> filename*1*=%C2%82%C3%82%C2%82%C4%82%C2%82%C3%82%C2%82%C4%82%C2%84
>>> %C3%82;
>>
>> First of all any idea why cleanup did not segfault with the info rule in
>> place?
> 
> When something accesses wrong memory, what happens next is totally
> dependent on memory layout, execution history, and so on. For example
> the program may not crash (but still produce incorrect behavior).
> 
>> 2nd: could such mime headers be the reason for a pcre pattern to let
>> libpcre segfault?
> 
> Sure, there are sometimes bugfixes for libpcre.
> 
> You can test such things.
> 
> $ postmap -h -q - pcre:pattern-file < data-file
> 
> $ valgrind --tool=memcheck postmap -h -q - pcre:pattern-file < data-file
> 
> where data-file contains the complete crashing message header and
> pattern-file contains the crashing pattern.
> 
> Note that Postfix logs only a limited portion of very large lines.
> You may need to "postcat" the original message if it is available.
> 
> valgrind will report incorrect memory access even when a program
> does not crash. And yes, I do sometimes run Postfix daemons under
> valgrind to find non-crashing bugs.
> 
> I'd be interested if you can reproduce the bug.
> 
>   Wietse
> 

Re: Segfaults libpcre in cleanup

[Tobi]

Hi

as usual: thanks to Wietse :-)

Adding the info rule to the pcre maps solved more than expected. After
adding the info rule postfix cleanup did not segfault anymore and the
mail could be accepted --> we have the source now.
From what I see that is a massively oversized mime part header. I
counted about 500 times the filename= in the mime part header as well as
name= contains hundreds of values. All nicely utf8

Like

> Content-Type: image/png; name="=?UTF-
> 8?B?xILChMOCwoLEgsKCw4LChMOEwoLDgsKCxILCgsOCwoLEgsKEw4LCgsSC?=
> =?UTF-8?B?woLDgsKCw4TCgsOCwoLEgsKCw4LChMOEwoLDgsKExILCgsOCwoLDhMKC?=
> =?UTF-8?B?w4LCgsSCwoLDgsKCxILChMOCwoLEgsKCw4LCgsOEwoLDgsKCxILCgsOC?=

and

> Content-Disposition: inline; filename*0*=UTF-8''%C4%82%C2%84%C3%82%C2
> %82%C4%82%C2%82%C3%82%C2%84%C3%84;
> filename*1*=%C2%82%C3%82%C2%82%C4%82%C2%82%C3%82%C2%82%C4%82%C2%84
> %C3%82;

First of all any idea why cleanup did not segfault with the info rule in
place?
2nd: could such mime headers be the reason for a pcre pattern to let
libpcre segfault?

--

Cheers

tobi

Am 12.05.20 um 15:20 schrieb Wietse Venema:
> Tobi:
>> Hi list
>>
>> we have the very rare problem that cleanup "triggers" segfaults in
>> libpcre. We're currently running postfix 3.5.1 but had the issue before
>> updating (with postfix 3.4.4) as well. OS is a Centos7 with latest updates.
>>
>>> May 12 14:36:14 XXX kernel: cleanup[23927]: segfault at 7ffc5118ef78
>>> ip 7fd07913c98a sp 7ffc5118ef70 error 6 in
>>> libpcre.so.1.2.0[7fd079129000+6]
>>
>> libpcre is of version 8.32
>>
>> Unfortunately we do not have access to the message source. But it's
>> always the same message that triggers the segfault. Every re-send try
>> from sending server ends in that error.
>> We highly assume that one of our pcre rules could be the culprit, but
>> it's hard to find out which one it is. Postfix never complains about a
>> broken pattern or something like that in logs. Also testing with postmap
>> -vv -q works without any error/warning for all our pcre maps. There is
>> no suspicious logging prior to cleanup "crash".
>>
>> Is there a way to narrow down which pcre rule may is problematic, given
>> the fact that we do not have access to message source?
> 
> Use dummy rules:
> 
> /(.+)/info before foo: $1
> /foo/ action for foo
> /(.+)/info before bar
> /bar/ action for bar
> 
>   Wietse
> 



signature.asc
Description: OpenPGP digital signature

Re: Postfix "IPv6-only" - experience/recommendation question

[Tobi]

Hi

Am 12.05.20 um 11:27 schrieb Jaroslaw Rafa:
> If
> somedomain.com sends spam, you won't automatically classify all other .com
> domains as spam. So why do it for eu.org?

because .com is a real TLD whereas eu.org is a pseudo TLD. You won't see
user@com in mail but u...@eu.org
My 5 cents: never rely on the reputation of a domain if you do not have
control over parent domain. So if others from eu.org zone sending spam
one should not wonder why the own subdomain of eu.org might be
listed/blocked/seen as spam.

--
Cheers

tobi

Segfaults libpcre in cleanup

[Tobi]

Hi list

we have the very rare problem that cleanup "triggers" segfaults in
libpcre. We're currently running postfix 3.5.1 but had the issue before
updating (with postfix 3.4.4) as well. OS is a Centos7 with latest updates.

> May 12 14:36:14 XXX kernel: cleanup[23927]: segfault at 7ffc5118ef78
> ip 7fd07913c98a sp 7ffc5118ef70 error 6 in
> libpcre.so.1.2.0[7fd079129000+6]

libpcre is of version 8.32

Unfortunately we do not have access to the message source. But it's
always the same message that triggers the segfault. Every re-send try
from sending server ends in that error.
We highly assume that one of our pcre rules could be the culprit, but
it's hard to find out which one it is. Postfix never complains about a
broken pattern or something like that in logs. Also testing with postmap
-vv -q works without any error/warning for all our pcre maps. There is
no suspicious logging prior to cleanup "crash".

Is there a way to narrow down which pcre rule may is problematic, given
the fact that we do not have access to message source?


--
Thanks and have a good one

tobi

Re: Graphing

[Tobi]

Hello

mailgraph [1] is RRD based and does bounces by default. It does a very
good job on my own servers and the servers I administer at work.

If you want to have all-possible-kind-one-can-think-of graphs, then I
can only recommend to bring your maillogs via shipper (like logstash or
filebeat) into an elasticsearch storage.
Then only the sky (or the datastock) is the limit for graphs :-) You can
even enrich your elastic data automatically with geoip and ASN info
related to external IP addresses.
It's a step learning curve to go but an ELK cluster for all mail
relevant logs is worth the effort :-)


[1] https://mailgraph.schweikert.ch/


Cheers

--

tobi

Am 24.01.20 um 09:47 schrieb Cédric Gallo:
> Hello,
> 
> Munin server and munin nodes with standards and home-made plugins (for
> bounces).
> http://munin-monitoring.org/
> 
> Bye
> 
> Le 24/01/2020 à 07:09, Ed a écrit :
>> Hello,
>>
>> What do people use for simple throughput/relay/bounce graphing?
>>
>> RRD based would be nice.
>>

Re: Possible to enforce 4XX error upon dns lookups which result in NXDomain?

[Tobi]

Hi Wietse

thanks a lot for your hint :-) Deployed and first tests show it works as
it should: changing 5xx to 4xx in case of NX domain for nexthop.

Cheers

tobi

Am 15.10.19 um 21:58 schrieb Wietse Venema:
> Wietse Venema:
>> Wietse Venema:
>>> Tobi:
>>>> I wonder if the following idea is somehow "do-able" in postfix. We have
>>>> a fallback postfix instance which gets all mails that our scanners could
>>>> not send to our customers target server. Now the fallback tries to
>>>> submit those msg to our customers. Sometimes our customers do not know
>>>> how to manage dns and delete an important record (like the a-rec for the
>>>> target server). We do not manage their zones, that's done by themselves.
>>>>
>>>> Now we thought that it would be very nice if we could "tell" our
>>>> fallback instance that in case of NXDomain in DNS lookup of a target
>>>> server to return a DEFER (4xx) instead of a REJECT (5xx).
>>>> I found soft_bounce parameter in the docs but that seems too wide, as we
>>>> would only soft bounce in case of NXDomain results of target servers and
>>>> not for any other reason. Is it possible to use smtp_dns_reply_filter to
>>>> filter for NXDomain results and return a DEFER action?
>>
>> Of course Postfix can, it just isn't called smtp_dns_reply_filter
>>
>> Instead, use smtp_delivery_status_filter.
>>
>> The filter is invoked with a string of the form :
>>
>> enhanced-status-code SPACE explanatory-text
>>
>> For example:
>>
>> 5.4.4 Host or domain name not found. Name service error for...
>>
>> So the following could do the trick for your fallback relay host:
>>
>> /etc/postfix/main.cf:
>>  smtp_delivery_status_filter = pcre:/etc/postfix/fallback_status_filter
> 
> Corrected text: The '5' needs to be outside the ().
> 
> /etc/postfix/fallback_status_filter:
> /^5(\S+\s+Host or domain name not found.+)/ 4$1
> 
> This changes the hard error into a soft one, and is more selective
> than setting soft_bounce=yes.
> 
>   Wietse
>>

Re: Postfix is not open relay but send spam

[Tobi]

Hi

shot me if I'm wrong ;-) but I think your smtp service is an open
relay?! I don't see reject_unauth_destination after your
permit_mynetwork and permit_sasl_authenticated. Thats means (at least
afaik) that any mail will be accepted as long as it does not hit one of
your reject_* statements.
So for your submission/smtps service I'd recommend to add a final reject
to the restrictions and for the smtpd_recipient_restrictions I'd
recommend to add reject_unauth_destination directly after
permit_sasl_authenticated. Imho it would be preferable to disable AUTH
on port 25 anyway (but that might start "religious" discussions here ;-))

I wonder a bit that your postfix allows processing mail at all because
the man says:

> IMPORTANT: Either the smtpd_relay_restrictions or the
> smtpd_recipient_restrictions parameter must specify at least one of
> the following restrictions. Otherwise Postfix will refuse to receive
> mail:
>
>reject, reject_unauth_destination
>
>defer, defer_if_permit, defer_unauth_destination

Another thing I wonder about is your output from mxtoolbox test. It
shows your server rejects with a 4xx temporary reject. That should be a
5xx. I think postfix complains about something in its logs.

Cheers

--

tobi

Am 15.10.19 um 09:27 schrieb Julien Michaux:
> Hi everyone,
> 
> I have a problem with postfix.
> 
> I use OBM as a mail server (postfix + cyrus + ldap, etc...). My postfix is
> not openrelay :
> 
> 220 xx ESMTP Postfix (Debian/GNU) [706 ms]
> EHLO keeper-us-east-1c.mxtoolbox.com
> 250-xx
> 250-PIPELINING
> 250-SIZE 52428800
> 250-VRFY
> 250-ETRN
> 250-STARTTLS
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 DSN [702 ms]
> MAIL FROM: 
> 250 2.1.0 Ok [700 ms]
> RCPT TO: 
> 454 4.7.1  : Relay
> access denied [719 ms]
> 
> LookupServer 3927ms
> 
> Time to time, my server is attack and he sends spam. All spam are from a
> specific address "cy...@mydomain.com" .
> I tried many things but nothing works. I have to stop postfix for some
> hours and attack ends until next time.
> 
> Can you provide me advice or corrections to my config to ensure this attack
> can't success please ?
> 
> Here is master.cf :
> smtp  inet  n   -   n   -   -   smtpd -v
>   -o receive_override_options=no_address_mappings
>   -o content_filter=smtp-amavis:127.0.0.1:10024
> submission inet n   -   n   -   -   smtpd
>   -o syslog_name=postfix/submission
>   -o smtpd_tls_security_level=encrypt
>   -o smtpd_sasl_auth_enable=yes
>   -o smtpd_reject_unlisted_recipient=no
>   -o smtpd_client_restrictions=$mua_client_restrictions
>   -o smtpd_helo_restrictions=$mua_helo_restrictions
>   -o smtpd_sender_restrictions=$mua_sender_restrictions
>   -o smtpd_recipient_restrictions=$mua_recipient_restrictions
>   -o milter_macro_daemon_name=ORIGINATING
>   -o receive_override_options=no_address_mappings
>   -o content_filter=smtp-amavis:127.0.0.1:10024
> smtps inet  n   -   n   -   -   smtpd
>   -o syslog_name=postfix/smtps
>   -o smtpd_tls_wrappermode=yes
>   -o smtpd_sasl_auth_enable=yes
>   -o smtpd_reject_unlisted_recipient=no
>   -o smtpd_client_restrictions=$mua_client_restrictions
>   -o smtpd_helo_restrictions=$mua_helo_restrictions
>   -o smtpd_sender_restrictions=$mua_sender_restrictions
>   -o smtpd_recipient_restrictions=$mua_recipient_restrictions
>   -o milter_macro_daemon_name=ORIGINATING
>   -o receive_override_options=no_address_mappings
>   -o content_filter=smtp-amavis:127.0.0.1:10024
> pickupunix  n   -   n   60  1   pickup
> cleanup   unix  n   -   n   -   0   cleanup
> qmgr  unix  n   -   n   300 1   qmgr
> tlsmgrunix  -   -   n   1000?   1   tlsmgr
> rewrite   unix  -   -   n   -   -   trivial-rewrite
> bounceunix  -   -   n   -   0   bounce
> defer unix  -   -   n   -   0   bounce
> trace unix  -   -   n   -   0   bounce
> verifyunix  -   -   n   -   1   verify
> flush unix  n   -   n   1000?   0   flush
> proxymap  unix  -   -   n   -   -   proxymap
> proxywrite unix -   -   n   -   1   proxymap
> smtp  unix  -   -   n   -   -   smtp
> relay unix  -   -   n   -   -   smtp
> showq unix  n   -   n   -   -   showq
> error unix  -   -   n   -   -   error
> retry unix  -   -   n   -   -   error
> discard   unix  -   -   n   -   -   discard
> loc

Possible to enforce 4XX error upon dns lookups which result in NXDomain?

[Tobi]

Hi list

I wonder if the following idea is somehow "do-able" in postfix. We have
a fallback postfix instance which gets all mails that our scanners could
not send to our customers target server. Now the fallback tries to
submit those msg to our customers. Sometimes our customers do not know
how to manage dns and delete an important record (like the a-rec for the
target server). We do not manage their zones, that's done by themselves.

Now we thought that it would be very nice if we could "tell" our
fallback instance that in case of NXDomain in DNS lookup of a target
server to return a DEFER (4xx) instead of a REJECT (5xx).
I found soft_bounce parameter in the docs but that seems too wide, as we
would only soft bounce in case of NXDomain results of target servers and
not for any other reason. Is it possible to use smtp_dns_reply_filter to
filter for NXDomain results and return a DEFER action?

Thanks for any idea and have a good one

--

tobi



signature.asc
Description: OpenPGP digital signature

Re: Performing rcpt_verification based on sender possible?

[Tobi]

Noel,

omg own stupidity :-)
Settings all are okay but there was a cache file for results of verify
lookups.
Forgot that I changed the rcpt test account to REJECT within the last
31days (default for address_verify_positive_expire_time)

So instead of waiting for max 31days for the "postfix self-healing" to
kick in ;-), I removed the file and postfix reload and it works

Thanks a lot for your help and have a good one

tobi

Am 14.11.18 um 16:29 schrieb Noel Jones:
> On 11/14/2018 2:50 AM, Tobi wrote:
> 
>>
>> $ postconf -d|grep parent_domain_matches
>> parent_domain_matches_subdomains =
>> debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,qmqpd_authorized_clients,relay_domains,smtpd_access_maps
>>
> 
> caution: "postconf -d" shows the compiled-in defaults, not current
> settings.  use "postconf" (no options) to show current settings.
> 
> 
>> Will set postfix to debug as described this evening and see if I can get
>> more information about this issue.
> 
> No, setting postfix to debug was not recommended.  The combination
> of "postconf -n" plus any overrides you've added in master.cf, and
> normal logging almost certainly provides all the information you
> need.  Debug logging will likely bury the real problem in a flood of
> unrelated information.
> 
> 
>   -- Noel Jones
> 

Re: Performing rcpt_verification based on sender possible?

[Tobi]

Noel,

first of all thanks for your patience :-)

> you must have smtpd_delay_reject=yes

is set default so YES


> and parent_domain_matches_subdomains must contain smtpd_access_maps

checked that too, looks like the defaults

$ postconf -d|grep parent_domain_matches
parent_domain_matches_subdomains =
debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,qmqpd_authorized_clients,relay_domains,smtpd_access_maps


I checked with postconf -n that the smtpd_sender_restrictions are okay
and as expected

$ postconf -n|grep smtpd_sender
smtpd_sender_restrictions = reject_unknown_sender_domain,
reject_non_fqdn_sender, check_sender_access
hash:/etc/postfix/do_callahead, .

Will set postfix to debug as described this evening and see if I can get
more information about this issue.

Thanks a lot

tobi

Am 13.11.18 um 18:22 schrieb Noel Jones:
> On 11/13/2018 10:46 AM, Tobi wrote:
>>> Postfix supports what you've described. You must have made some
>>> other mistake.
>>
>> believe me that's what I thought first :-) But the only reason this
>> would not fire is that a prior restriction already OK the mail. To test
>> I commented all client restrictions and placed my check_sender access on
>> (almost) top of sender_restrictions
>>
>> smtpd_sender_restrictions = reject_unknown_sender_domain,
>>  reject_non_fqdn_sender,
>>  check_sender_access hash:/etc/postfix/do_callahead,
>>  []
>>
>> so the restriction is well before any restriction that could ACCEPT the
>> mail.
>>
>> postmap tells me that it gets the correct value from the map
>>
>> $ postmap -q 'example.com' /etc/postfix/do_callahead
>> reject_unverified_recipient
>>
>>
>>
> 
> Two things that come to mind...
> 
> you must have smtpd_delay_reject=yes
> 
> and parent_domain_matches_subdomains must contain smtpd_access_maps
> 
>  check your "postconf -n" output to make sure it shows what you expect.
> 
> If you have more trouble, please see
> http://www.postfix.org/DEBUG_README.html#mail
> 
> 
>   -- Noel Jones
> 

Re: Performing rcpt_verification based on sender possible?

[Tobi]

> Postfix supports what you've described. You must have made some
> other mistake.

believe me that's what I thought first :-) But the only reason this
would not fire is that a prior restriction already OK the mail. To test
I commented all client restrictions and placed my check_sender access on
(almost) top of sender_restrictions

smtpd_sender_restrictions = reject_unknown_sender_domain,
 reject_non_fqdn_sender,
 check_sender_access hash:/etc/postfix/do_callahead,
 []

so the restriction is well before any restriction that could ACCEPT the
mail.

postmap tells me that it gets the correct value from the map

$ postmap -q 'example.com' /etc/postfix/do_callahead
reject_unverified_recipient



Am 13.11.18 um 17:18 schrieb Noel Jones:
> On 11/13/2018 9:43 AM, Tobi wrote:
>> Hello list
>>
>> I'm trying to achieve that a certain sender (or sender domain) must have
>> the recipients verified. Thought that it could be done with a
>> restriction class:
>>
>> #main.cf
>> smtpd_restriction_classes = DO_CALLAHEAD
>> DO_CALLAHEAD = reject_unverified_recipient
>> smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/my.map
>>
>> #my.map
>> example.com  DO_CALLAHEAD
>>
>> But if I test with example.com sender on a remote rcpt that is rejected,
>> the msg is always accepted and a bounce has to be sent back to sender.
>> Which is what I'm trying to avoid for this particular sender with rcpt
>> verification.
>>
>> Is there a way to achieve that with postfix?
>>
>> Thanks for any idea
>>
>> tobi
>>
> 
> 
> Postfix supports what you've described. You must have made some
> other mistake.
> 
> You can simplify your config by not using a restriction class, which
> isn't required for this particular function.
> 
> # my.map
> example.com  reject_unverified_recipient
> 
> 
> 
> 
>   -- Noel Jones
> 

Performing rcpt_verification based on sender possible?

[Tobi]

Hello list

I'm trying to achieve that a certain sender (or sender domain) must have
the recipients verified. Thought that it could be done with a
restriction class:

#main.cf
smtpd_restriction_classes = DO_CALLAHEAD
DO_CALLAHEAD = reject_unverified_recipient
smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/my.map

#my.map
example.com DO_CALLAHEAD

But if I test with example.com sender on a remote rcpt that is rejected,
the msg is always accepted and a bounce has to be sent back to sender.
Which is what I'm trying to avoid for this particular sender with rcpt
verification.

Is there a way to achieve that with postfix?

Thanks for any idea

tobi

Re: check if envelope from and from is the same

[Tobi]

if your auth senders spoof from headers: block their login account and
terminate their service

Am 02.10.18 um 21:17 schrieb Stefan Bauer:
> Hi,
> 
> we're running a small smtp send only service for authenticated users
> only. Even though we only accept allowed combinations of authenticated
> user and pre-defined envelope from addresses with access_maps, some
> smartasses started to spoof From: addresses so we got bad reputation at
> receiver sites.
> 
> Is this a good idea to check if envelope from and from matches and if
> so, howto do it in postfix?
> 
> thank you
> 
> Stefan

Re: Authenticating 'From' header to match envelope

[Tobi]

> when in Thunderbird someone uses the "Custom From Address" feature, it
> doesn't change the envelope sender, but only the actual "From" header
> field

are you sure? I just tested with my TB (60.0) under Linux (Fedora 28)
and found that both (envelope from and from header) are changed to the
value I defined in "custom from address"

Btw: at least the Thunderbird question should go to a thunderbird
mailing list. Not really a postfix issue here :-)

Cheers

tobi

Am 03.10.18 um 17:33 schrieb Stefan Bauer:
> Johannes,
> 
> did you double check if your planned setup will not break other things?
> 
> Have similar needs but am not yet deep enough into mail to see possible
> pitfalls.
> 
> Stefan
> 
> Am Dienstag, 2. Oktober 2018 schrieb Johannes Bauer :
>> Hi list,
>>
>> I'm having an issue with my Postfix configuration: Currently I've it set
>> up so that one authentication SASL login (e.g., m...@foo.com
> <mailto:m...@foo.com>) supports
>> multiple virtual email addresses (e.g., m...@foo.com
> <mailto:m...@foo.com> but also
>> f...@foo.com <mailto:f...@foo.com>, b...@foo.com <mailto:b...@foo.com>).
>>
>> Once authenticated with m...@foo.com <mailto:m...@foo.com>, the
> envelope sender ("MAIL FROM")
>> is restricted to only the permissible variants.
>>
>> However, as I've now painfully found out, when in Thunderbird someone
>> uses the "Custom From Address" feature, it doesn't change the envelope
>> sender, but only the actual "From" header field. This means, I have the
>> following situation:
>>
>> Auth: m...@foo.com <mailto:m...@foo.com>
>> Envelope from: m...@foo.com <mailto:m...@foo.com>
>> Header 'From': anyth...@goes.com <mailto:anyth...@goes.com>
>>
>> One of my customers used a gmail address in the header "From", sent an
>> email to @hotmail.com <http://hotmail.com> and now my mailserver is
> permablocked at Microsoft
>> for bad reputation.
>>
>> How can I ensure in the future that the same checks are applied to the
>> Header "From" field that are also applied to the evelope "From" field?
>>
>> Thanks,
>> Johannes
>>

Re: Prioritize header checks

[Tobi]

Am 09.11.2017 um 19:00 schrieb Viktor Dukhovni:
> 
> 
> Best to call that a "proxy filter" to avoid confusion.
> 
okay I see so I have a proxy filter then. As I want to be able to reject
msg by my proxy filter I need the pre-queue approach.

> 
> Only by using a content filter. 
>
and content filter it this case means post-queue filter?

Background is that my header checks should match headers (ex marked
already as spam by sending server) of messages which I do not want to
feed to my proxy filter. As processing msg via my proxy filter invokes 3
av-scanners, spamassassin and several other plugins of that filter
software. Much work for a message that after proxy filter will be
rejected by postfix header checks anyway :-)

So if I got you right: it's not possible to run header checks before
proxy filter.

Cheers and thanks

tobi

Prioritize header checks

[Tobi]

Hi list

I have a content filter running in prequeue mode to which postfix talks
via smtpd_proxy_filter.
Runs fine, but ;-) it seems to me that postfix header checks are
evaluated after the msg has been processed by the content filter.

Is it somehow possible to tell postfix to run those checks **before**
msg is passed to the content filter?

Cheers

tobi

Customize log message of postfix proxy?

[Tobi]

Hi

I use a pre-queue content filter via postfix proxy feature. Works fine :-)
My "problem" is the logmessage that is generated into maillog upon
reject of this pre-queue filter which currently looks like this:

Oct 24 09:48:29 myhost postfix/smtpd[16393]: proxy-reject:
END-OF-MESSAGE: 550 test.exe: Dangerous attachment type (Microsoft
kbid=883260); from= to= proto=ESMTP
helo=

What I'm missing here is the ip address of the sending client which
triggered that reject. Is it somehow possible to add this information to
the logs via configuration of postfix?

The only other places in my logs where I see the client IP are those lines

Oct 24 09:48:28 myhost postfix/smtpd[16393]: connect from unknown[REDACTED]
Oct 24 09:48:29 myhost postfix/smtpd[16393]: disconnect from
unknown[REDACTED]
Oct 24 09:48:29 myhost postfix/smtpd[16393]: NOQUEUE:
client=unknown[REDACTED], sasl_method=LOGIN, sasl_username=REDACTED

but I can see no way to correlate these messages with the proxy-reject
message. As I guess that the same smtpd PID is used for several
mailtransactions?

Thanks for any idea

tobi

Re: Is it possible to suppress NDR/Delayed delivery messages generated by messages to a particular RCPT?

[Tobi]

Am 02.08.2017 um 12:59 schrieb Wietse Venema:
> Why mess with NDRs, when you could reduce the intensity of the flow
> to the mbox servers?
> 

As usual thanks to Wietse for putting me in the right direction. :-)
It was not the amount of msg but the message size itself which was
problematic.

My sieve script calls external commands (my scripts) to parse out urls
from content and ips from received headers for such messages. After
looking at the queue I saw that messages which stuck were always bigger
than 2mb
So looking deeper at my scripts I found that they were very slow in
reading the message from stdin. After optimizing the read from stdin and
some other little changes even huge messages are now processed in quite
short time.
My scripts now use only the first 1024 lines from message content to
look for urls instead the whole content. And in sieve script I added a
size limit that messages over 2mb are not even passed to my scripts

Again thanks for your help Wietse

Cheers

tobi

Is it possible to suppress NDR/Delayed delivery messages generated by messages to a particular RCPT?

[Tobi]

Hello list

first of all: I know suppressing NDR/Delay Delivery Notifications is not
a "good" thing as they can be helpful.
But I have a case where I really need to suppress them :-)

My mailsystem consinsts of two postfix instances (mx and scanner) and
the mailbox servers where scanners deliver via lmtp.
The mail flow is

outside world (smtp) --> mx (smtp) --> scanner (lmtp) --> mailbox

Now I have several spamtrap addresses and catch-alls which are aliased
by mx to the same RCPT address s...@example.tld
This address does trigger some dovecot-sieve scripts on mbox upon
receiving msg via lmtp.
When the mbox servers are under heavy load the sieve-script is not
processed fast enough and postfix on scanners keep the msg in queue

> conversation with mbox.example.tld[XX.XX.XX.XX] timed out while
> sending end of data -- message may be sent more than once)
>s...@example.tld

Although I have those messages on mbox :-)

After some time the scanners try to send a delay notification to the
original sender and after queue time expired the NDR.

These notifications I want to suppress without suppressing the helpful
ones for all "normal" rcpt addresses (not trap and not catch all). The
msg to suppress have in common that they're all generated by messages
for rcpt s...@example.tld

Is it somehow possible to configure postfix to suppress notifications
but only if they're were originally triggered by a delivery for a
specific address?

Thanks and cheers

tobi

Re: Specify VPN for postfix

[Tobi]

Am 01.08.2017 um 20:39 schrieb Abi Askushi:
> Since this is socks proxy and not vpn you could redirect postfix traffic
> with iptables to the port your socks proxy listens. Plenty examples on
> google.

if you redirect the full postfix traffic you might end up in asymetric
routing.

Most important question: does this postfix accept connections/mails from
the outside world? If it does: which path these connections come to
postfix? Via VPN/Socks or directly?
If **ALL** connections to this postfix come via VPN/Socks simple
iptables rules as suggested by Abi will work.

Otherwise I gets more complex and the OP needs a routing based on the
source of the pakets. The goal is to bring answers from postfix to the
exact same path as the query from outside came in (means correct
interface and gateway). And that can only be achieved by policy based
routing.

AW: Specify VPN for postfix

[Tobi]

Easiest case if the default route for the postfix server points to the vpn 
tunnel.

If  def gw does not point to vpn then you could use nat rules on vpn server to 
replace the src address with the vpn servers vpn address. 

If NAT is not an option then you will have to setup a policy based routing aka 
source based routing on postfix server to ensure answers from postfix go back 
via the same gateway they came in.

Cheers

tobi

- Originale Nachricht -
Von: Yubin Ruan <ablacktsh...@gmail.com>
Gesendet: 01.08.2017 - 06:07
An: postfix-users@postfix.org
Betreff: Specify VPN for postfix

> Hi,
> Can anyone tell me how to point postfix to a VPN connection? I have
> setup a VPN listening at background on my Ubuntu and I want to point
> postfix to that listening port whenever postfix try to connect to the
> internet.
> 
> Thanks,
> Yubin

Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?

[Tobi]

Even with level encrypt the certificates are **NOT** verified which
means anyonymous chiphers are still used.

To verfiy peer certificates see:
http://www.postfix.org/TLS_README.html#client_tls_verify.
Or configure postfix smtp server to enforce clients to present a cert:
http://www.postfix.org/postconf.5.html#smtpd_tls_req_ccert

But to use "encrypt" on a public smtp server or enforce clients to
present certificates on such systems will lead to the fact that you
won't be receiving mails from servers which do not support TLS or do not
use a matching chipher


Am 31.07.2017 um 22:55 schrieb robg...@nospammail.net:
> I'm reading about ciphers.
> 
> Here
> 
> "why use "aNULL:!aNULL:" in Postfix default cipherlists?"
>  
> http://postfix.1071664.n5.nabble.com/why-use-quot-aNULL-aNULL-quot-in-Postfix-default-cipherlists-td83301.html
> 
> It talks about using anonymous ciphers when TLS policy is opportunistic == 
> may.
> 
> I get that.
> 
> If instead you use MANDATORY tls policy, == encrypt, do you need to redefine 
> the cipherlist to REMOVE that "aNull:-aNull"?
> 
> Rob
> 

Re: smtp port issue

[Tobi]

Am 12.06.2017 um 15:51 schrieb b...@bitrate.net:
> 25025 init  n   -   n   -   -   smtpd
typo?



signature.asc
Description: OpenPGP digital signature

Re: Why does reject_unknown_reverse_client_hostname reject this mail?

[Tobi]

Hi Wietse


Am 16.05.2017 um 20:11 schrieb Wietse Venema:
> Good luck debugging this. I expect yiu have a chroot issue.
>
as usual you are right :-)
Had chroot 'y' for several postfix processes in master.cf
After setting to 'n' and postfix restart the reverse dns check seems to
be working as expected
Just have to wait until the next mail from ntp mailinglist to be fully sure.

The only thing I do not understand yet is why forward dns resolution
worked in same chrooted environment. Also the dnsbl lookups from
postscreen always worked in chroot.
It was just rdns lookups that made problems

Thanks for your lesson in "how dns resolution works" and your patience :-)

Regards

tobi

Re: Why does reject_unknown_reverse_client_hostname reject this mail?

[Tobi]

Hi Wietse

Sorry should have mentioned after your reply that ipv6 is disabled on all my 
boxes. And have postfix inet_protocol set to ipv4 anyway 
So no reason for postfix to query a nameserver via ipv6. At least I do not see 
one :-)

Regards

tobi

- Originale Nachricht -
Von: Wietse Venema <wie...@porcupine.org>
Gesendet: 16.05.2017 - 16:19
An: Postfix users <postfix-users@postfix.org>
Betreff: Re: Why does reject_unknown_reverse_client_hostname reject this mail?

> Tobi:
>> Am 16.05.2017 um 13:15 schrieb Wietse Venema:
>> > Tobi:
>> >>> Client host rejected: cannot find your reverse hostname,
>> >>> [185.140.48.241]
>> > Here's a hint:
>> >
>> > % host 185.140.48.241
>> > ;; connection timed out; no servers could be reached
>> I can reliably resolve that ip from my server.
> 
> Read my reply again, and pay attention to the part that 
> talks about IPv6.
> 
>   Wietse

Re: Why does reject_unknown_reverse_client_hostname reject this mail?

[Tobi]

Am 16.05.2017 um 13:15 schrieb Wietse Venema:
> Tobi:
>>> Client host rejected: cannot find your reverse hostname,
>>> [185.140.48.241]
> Here's a hint:
>
> % host 185.140.48.241
> ;; connection timed out; no servers could be reached
I can reliably resolve that ip from my server.
Since then I have a script running on the server that checks the rdns
every 5min. Not one try that could not get a rdns

host 185.140.48.241
241.48.140.185.in-addr.arpa is an alias for
241.192/26.48.140.185.in-addr.arpa.
241.192/26.48.140.185.in-addr.arpa domain name pointer psp3.ntp.org.

If you say that the above result cannot not trigger such a reject then I
would assume a timeout issue too.
I just wanted to be sure as I've never seen such a rdns reply before :-)

Thanks and regards

tobi

Why does reject_unknown_reverse_client_hostname reject this mail?

[Tobi]

Hello list

recently I setup rDNS rejects for postfix via 

> reject_unknown_reverse_client_hostname

in smtpd_client_restrictions in main.cf

After that I saw in the logs that mails from the ntp mailinglist get rejected

> Client host rejected: cannot find your reverse hostname,
> [185.140.48.241]

I checked their rDNS on the same machine that rejected them and found

> 241.48.140.185.in-addr.arpa. 2731 INCNAME   
> 241.192/26.48.140.185.in-addr.arpa.
> 241.192/26.48.140.185.in-addr.arpa. 931IN PTRpsp3.ntp.org.

Is that rDNS bogus so postfix "thinks" it's a unknown/broken rDNS and rejects 
it? 

Regards

tobi

Re: Telnet auth

[Tobi]

If you do not accept submission on port 25, you could add a
sender_access map to the service on port 25

smtpd_sender_restrictions =
...
 check_sender_access hash:/etc/postfix/sender_access
...

and in said file list your domains each with action "reject"

Am 18.05.2016 um 12:22 schrieb Catalin Badirca:
> Thank you very much for your time and sorry for the long response time. 
> 
> I've tried your suggestion and the issue remains. Someone could telnet into 
> postfix and would be allowed to send mails from a valid address to another 
> valid address in mydomain without authentication.
> 
> Is there any way I can stop potential spam for mydomain ?
> 
> Thabk you !
> 
> Sent from my iPhone
> 
>> On 16 May 2016, at 20:21, /dev/rob0  wrote:
>>
>>> On Mon, May 16, 2016 at 07:25:54PM +0300, Catalin Badirca wrote:
>>> I am breaking my head trying to solve the following thing. I have a 
>>> Postfix server that accepts mail from $mydomain and delivers for
>>
>> "From $mydomain" probably has nothing to do with it.
>>
>>> standard $mydestination. I also have smtp_relay_redtriction to
>>
>> smtpd_relay_restrictions, spelling DOES count, and be especially 
>> aware of the "smtp_* != smtpd_" issue.
>>
>>> allow sasl and reject other destinations than $mydomain. Standard
>>
>> s/mydomain/mydestination/ , that is.
>>
>>> until now. The thing is: if i telnet to the machine and try to send 
>>> mail from a valid address to another valid address in $mydomain i 
>>> can do it without beeing forced to authenticate. I can easily force 
>>> reject instead of reject_unauth_destination and tale care of this 
>>> but then no emails for me.
>>>
>>> Does anyone know a solution for this please ?
>>
>> It's quite simple, actually.
>>
>> Do not accept user submission on port 25.  Remove all permit_* 
>> restrictions from the global configuration.  Don't advertise nor 
>> accept AUTH on port 25.
>>
>> Do not accept mail exchange on port 587.
>>
>> main.cf:
>> ...
>> smtpd_relay_restrictions = reject_unauth_destination
>> submission_relay_restrictions = permit_sasl_authenticated, reject
>> # smtpd_sasl_auth_enable is "no" by default, so omit that, but
>> # other smtpd_sasl_* settings can go here
>> ...
>>
>> master.cf:
>> ...
>> submission inet  n   -   n   -   -   smtpd
>>-o smtpd_tls_auth_only=yes
>>-o smtpd_sasl_auth_enable=yes
>>-o smtpd_recipient_restrictions=
>>-o smtpd_relay_restrictions=$submission_relay_restrictions
>>-o milter_macro_daemon_name=ORIGINATING
>>-o syslog_name=postfix/submission
>> ...
>>
>> (That example assumes that TLS is set up for smtpd.)
>>
>> Yes, someone can still  "telnet" to port 25 and send mail to your 
>> addresses/users.  That's what mail exchange is.  Nothing is magic 
>> about telnet, it is just one of many ways to make a TCP connection.
>> That's the same thing a MTA client will do when delivering mail on 
>> behalf of their user to one of your addresses.
>> -- 
>>  http://rob0.nodns4.us/
>>  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: underscore in domains

[Tobi]

Am 17.02.2016 um 09:30 schrieb Suuuper:

> 
> I tried to add reject_non_fqdn_recipient in
> smtpd_recipient_restrictions, but it doesn't work.
> 

use a regexp on recipient and/or sender domain to reject such messages.
postfix accepts underscore in domain names as this is a common mistake
by many legitimate admins

Re: Postfix claims no MX host for ogrj.ch has a valid address record

[Tobi]

Just as an update:

Our loadbalancers have troubles with dns responses which contain several
hosts. For some domains they corrupt the dns cache on the loadbalancer
and therefore deliver such bogus responses.
This behaviour even occurs if no dns cache settings are set on the
loadbalancer.
The manufactor (a10 networks) opened a bug report and will fix the issue
in a future software release.

So it never was a postfix problem :-)

Am 11.06.2015 um 15:40 schrieb Viktor Dukhovni:
 On Thu, Jun 11, 2015 at 12:23:47PM +, Viktor Dukhovni wrote:
 

 ogrj.ch.3057IN  MX  10 smtasg01.abxsec.com.
 ogrj.ch.3057IN  MX  20 smtazh01.abxsec.com.
 ogrj.ch.3057IN  MX  110 smta2.abxsec.com.
 ogrj.ch.3057IN  MX  120 smtp1.seabix.com.
 ogrj.ch.3057IN  MX  130 smta4.abxsec.com.
 ogrj.ch.3057IN  MX  140 smta3.abxsec.com.
 ogrj.ch.3057IN  MX  510 mtas.abxsec.com.
 ogrj.ch.3057IN  MX  520 mtaz.abxsec.com.

 Jun 11 11:09:07 smtp2 postfix/smtp[19862]: warning: no MX host for
 ogrj.ch has a valid address record

 There was a problem looking up the addresses of the above hosts,
 perhaps a nameserver was down, or a network connectivity problem
 prevented access.

 Jun 11 11:09:07 smtp2 postfix/smtp[19862]: 2B25317FA69:
 to=removed_for_priv...@ogrj.ch, relay=none, delay=0.18,
 delays=0.15/0/0.03/0, dsn=5.4.4, status=bounced (Host or domain name
 not found. Name service error for name=smtp1.seabix.com type=A: Host
 not found)

 Postfix logged the problem for one of the MX hosts.
 
 However, given that the message then bounced, the problem did not
 manifest as a transient problem.  For some reason at the time in
 question the MX RRset authoritatively did not contain any hosts
 that had an IP address and it looks like smtp1.seabix.com was
 the last host by MX preferene.
 




signature.asc
Description: OpenPGP digital signature

Postfix claims no MX host for ogrj.ch has a valid address record

[Tobi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello list

I currently have a weird problem with my postfix installation. Emails
to the domain ogrj.ch cannot be sent anymore. Postfix claims that no
MX host for said domain has a valid address record.
A dns query for the MX of this domain tells me that the following
hosts act as MX

ogrj.ch.3057IN  MX  10 smtasg01.abxsec.com.
ogrj.ch.3057IN  MX  20 smtazh01.abxsec.com.
ogrj.ch.3057IN  MX  110 smta2.abxsec.com.
ogrj.ch.3057IN  MX  120 smtp1.seabix.com.
ogrj.ch.3057IN  MX  130 smta4.abxsec.com.
ogrj.ch.3057IN  MX  140 smta3.abxsec.com.
ogrj.ch.3057IN  MX  510 mtas.abxsec.com.
ogrj.ch.3057IN  MX  520 mtaz.abxsec.com.

In the postfix logs I get the following:

Jun 11 11:09:07 smtp2 postfix/smtp[19862]: warning: no MX host for
ogrj.ch has a valid address record
Jun 11 11:09:07 smtp2 postfix/smtp[19862]: 2B25317FA69:
to=removed_for_priv...@ogrj.ch, relay=none, delay=0.18,
delays=0.15/0/0.03/0, dsn=5.4.4, status=bounced (Host or domain name
not found. Name service error for name=smtp1.seabix.com type=A: Host
not found)

what I do not understand so far is, that postfix seems to try to
connect to smtp1.seabix.com which has prio 120
Why does postfix not try to connect to the 10 or 20 prio hosts?

For other domains which are handled via the same MX we could deliver
without any problem to MX host with prio 10

Jun 11 11:28:23 smtp1 postfix/smtp[6995]: 8127A17F87B:
to=removed_for_priv...@stadt.sg.ch,
relay=smtasg01.abxsec.com[193.246.80.88]:25, delay=1.4,
delays=0.04/0/0.12/1.3, dsn=2.0.0, status=sent (250 2.0.0
t5B9SMtO014723 Message accepted for delivery)

The difference between these two domains is that stadt.sg.ch only has
two MX hosts

stadt.sg.ch.60  IN  MX  20 smtazh01.abxsec.com.
stadt.sg.ch.60  IN  MX  10 smtasg01.abxsec.com.

Does anyone have a clue where I could dig more to narrow the source of
the problem?

Thanks for any idea
Cheers

tobi
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVeXn2AAoJEDUc5iWoaKTkFnEP/jjKrJRzSrcUDLsc1LKDtR+y
vKSLAj6cc79HsOIIWQGmuUPFuTrFddes+ztnonzBINqAoGt3xfvkj8cTqYGmICkm
h4C4sByip4lVhROndgT57fmxN0e5+mxAkhE8MAkC197cvkiaWCe9ziLcpxfMunju
hRLEhKJxc3+Wt75/sI6mz4+/PBJtJ4ygAMXmOZ+jBR0eWTpHIdUSQ4aBKOBfVS12
6nFSggtV/UwTXXMo1wIqjU6BttL3FGGrjmAwUS5XXrd7q7TmtMoXnrfQgRP1KQGg
+3WubcLlYiI2o/7L47QMw/KgFrhiOL4kwrGNn1WaPwwMQWAFlvCwD14fTMlU51i8
j7oYegAXAW6cgL4C8S33M5XquHNuUOhx2uUjtz5sBqjOEU/pYIRbYGS47AGfGmOM
IUi+YCxZeWl6tN6l2jnzCiG+Q8L0agsdZHddYgNOPUsnxn8/npTdzk0fti+XgoSN
sFeiYQW8w2B88vPVxEZbrKSjoQS9GKjRICqP2i8KmQhApAGapkZulLHNdF7R2bKs
5gsSN5dgCUvCe3cF/XDi7kabmuQDbAoUkhnp5kKMDvCav57fQ6kkVt1naP1zyN+e
NcdUXsgYfsZD35PQeh8/OacC9uSe8rSM1qVjDi1OW8iHkitD7avvcEHabqY7AB7u
bFJ8HhvatqMmi9J4fzBe
=zmJX
-END PGP SIGNATURE-

Re: Postfix claims no MX host for ogrj.ch has a valid address record

[Tobi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am 11.06.2015 um 14:23 schrieb Viktor Dukhovni:

 There was a problem looking up the addresses of the above hosts, 
 perhaps a nameserver was down, or a network connectivity problem 
 prevented access.
 
I thought about that too but after my tests it seems to be very
unlikely for me :-)
I just sent a testmail to the user at the orgj.ch domain and instantly
received the same error from postfix.

Jun 11 14:50:35 smtp1 postfix/smtp[29194]: warning: no MX host for
ogrj.ch has a valid address record
Jun 11 14:50:35 smtp1 postfix/smtp[29194]: DA85418006C:
to=remo...@ogrj.ch, relay=none, delay=0.08, delays=0.06/0.01/0/0,
dsn=5.4.4, status=bounced (Host or domain name not found. Name service
error for name=smta3.abxsec.com type=A: Host not found)

I checked the dns on the server that issued the error and had no
problems in resolving the MX hosts and get a A record for the MX with
prio 10

# mx records
;; ANSWER SECTION:
ogrj.ch.3447IN  MX  120 smtp1.seabix.com.
ogrj.ch.3447IN  MX  130 smta4.abxsec.com.
ogrj.ch.3447IN  MX  140 smta3.abxsec.com.
ogrj.ch.3447IN  MX  510 mtas.abxsec.com.
ogrj.ch.3447IN  MX  520 mtaz.abxsec.com.
ogrj.ch.3447IN  MX  10 smtasg01.abxsec.com.
ogrj.ch.3447IN  MX  20 smtazh01.abxsec.com.
ogrj.ch.3447IN  MX  110 smta2.abxsec.com.


# A record for MX with prio 10
;; ANSWER SECTION:
smtasg01.abxsec.com.768 IN  A   193.246.80.88

# finally test a connection
telnet smtasg01.abxsec.com 25
Trying 193.246.80.88...
Connected to smtasg01.abxsec.com.
Escape character is '^]'.
220 smtasg01.abxsec.com ESMTP Thu, 11 Jun 2015 14:51:01 +0200
QUIT
221 2.0.0 smtasg01.abxsec.com closing connection
Connection closed by foreign host.

So connections to the mx host with prio 10 seems to be working, just
one or two seconds after postfix showed the error.

I really tested a lot of queries manually and NEVER had problems with
resolving. Therefore I wonder why postfix sees a problem with EVERY
mail for the domain ogrj.ch

Thanks

tobi

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVeYmQAAoJEDUc5iWoaKTksJIP/irTXg2pRLImE5uSGF1N4Qff
JDOdIaLo8AMDT/HEPmTCjO4+q01F3A2EOULTXOq7xHkwQXbM8yiot4RYfFQh6HSr
TYZrY6mFkzEpWs4564GBfHcqaX+IFZeb6MZ8ZlXKjBmUxCbQ8/KcCK3dReSqTv2R
62sQwJXgN/CPKHXg96zj8o2yeQSjfsP4WR8f9Kjh2+YOW4gTVN9OxUCNjiV8Icgr
Cnw+eAFJSl2SMmv9ioKB2VoCk3P3S17EXOuzvSMRW24UEYDbN8kTwPGrcIEHlyLi
5Aj6pFD/eIeqkm+ZeaZYxybTtde3Zgkfv/nx1IzK0SzyeEostQnKuy2jFbkeW/QN
OisxKr84nRgm8+rK21J/WeKCGO5K8TpGnjFUXII+9RO2f30L/P/I8KduXfI27aFZ
867/kDXcm5kBmitJNU0Phi4BKjM6mWXk2/ePsEgr5DGT72rA19GL6NIeW+a3T+Bh
CWpH/e/7+qrZgKQ5qFj5wwXtA/2VxVpSlmakXVHHowYRXWrB/69pqG/MmuzI+/bc
7Hpn2eK7YhvjRTjIN3w/sxkp4hXW07PLpZLuLNr8Wram+IRywtGnybJQmVB2cGe2
aqOqGVqxqsBYYcTEOFtp6p1ivGvw4lQs1xJr/16WEmQwtNp2NCGK8IQxJhz9MUTR
h2jgALW2Dd0pqItxjkiy
=odEb
-END PGP SIGNATURE-

Re: SQL table lookup

[Tobi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am 07.05.2015 um 18:43 schrieb Rod K:
 I'm trying to implement
 
 check_client_restrictions = check_client_access
 pgsql:/path/to/local_blacklist-sql.cf, ...
 
have you had a look at postfix postscreen featue?
http://www.postfix.org/POSTSCREEN_README.html
I recommend to implement ip based blocklists via postscreen.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVTGbPAAoJEDUc5iWoaKTk8T0QAInAbR5HbtWoKwIwQfoKRkNL
qTjQtbKn12l2/htyANr/C+EpeQp8jUMDTSHMJ0qd/u6oLR/WoVANrpLWYGS9JraU
zZLh/Kw9b5l785iN38gjBTO6yBMVqVwm+7ct50J3P/y+qm/aHmWmGaC1GHVF0ZfU
+D3216gfSASJPSwKKbPXOxp3XVAktivJaXR4UB4dd+9tg8fCDlMReoRiekB4Vqjr
EBHveTLQlugB2wdoX0F+z3TKDVKhz6wNLtfe9XKVgtwyYVe9+4Tj3UL5Eniseysc
WCyy8favHOtfxMB18Y/mn+1kLgs2qftHVAR8ScN1q2mEpBKzgC/HbEhw5g/r1IXo
yn3xZSrG5rza9D0xK99Dwra+YPOWeDOkqt67eOzIUhi6Drk5E1R8vNFzMdT98H1i
uWiaYQ0w4X9yWuN9U2HXZ9B7PHy5Sqr1yvui/U05+c1QhJWZLpFhMR1hyK+2fv0t
b7wLwKPiJ3nZ3C3OV6MYplSIfjx34HEpDFSj6ZxNKiKbKiE0qai+rKs57rKRhsFu
ilIAPDRJvF2C/D79WqtpalB9n3i+e8yM4jG5GoKPJx19dCRmG+FFS0X52y7l4ZTN
BvNVXnCUTkltIc9MbZY84fIFT8ntkcbpmFEqDMcMb6rXJqy7WH4Ths6VBQqTOMkA
INVe+PeMJbST42BfhGH9
=IGeJ
-END PGP SIGNATURE-

Re: Send copy of incoming email to old mail server

[Tobi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I would suggest you to have a look into the doc

http://www.postfix.org/ADDRESS_REWRITING_README.html#receiving

in our case eigther alias or auto bcc should solve the problem



Am 07.05.2015 um 12:56 schrieb Kashif Ali Bukhari:
 Hi list fellows
 
 I am in a process to move my email server from Microsoft offiice365
 to postfix. postifx is all setup and working like charm , but now i
 want all incoming emails which delivered to postfix inbox should
 send a copy to Microsoft office 365 mailbox.
 
 this will help me to trancer my users from old server to new
 server. if some one login to old server he//she would be able to
 see his emails on old server too.
 
 please guide me about postfix mail delivery as above requirment .
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVS3esAAoJEDUc5iWoaKTkXLkP/iaCnaoHYaVa34GcZR3whQ5W
CJvCbMnjG+ZXlCKbfRI0AIIFF3IAUBJanRhuG6Dh/43YSzpoLUIrINrh4L7O2Dxh
4Rz3RYgGKqxqtoCBBIW+9J8pCh9xdxLRvkxlA0a1eVZvJke97oePpCtmpoi6XrID
bT1nq2zLUTXZwZfSH6qn2/xuE9rI9ap8mHPWRLGKTYhAI1H4K0wEDzhDp0azUfUJ
U/f3nvUg3D5R7ByJOnkCfolEjpZp7Jrx0zbMr0/xDnhng5fdNMXG62AuqDzjs0Qu
KMsf+shg6VC4iXg2A3jhCFkHQuflr9lo5ILYiYAsB7dFHp9UXEdWh9+aIjphwSxt
sGVj59SHgaIKB0+8dxmfLIn4cPKWj1Qbyr68XW98nVTK2I4qZeKJXSPwlxAj1puW
2ePEVU2+kJqpG/JUoAdifTyGKiD9aIeVDm0hx2COdtR6E3Tiw2NUEkyvcwxL8G34
YuR/D2abqs1DXmp07I8s6OLncZIQkOThd3gdDTkVS5rSetPVO9B29yKL3Z34W7mn
mvYGRBdS/UoQhw1BQYdMV2L/sTMG0AxxN7vf1qjgKwl38UqZwO55QLv1XqCeX3Bb
2Ku5ThpC1NS8f1C2iLonHQIuRQkGAE+og7aQ08elF/zuwrkOI6eDt+3Aa2Ge2MK0
N8Pj4LszZ8oq2gHddBni
=ibW7
-END PGP SIGNATURE-

postfix-policyd-spf-perl and troubles with Amazon?

[Tobi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi list

I know it's technically not a postfix issue :-) But maybe someone else
here on this list has the same problem.
I'm using Postfix with postfix-policyd-spf-perl About 4 or 5 days ago
I started to get error messages from postfix for mails from Amazon.
The log shows


May  6 15:33:12 mail1 postfix/policy-spf[10692]: Policy
action=DEFER_IF_PERMIT SPF-Result=marketplace.amazon.de ...
spf1.amazon.com: Unknown error on DNS 'TXT' lookup of 'spf1.amazon.com'
May  6 15:33:12 mail1 postfix/smtpd[10069]: NOQUEUE: reject: RCPT from
a0-3.smtp-out.eu-west-1.amazonses.com[54.240.0.3]: 450 4.7.1
tobs...@brain-force.ch: Recipient address rejected:
SPF-Result=marketplace.amazon.de ... spf1.amazon.com: Unknown error on
DNS 'TXT' lookup of 'spf1.amazon.com';
from=comm-bounces+bbc-message-a370530b4pb...@marketplace.amazon.de
to=tobs...@brain-force.ch proto=ESMTP
helo=a0-3.smtp-out.eu-west-1.amazonses.com
May  6 15:33:37 mail1 postfix/smtpd[10069]: disconnect from
a0-3.smtp-out.eu-west-1.amazonses.com[54.240.0.3]
 

I did not change anything on the server side. I tried to verify the
SPF records from Amazon with
http://www.kitterman.com/spf/validate.html but the tests were always
successfull.
Does anyone have this problem too with Amazon? Or does anyone have an
idea how to solve it?

Thanks

tobi
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVShrmAAoJEDUc5iWoaKTkd7kP/RxLTO0uzrxcPg348cnm9yjG
l2fIodQqvyRG2BgloKd3ldseVhc5B1+f/Ee+xFiofjMI5KSMYf9UbiH2cmmbfBZq
/AyZesUwwDUsHWHw6vhY9DwXP/QjHLLpUOsiY0iyQsH2sesOneSYYp0W1ZHmDcOU
CRF07QgduCOHNsHueEsw8BF+RqluXIwklJ83hXZBziTBT0PR0QvF9ZW/TxI3n+Sg
Pkijo5e/l48efvykZffJjl6qMC22twS42hCHCnHbZujjg7vaSvyTGaVGzfuEGRUn
z3qCe0ISDKM2QyB2ljXmCITwWT5tt/2rdkA5UV/ENHpl5g66y0aMV7sJP9Hd7QBG
l2UeuLMtiq3IMy+Banc30ZiBq/Id0IdpkidHzn+3kgxP9SDf4VBvXJpSozz8i/BN
ASvggyeRno08tcqBBgysX7FXn+m1s3KGYfWNWrrWe4061Fh2gcLw3zgrE1CyO9OH
9uS3jeD5EiMQYfQ9vb5ZHhBWz7BbA1TC3KQg7wP7nuGIeKqAUL821PX38xKoMiva
lTVtx5IRqMfh8gDuVf6umO1BnUpx8ttc5hPd2HGPRyD5d+lZhP7FBrjaFPwf7UHe
w0wyAFQXVzo2vGImq2GReZE/Em88NNvHqNcbKgNcDWLe+35v/Rm1W+83PD+slumB
gSvSt8ODswf8UjbrWbbp
=2Xb7
-END PGP SIGNATURE-

Re: postfix-policyd-spf-perl and troubles with Amazon? [SOLVED]

[Tobi]

@Scott

thanks for putting me into the right direction :-)
The answer for spf1.amazon.com TXT is indeed too big for UDP. So the 
query was retried in TCP mode.
But the stupid admin (aka myself) forgot that he disabled tcp on the 
mailservers local resolvers (unbound). After enabling tcp mode for 
unbound the queries for spf1.amazon.com TXT were properly answered properly.

Amazon did not retry yet, but I'm sure that this solved the problem.

Thanks a iot

tobi

Am 06.05.2015 um 16:11 schrieb Scott Kitterman:

On Wednesday, May 06, 2015 09:58:57 AM James B. Byrne wrote:

On Wed, May 6, 2015 09:45, Tobi wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi list

I know it's technically not a postfix issue :-) But maybe someone else
here on this list has the same problem.
I'm using Postfix with postfix-policyd-spf-perl About 4 or 5 days ago
I started to get error messages from postfix for mails from Amazon.
The log shows


May  6 15:33:12 mail1 postfix/policy-spf[10692]: Policy
action=DEFER_IF_PERMIT SPF-Result=marketplace.amazon.de ...
spf1.amazon.com: Unknown error on DNS 'TXT' lookup of
'spf1.amazon.com'
May  6 15:33:12 mail1 postfix/smtpd[10069]: NOQUEUE: reject: RCPT from
a0-3.smtp-out.eu-west-1.amazonses.com[54.240.0.3]: 450 4.7.1
tobs...@brain-force.ch: Recipient address rejected:
SPF-Result=marketplace.amazon.de ... spf1.amazon.com: Unknown error on
DNS 'TXT' lookup of 'spf1.amazon.com';
from=comm-bounces+bbc-message-a370530b4pb...@marketplace.amazon.de
to=tobs...@brain-force.ch proto=ESMTP
helo=a0-3.smtp-out.eu-west-1.amazonses.com
May  6 15:33:37 mail1 postfix/smtpd[10069]: disconnect from
a0-3.smtp-out.eu-west-1.amazonses.com[54.240.0.3]


I did not change anything on the server side. I tried to verify the
SPF records from Amazon with
http://www.kitterman.com/spf/validate.html but the tests were always
successfull.
Does anyone have this problem too with Amazon? Or does anyone have an
idea how to solve it?

Thanks

dig spf1.amazon.com TXT

;; ANSWER SECTION:
spf1.amazon.com.900 IN  TXT spf2.0/pra ip4:207.171.160.0/19
ip4:87.238.80.0/21 ip4:72.21.192.0/19 ip4:194.154.193.192/27
ip4:194.7.41.152/28 ip4:212.123.28.40/32 ip4:203.81.17.0/24
ip4:72.21.212.0/25 ip4:178.236.10.128/26 -all
spf1.amazon.com.900 IN  TXT v=spf1 ip4:207.171.160.0/19
ip4:87.238.80.0/21 ip4:72.21.192.0/19 ip4:194.154.193.192/27
ip4:194.7.41.152/28 ip4:212.123.28.40/32 ip4:203.81.17.0/24
ip4:72.21.212.0/25 ip4:178.236.10.128/26 -all

Amazon has screwed up their spf records.  A DNS host can have only ONE
spf TXT RR and that must not contain or recursively resolve to more
than TEN tags.

You will have to contact the DNS maintainer for the amazon.com zone

;; AUTHORITY SECTION:
amazon.com. 60  IN  SOA dns-external-master.amazon.com.
root.amazon.com. 2010112764 180 60 3024000 60

Who evidently is reached via r...@amazon.com.  Good luck with that.

No.  That's not it.  One of those is a v=spf1 SPF record and the other is a
spf2.0 Sender ID record.

Much more likely the issue is the use of EDNS0.  In the part of the dig output
you didn't include, you probably got:

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096

and

;; MSG SIZE  rcvd: 611

I would guess that they published a new record that pushed them outside the
size of a UDP packet, so it used EDNS0, and there's some incompatible box in
the middle (and there wasn't such a box similarly in between amazon and my SPF
validator).

Followups should probably go to:

https://answers.launchpad.net/postfix-policyd-spf-perl

Scott K

Alias expansion when relay possible?

[Tobi]

Hello list

I have a postfix setup with a frontend and two backend servers.  The
problem is that one user has forward (ex forwards to his mailbox and to
another one). The problem is that one mailbox is on backend1 and the
other (expanded from alias) is on backend2. Now I thought okay I add a
transport mapn on each backend


user = xxx
password = xxx
hosts = xxx
dbname = mail
query = SELECT CONCAT('smtp:[',backend,']:25') AS transport FROM mailbox
WHERE username = '%u@%d' AND active=1 AND backend != '192.168.50.42'

now backend1 (ip 192.168.50.42) receives an email for u...@domain.tld
and this should be expanded to u...@domain.tld and us...@domain.tld.
u...@domain.tld which mailbox is on backend1 is not the problem and is
delivered via dovecot.
But us...@domain.tld which mailbox is on the other backend
(192.168.50.41) generates the following errors in the logs


Nov  6 13:39:19 backend2 postfix/smtp[12130]: 5826E280645:
to=us...@domain.tld, orig_to=u...@domain.tld,
relay=192.168.50.41[192.168.50.41]:25, delay=0.07,
delays=0.05/0.01/0.01/0, dsn=5.4.6, status=bounced (mail for
[192.168.50.41]:25 loops back to myself)


I found that this is because domain.tld is listed as
virtual_mailbox_domains on both backends. So backend1 always assumes
it's final destination for domain.tld although the transport tells to
send to another server.

The only way I could see to solve is to perform the alias expension
already on the smtp frontend. But I could not find a parameter to do
this like relay_alias_maps or something like that.
Is there a way to perform the alias on the frontend before it relays to
the respective backend?

Thanks a lot for any idea :-)

tobi

Re: [SOLVED] Alias expansion when relay possible?

[Tobi]

Should have thought before writing :-)
Changed the quries on the backends to



query = SELECT CONCAT('lmtp:[',backend,']:24') AS transport FROM mailbox
WHERE username = '%u@%d' AND active=1 AND backend != '192.168.50.42'


activated dovecot-lmtp on all backends.
That works as it should :-)

tobi

Am 06.11.2014 um 13:57 schrieb Tobi:
 Hello list

 I have a postfix setup with a frontend and two backend servers.  The
 problem is that one user has forward (ex forwards to his mailbox and to
 another one). The problem is that one mailbox is on backend1 and the
 other (expanded from alias) is on backend2. Now I thought okay I add a
 transport mapn on each backend

 
 user = xxx
 password = xxx
 hosts = xxx
 dbname = mail
 query = SELECT CONCAT('smtp:[',backend,']:25') AS transport FROM mailbox
 WHERE username = '%u@%d' AND active=1 AND backend != '192.168.50.42'
 now backend1 (ip 192.168.50.42) receives an email for u...@domain.tld
 and this should be expanded to u...@domain.tld and us...@domain.tld.
 u...@domain.tld which mailbox is on backend1 is not the problem and is
 delivered via dovecot.
 But us...@domain.tld which mailbox is on the other backend
 (192.168.50.41) generates the following errors in the logs

 
 Nov  6 13:39:19 backend2 postfix/smtp[12130]: 5826E280645:
 to=us...@domain.tld, orig_to=u...@domain.tld,
 relay=192.168.50.41[192.168.50.41]:25, delay=0.07,
 delays=0.05/0.01/0.01/0, dsn=5.4.6, status=bounced (mail for
 [192.168.50.41]:25 loops back to myself)
 I found that this is because domain.tld is listed as
 virtual_mailbox_domains on both backends. So backend1 always assumes
 it's final destination for domain.tld although the transport tells to
 send to another server.

 The only way I could see to solve is to perform the alias expension
 already on the smtp frontend. But I could not find a parameter to do
 this like relay_alias_maps or something like that.
 Is there a way to perform the alias on the frontend before it relays to
 the respective backend?

 Thanks a lot for any idea :-)

 tobi

Why is there msg id in logs but no recipient?

[Tobi]

Hi list

I got a imho weird problem with understanding the logs. We have an
client that authenticates correctly which generates an id from postfix.
If I grep this id through the logs I can see a logline with a
message-id. But why there is no recipient?


Nov  5 05:26:44 213.196.149.XX postfix/smtpd[30553]: B93D2180036:
client=unknown[188.119.245.XX], sasl_method=LOGIN,
sasl_username=our_u...@example.com
Nov  5 05:26:46 213.196.149.XX postfix/cleanup[30375]: B93D2180036:
message-id=01cff8b0$b57dd950$20798bf0$@example.com

I cannot understand why we get the message-id without any recipient.
Normally if I grep the postfix id from a login I can find a line with a
to=recipi...@example.com
I could understand if we only have the first line. That would mean for
me that the client authenticated but did not send an email.
But does the message-id not mean that DATA has been transmitted from
client? But then there should be a RCPT TO or not?

Thanks

tobi

Re: Why is there msg id in logs but no recipient?

[Tobi]

Am 05.11.2014 um 11:40 schrieb li...@rhsoft.net:
 Am 05.11.2014 um 11:37 schrieb Tobi:
 I got a imho weird problem with understanding the logs. We have an
 client that authenticates correctly which generates an id from postfix.
 If I grep this id through the logs I can see a logline with a
 message-id. But why there is no recipient?

 Nov  5 05:26:44 213.196.149.XX postfix/smtpd[30553]: B93D2180036:
 client=unknown[188.119.245.XX], sasl_method=LOGIN,
 sasl_username=our_u...@example.com
 Nov  5 05:26:46 213.196.149.XX postfix/cleanup[30375]: B93D2180036:
 message-id=01cff8b0$b57dd950$20798bf0$@example.com

 I cannot understand why we get the message-id without any recipient.
 Normally if I grep the postfix id from a login I can find a line with a
 to=recipi...@example.com
 I could understand if we only have the first line. That would mean for
 me that the client authenticated but did not send an email.
 But does the message-id not mean that DATA has been transmitted from
 client? But then there should be a RCPT TO or not?

 just grep for the client's IP

 maybe connection lost or something similar
 not all loglines contain the queue-id
Hi

thanks for your input. After greping for the ip I could see 'timeout
after data'
But I still wonder why there is a message-id logged? Is the message-id
generated before the complete tranmission of DATA?

Thanks

tobi

Re: 20-40+ second delays. Is this normal?

[tobi]

Am 18.03.2014 17:13, schrieb jmct:


I spoke with one of our Linux administrators and he advised that SELinux
didn't even cross his mind because he's so used to disabling it on install.
:P


Just curious: normally postfix runs quite well with selinux enabled. 
Have you checked the audit logs where selinux reports details of 
violations? Normally under /var/log/audit/ and grep the latest logfile 
for postdrop
With that lines you might be able to create a selinux policy module that 
can be loaded.
Just my 5 cents: disabling a security feature like selinux is not the 
best choice.
Just one more thing: did you try selinux mode targeted as well? Same 
problem?

Re: Compromised Passwords

[tobi]

Am 04.03.2014 23:38, schrieb Homer Wilson Smith:

  Change their password?

from my experience the only thing that really stops the spam
Maybe it's anoying for the account owner but it works most reliable.
Counting IPs might help also but what if the spammer uses the same src 
ip for its garbage? Your server would be on blacklists and all clients 
are affected.
So imho it's really better to change passwords, that case only one user 
is affected.

Have a published abuse contact and react on complains promptly also helps.
To make it harder for the spammers to get login credentials we use 
fail2ban which monitors maillogs for failed logins and blocks IPs after 
X numbers of failed logins. The ban time we keep just some minutes, but 
thats enough for most of the bruteforcers to go to another server

Re: Postfix 2.9.6-2 on debian wheezy with a mysql problem?

[Tobi]

Am 07.11.2013 23:55, schrieb Viktor Dukhovni:
 On Thu, Nov 07, 2013 at 11:46:43PM +0100, Tobi wrote:

 If the ip/port are different, it is not the *SAME* configuration.
 I know but it's not possible otherwise. The two other server reach
 the mysql-cluster via other ips/ports.
 Do double-check that 3rd configuration file, make sure it contains
 no hidden backspace or unusual whitespace characters that might
 upset MySQL.

 If MySQL reports a missing table, I would not doubt that. Thus
 either your configuration has non-trivial differences you're not
 reporting, or you're reaching a different MySQL.  Debug your NAT
 or cluster config.

Hi Victor

The error message is 99.999% not from mysql. Because when I remove the
backticks around the table name then I get an error from mysql which
looks different

postmap -q '192.167.34.21' mysql:/etc/postfix/mysql-test.cnf
*postmap: warning: mysql query failed: You have an error in your SQL
syntax; check the manual that corresponds to your MySQL server version
for the right syntax to use near '-cidr WHERE inet_aton('192.167.34.21')
BETWEEN `network` AND `broadcast`' at line 1*
postmap: fatal: table mysql:/etc/postfix/mysql-test.cnf: query error:
Success
2013 Nov  8 15:36:45 mail1 fatal: table
mysql:/etc/postfix/mysql-test.cnf: query error: Success

Furthermore as I wrote in my first mail here I can connect via mysql
from my mailserver to the database and fire the query as stated in the
cnf file without any problem. So the query itself is a valid query for
mysql.

Normally I would not doubt if mysql reports a missing table. But if this
table would be really missing, then none of my mailserver would be in
operating state anymore.

I just connected from the mailserver in question to the datase using ip,
port and credentials from cnf file and made a show table

mysql show tables;
+---+
| Tables_in_postfix |
+---+
| alias |
| autoreply |
| blacklist-cidr|
| mailbox   |
| vmailbox  |
+---+

And as this is a cluster based setup it's (imho) not possible that one
client can see the table and another not

tobi

Re: Postfix 2.9.6-2 on debian wheezy with a mysql problem?

[Tobi]

Am 08.11.2013 15:59, schrieb Wietse Venema:
 Tobi:
 Am 07.11.2013 23:55, schrieb Viktor Dukhovni:
 On Thu, Nov 07, 2013 at 11:46:43PM +0100, Tobi wrote:

 If the ip/port are different, it is not the *SAME* configuration.
 I know but it's not possible otherwise. The two other server reach
 the mysql-cluster via other ips/ports.
 Do double-check that 3rd configuration file, make sure it contains
 no hidden backspace or unusual whitespace characters that might
 upset MySQL.

 If MySQL reports a missing table, I would not doubt that. Thus
 either your configuration has non-trivial differences you're not
 reporting, or you're reaching a different MySQL.  Debug your NAT
 or cluster config.

 Hi Victor

 The error message is 99.999% not from mysql. Because when I remove the
 backticks around the table name then I get an error from mysql which
 looks different
 When the same Postfix on different systems produces different
 results, then the difference is not Postfix, one would expect that
 that should be clear by now.

 Please use systematic elimination instead of wasting everyone's
 time with guesswork. Reproduce the problem configuration on other
 machines, one step at a time. Eventually you will find what part
 of your configuration is in error.

   Wietse
That's exactly the problem: I cannot reproduce this error on the two
other systems. I really tried hard to
If I look at this error message from postfix

postmap: warning: mysql query failed: Table 'postfix.blacklist-cidr'
doesn't exist

then I see that the table name in the error message is not as configured
in the cnf file.
The cnf file defines the name as `blacklist-cidr` but the error shows no
backticks. And without backticks the table cannot be found because of
the - sign in the name


postmap: warning: mysql query failed: You have an error in your SQL
syntax; check the manual that corresponds to your MySQL server version
for the right syntax to use near '-cidr WHERE inet_aton('192.167.34.21')
BETWEEN `network` AND `broadcast`' at line 1

this error shows up when I do not use backticks in the cnf file.

Sorry for wasting everyone's time. Probably better to rename the table
without - so no backticks are necessary. Other tables in the same
database but without - in their names work perfect from the server in
question.

tobi

Re: Postfix 2.9.6-2 on debian wheezy with a mysql problem?

[Tobi]

Am 08.11.2013 16:18, schrieb Viktor Dukhovni:
 On Fri, Nov 08, 2013 at 03:45:03PM +0100, Tobi wrote:

 The error message is 99.999% not from mysql. Because when I remove the
 backticks around the table name then I get an error from mysql which
 looks different
 That error is also from MySQL.  Postfix does not parse SQL queries,
 the database client and server code do.

 And as this is a cluster based setup it's (imho) not possible that one
 client can see the table and another not
 Databases do have access controls.  And differnt ip:port means NAT
 devices and/or load-balancers in the way, which may be consistently
 connecting you to a different server in the cluster.  In any case:

 Post the output of: 

 $ cat -etv /path/table.cf

hosts = 192.168.200.113$
port = 3308$
user = postfix$
password = X$
dbname = postfix$
query = SELECT 'reject' FROM `blacklist-cidr` WHERE inet_aton('%s')
BETWEEN `network` AND `broadcast`$


 where /path/table.cf is the table config file in question.  Also
 post the output of 

   postmap -v -q 192.0.2.1 mysql:/path/table.cf

postmap -v -q 192.168.2.1 mysql:/etc/postfix/mysql-blacklist.cf
postmap: name_mask: ipv4
postmap: inet_addr_local: configured 5 IPv4 addresses
postmap: cfg_get_str: /etc/postfix/mysql-blacklist.cf: user = postfix
postmap: cfg_get_str: /etc/postfix/mysql-blacklist.cf: password = london21
postmap: cfg_get_str: /etc/postfix/mysql-blacklist.cf: dbname = postfix
postmap: cfg_get_str: /etc/postfix/mysql-blacklist.cf: result_format = %s
postmap: cfg_get_int: /etc/postfix/mysql-blacklist.cf: expansion_limit = 0
postmap: cfg_get_str: /etc/postfix/mysql-blacklist.cf: query = SELECT
'reject' FROM `blacklist-cidr` WHERE inet_aton('%s') BETWEEN `network`
AND `broadcast`
postmap: cfg_get_str: /etc/postfix/mysql-blacklist.cf: domain =
postmap: cfg_get_str: /etc/postfix/mysql-blacklist.cf: hosts =
192.168.200.113
postmap: dict_open: mysql:/etc/postfix/mysql-blacklist.cf
postmap: dict_mysql_get_active: attempting to connect to host
192.168.200.113
postmap: dict_mysql: successful connection to host 192.168.200.113
postmap: warning: mysql query failed: Table 'postfix.blacklist-cidr'
doesn't exist
postmap: fatal: table mysql:/etc/postfix/mysql-blacklist.cf: query
error: Success


 showing the database parameters and query (feel free to hide the
 password value).  Also post the exact same query typed into the
 mysql command-line interpreter.
mysql -upostfix -pX -h 192.168.200.113 -P 3308
mysql use postfix
Database changed
mysql SELECT 'reject' FROM `blacklist-cidr` WHERE
inet_aton('192.168.2.1') BETWEEN `network` AND `broadcast`;
Empty set (0.08 sec)


 Do make sure the username and password sent by postmap are
 IDENTICAL to the username and password you specify interactively.
 Table access permissions may depend on the user login.

 Anyway, this is really not a Postfix issue.  Don't blame the
 messenger, Postfix just prints the errors reported by the MySQL
 library.  You really must treat this as you would any other problem
 with a MySQL application, check the login settings, query settings,
 ...

Think I found it :-) I stated port = 3308 which seems wrong. After
stating hosts = 192.168.200.113:3308 it works
Thanks Victor for putting me in the right way. I just found out when
getting the output you requested

So case closed: error reason 30cm in front of the screen
Sorry for blaming postfix :-)

tobi

Postfix 2.9.6-2 on debian wheezy with a mysql problem?

[Tobi]

Hi list

I really got a weird problem with one of my postfix installations and 
the mysql lookup. The weird thing is that it works on two of my three 
postfix installtions.

Have the following .cnf file for the mysql lookup


hosts = 192.168.200.113
port = 3308
user = postfix
password = XX
dbname = postfix
query = SELECT 'reject' FROM `blacklist-cidr` WHERE inet_aton('%s') 
BETWEEN `network` AND `broadcast`


port is correct for sure ;-)
When I try with postmap -q I get the following error


postmap -q '192.167.34.21' mysql:/etc/postfix/mysql-blacklist.cf
postmap: warning: mysql query failed: Table 'postfix.blacklist-cidr' 
doesn't exist
postmap: fatal: table mysql:/etc/postfix/mysql-blacklist.cf: query 
error: Success



The same cnf file works like charm on the two other servers which are 
debian with the same postfix version too.
When I connect manually from the mailserver with mysql command and fire 
the query it works as well.



mysql -upostfix -pXX -h 192.168.200.113 -P 3308
mysql use postfix
Database changed
mysql SELECT 'reject' FROM `blacklist-cidr` WHERE 
inet_aton('192.167.34.21') BETWEEN `network` AND `broadcast`;

Empty set (0.12 sec)


I know I could rename the table which I would do for sure if the problem 
would have shown up on all of my servers :-)
It seems that on the affected server the backtick is handled differently 
by postfix from the two others.


tobi

Re: Postfix 2.9.6-2 on debian wheezy with a mysql problem?

[Tobi]

Am 07.11.2013 23:02, schrieb Wietse Venema:

Tobi:

Hi list

I really got a weird problem with one of my postfix installations and
the mysql lookup. The weird thing is that it works on two of my three
postfix installtions.
Have the following .cnf file for the mysql lookup



Copy the same config file to different machines and try:

$ postmap -q '192.167.34.21' mysql:/path/to/config-file

Are the results different?

Yes they are. On the two other machines the file works


root@mail1:~# postmap -q '192.167.34.21' mysql:/etc/postfix/mysql-test.cnf
root@mail1:~#

On the two other servers the ip/port is different, but mysql is a 
ndb-cluster so the same tables/records


tobi

Re: Postfix 2.9.6-2 on debian wheezy with a mysql problem?

[Tobi]

Am 07.11.2013 23:26, schrieb Viktor Dukhovni:

On Thu, Nov 07, 2013 at 11:21:15PM +0100, Tobi wrote:


Copy the *SAME* config file to different machines and try:

$ postmap -q '192.167.34.21' mysql:/path/to/config-file

Are the results different?

Yes they are. On the two other machines the file works

root@mail1:~# postmap -q '192.167.34.21' mysql:/etc/postfix/mysql-test.cnf

On the two other servers the ip/port is different, but mysql is a
ndb-cluster so the same tables/records

If the ip/port are different, it is not the *SAME* configuration.
I know but it's not possible otherwise. The two other server reach the 
mysql-cluster via other ips/ports.

Don't run the tests as root, run the tests as a non-privileged user
(with read access to the configuration file).

for my error it makes no difference which user I use. I tried several 
users beside root on the two other servers and it works. But on the 
third one regardless of the user I have this error.



tobi

Re: Recipient rewrite based on sender

[Tobi]

Am 04.09.2013 21:01, schrieb Wietse Venema:
 Tobi:
 Hello list,

 I have been asked if the following is possible somehow with postfix, but 
 as I'm quite unsure I try to ask the gurus :-)
 The goal is something like a conditional recipient rewrite. The 
 condition would be the envelope sender.
 Like: if sender is XXX rewrite the recipient to YYY but only if original 
 recipient is ZZZ.
 The only way I see so far would be to use a postfix pipe to handover all 
 mails from defined sender to a script that does check the conditions for 
 recipient rewrite. But with the downsize that every mail from this 
 sender has to be piped through that script. Even those that would not 
 have met the conditions for rewrite.

 Is there a way to achieve this without piping to an external script?
 I presented an example recently (one week ago) in the thread titled
 recipient rewrite when sender != , including the limitations
 of that approach. You're welcome to adapt it.

 Sometimes I think that these questions are part of a distributed
 denial of service attack.

   Wietse
Hi Wietse

sorry for not using the search :-) Thought I'm the first one with such a
question
I found the other thread you mentioned and I will try what I can do with
it today after working

Thanks for the reply and I'm not part of a DDos :-)

tobi

Recipient rewrite based on sender

[Tobi]

Hello list,

I have been asked if the following is possible somehow with postfix, but 
as I'm quite unsure I try to ask the gurus :-)
The goal is something like a conditional recipient rewrite. The 
condition would be the envelope sender.
Like: if sender is XXX rewrite the recipient to YYY but only if original 
recipient is ZZZ.
The only way I see so far would be to use a postfix pipe to handover all 
mails from defined sender to a script that does check the conditions for 
recipient rewrite. But with the downsize that every mail from this 
sender has to be piped through that script. Even those that would not 
have met the conditions for rewrite.


Is there a way to achieve this without piping to an external script?

thanks for any idea

tobi

Re: Find overquota mailboxes

[tobi]

Am 18.08.2012 21:07, schrieb Wietse Venema:
 This misses all the users that are over quota but did not get mail.
 
 What about parsing du output? This way you can find out all users
 that are over quota.
 
As usual you propose the best solution ;-) I will keep the idea with
du in mind, but as our main concern is to end up on backscatter
blacklists, it's imho enough to only list overquota accounts which
actually receive mails.
We have rumours in the company that this postfix will be replaced in
near future, so I do not want to invest too much time ;-) Other postfix
servers were already replaced by atmail, which I personally not really
like ;-)
 
 Safer:
 postmap /etc/postfix/overquota.new  mv /etc/postfix/overquota.new.db 
 /etc/postfix/overquota.db
 
Thanks for that I will change it tomorrow.

Cheers

tobi

Find overquota mailboxes

[tobi]

Hello list

I need your experience here to see if my solution is good or bad :-)
Background:
We have a postfix setup which can only check users quota after postfix
accepted the message. As you can imagine we produce a lot of
backscatter. Until now the procedure was to manually check mailq and
delete mails from well-known users which never clean up their
mailboxes (do not blame me about that, I just started to work there 4
weeks ago ;-) )
So I thought that must be solved somehow easier and more automatically.
My basic idea is to regularly scan the mailq for mails defered by
overquota. From these mails in queue I fetch the recipients and add
them to a recipient-restriction file for postfix. So postfix can reject
such mails before the queue.

snip
#!/bin/bash
LIMIT=10
TFILE=$(mktemp)
mailq | tail -n +2| awk 'BEGIN {RS = } /over quota/ {print $NF}' |
grep -v maildrop: | sort -n | uniq -c | sort -nr | awk '{if($1
'$LIMIT') print $2}'  $TFILE

while read line ; do
 echo $line 550 Account $line is overquota and cannot receive mails 
/root/overquota
done $TFILE
cp -f /root/overquota /etc/postfix/
postmap /etc/postfix/overquota
postfix reload
/snip

The overquota is in main.cf as check_recipient_access
hash:/etc/postfix/overquota within the smtpd_recipient_restrictions.

Is it save to do something like the above? Especially could it somehow
happen that my mailq... line matches something wrong? My main concern is
to write something wrong in the overquota file and break postfix (like
rejecting everything or something similar)

Thanks for any hints and enjoy the weekend

tobi

Re: Best way to protect backup-mx?

[tobi]

Thanks for this very plausible reason for not doing what I wanted :-) I
did not think about such circumstances.

Cheers

tobi

Am 07.08.2012 22:25, schrieb Reindl Harald:
 
 be carfeul with such things
 
 that you primary MX is up from the connection of your
 backup-MX means virtually nothing because this does
 not mean it is also from the route the delivering MTA
 takes
 
 i have a practical example where i would 100% say it is
 impossible if someone tells me the same:
 
 * Class C IP-Range
 * two IP-Addresses on the same server
 * one customer with a website on both ip-addresses
 * customer has one www-domain and another domain with ip-based SSL host
 
 our ISP had terrible routing problems from and to all sort of
 networks over some hours caused by a dying core-router
 
 my customer was sitting in his office on the same machine and
 was able to connect to 91.118.73.6 without any problem while
 he could not connect to 91.118.73.7 from the same machine while
 other customers could even not connect to 91.118.73.6
 
 so we had
 
 * the same client
 * the same network hardware on the client side
 * the same ISP on the client side
 * the same ISp on oour side
 * the same route
 * the same network hardware on our side
 * even the same physical server on our side
 * after ISP has solved his troubles all went to normal operations
 
 so nobody can explain me how this was possible
 but this shows me that make the decision my primary MX is up
 is finally danherous and says virtually nothing if he is
 up for any incoming connect from somewhere else and if the
 primary MX is down from the delivering MTA he is absolutely
 right to try the backup-MX!
 
 

Re: Best way to protect backup-mx?

[tobi]

Am 07.08.2012 22:40, schrieb Ansgar Wiechers:
 
 Why do you consider this a problem? Your backup MX should neither accept
 nor allow anything the primary MX wouldn't.
 
Actually I do not consider this a real problem My setups on my
backup-mx are as identical as possible to my main-mx. It's just annoying
if spammers try my backups first but not a real problem ;-)
Anyway because of the example that Harald sent I throw my idea over board
Thanks and cheers

tobi

Best way to protect backup-mx?

[tobi]

Hi list,

I'm currently doing some brainstorming on how to protect backup-mx
servers from being directly contacted by clients. I found that
postscreen can do this, but as far as I read only if the backup runs on
the same machine.
Another idea that came in my mind is that the backup-mx checks the
postgrey status of the main-mx and rejects clients that have no record
in master's postgrey. But this seems for me not very accurate. The only
clear case would be if postgrey has no record for the client or does not
answer at all because the entire server is down/having problems. But how
to react on backup if the client has a record in masters postgrey?
Or one could write a script for backup-mx that upon receiving mail tries
to contact master and check if a testmail could be sent. If the testmail
could be sent to master, then drop  the connection from client on backup
Somehow I have no idea what the best approach would be.

Thanks a lot for any input/hints/tips

tobi

Re: Best way to protect backup-mx?

[tobi]

Am 07.08.2012 20:04, schrieb Stan Hoeppner:
 The first thing you need to do is define for us what protect
 backup-mx servers means.  What, exactly, do you want to protect
 them from?
 

Sorry if my intention was only clear to myself ;-)
I want to prevent clients from connecting my backup-mx as long as the
main-mx is up and running. Like spammers sometimes try by connecting
directly to a backup-mx instead trying main-mx first.

tobi

Custom error msg

[tobi]

Hi list

I have a question concerning a custome error msg when using a helo_check
In helo_check I have the following line:

/^[0-9\.]+$/ 550 Not a valid helo name

now I want to allow some trustworth hosts to be allowed to send such a
helo. So I put the sending system in mynetworks parameter and in helo_check

/^[0-9\.]+$/ permit_mynetworks, 550 Not a valid hostname

but this leads to an error from postfix. So my question is: Is it
possible to mix built in policies with custom error messages?
For the moment I have

/^[0-9\.]+$/ permit_mynetworks, reject

which works but I really would like to send customized error messages.

Thanks a lot for any hint

tobi

Re: Custom error msg

[tobi]

Am 11.06.2012 13:17, schrieb DTNX Postmaster:

Also, since it seems you are trying to block the use of address
literals; the use of these is perfectly valid according to spec, so it
may be a good idea to adjust your message somewhat, and explain;

/^\[.*\]$/
 REJECT address literals not accepted from non-client hosts
I always thought in helo_name a fqdn has to be provided according to 
spec. This check is not for recipient or sender but just for the helo 
name the client sends.


But thanks for putting my on the right track. I just created a cidr map 
with client ips which should not be helo checked. I put this map before 
my helo checks and it works fine


tobi

Logging of users trying auth on auth-disabled port?

[tobi]

Hi list

I have disabled SMTP-Auth on my port 25. so this port is only uses to
receive emails for my domains but no relaying is possible. Now I have
bots that try to auth on port 25 by issue

Out: 250 DSN
In:  AUTH LOGIN
Out: 503 5.5.1 Error: authentication not enabled

the problem is that I cannot find a unique line for this in the logs.
Mostly it's stated connection lost in the logs but nothing like auth
tried but disabled
Is there any way to produce a unique logline under such circumstances? I
need to match these cases because I want to block such clients after X
tries for auth on said port

Thanks for any hints

tobi

Re: Logging of users trying auth on auth-disabled port?

[tobi]

On 25.04.2012 13:13, Wietse Venema wrote:

tobi:

Hi list

I have disabled SMTP-Auth on my port 25. so this port is only uses to
receive emails for my domains but no relaying is possible. Now I have
bots that try to auth on port 25 by issue

Out: 250 DSN
In:  AUTH LOGIN
Out: 503 5.5.1 Error: authentication not enabled

the problem is that I cannot find a unique line for this in the logs.

Postfix does not log invalid commands. That would allow a
denial-of-service on the maillog file.

Wietse
imho it's not an invalid command but a disabled one ;-) I agree 
invalid commands should not be logged, but disabled commands?
So if I want to catch such bots the only way would be activate smtp-auth 
again and then scan for failed logs?
Would it not be a solution for postfix to log a line like 
xxx.xxx.xxx.xxx sent disabled command (auth). Would there be a risk 
for dos on the maillog too?


tobi

Re: Logging of users trying auth on auth-disabled port?

[tobi]

On 25.04.2012 17:31, Wietse Venema wrote:
Logging every command is a great way to spam the logfile with random 
junk.


Maybe my subject was misleading. I do not need the content of the 
command. I would just like to find a way to get a line like from 
xxx.xxx.xxx.xxx Error: authentication not enabled in the logs. Thats 
the same message a client receives during smtp-talk if it tries auth 
login on auth disabled port.
If there really is no way then I will activate auth again and scan the 
logs for brute force on logins. I want the ips of those bastards who 
always try auth logins ;-)


tobi

cidr map for a certain receiver address only?

[tobi]

Hello list

I wonder if it's somehow possible to block client ips from a cidr map 
for a certain receiver address only. I have some addresses for which I 
do not want clients from certain providers to send mail to. With a cidr 
map in smtpd_client_restrictions I affect all addresses on my server, 
which is not my intention ;-)
Would it be possible to define this via a postfix policy or something 
similar? My goal would be to get a cidr map that would only be used when 
certain receiver addresses occur during smtp dialog.


Thanks for any hint

tobi

Re: cidr map for a certain receiver address only?

[tobi]

On 09.04.2012 15:19, /dev/rob0 wrote:

On Mon, Apr 09, 2012 at 02:23:14PM +0200, tobi wrote:

I wonder if it's somehow possible to block client ips from a cidr
map for a certain receiver address only. I have some addresses for
which I do not want clients from certain providers to send mail to.
With a cidr map in smtpd_client_restrictions I affect all addresses
on my server, which is not my intention ;-) Would it be possible to
define this via a postfix policy or something similar? My goal
would be to get a cidr map that would only be used when certain
receiver addresses occur during smtp dialog.

Use a restriction class called from a check_recipient_access lookup,
which then does your check_client_access cidr: lookup.

Thanks for putting me into the right direction. that works perfect :-)

Re: Permission for delivered messages.

[tobi]

On 19.10.2011 18:49, Simone Piccardi wrote:

Hi,

I'm trying to deliver some messages to a Public IMAP directory 
(Public in the dovecot namespace meaning).


I tried to use virtual to do this, I created a virtual domain 
shared.folders and then used a virtual_mailbox_maps to define a 
mapping between an address like someaddress@shared.folders to a 
specific shared folder.


I could deliver the messages sent to someaddress@shared.folders to a 
/var/mail/public/.somefolder Maildir, but they were all created with 
permission 0600, so they cannot be read by different users.


I cannot find any option to setup an umask for delivered message 
creation, so I'm asking if there is a way to do this or it's just 
impossible.


Regards
Simone
I'm not sure if there is an option in dovecot to change the chmod of the 
mail files. But you could use virtual Users on dovecot. Then the local 
user always remains the same and it's fine with chmod 0600.  Have a look 
here http://wiki2.dovecot.org/VirtualUsers if virtual users are an 
option for you


tobi

Re: Using Spamassassin as content filter

[tobi]

On 19.10.2011 21:00, Tom Hendrikx wrote:

On 19-10-11 18:54, Daniele Nicolodi wrote:

On 19/10/11 18:46, Tom Hendrikx wrote:

Actually, there is an experimental extension for dovecot sieve that
allows piping to external commands, but with a quite secure design
(sysadmin controls which commands are available to the pipe extension).
It works quite nice in the current state, and will probably be included
some day by the dovecot sieve implementation.

See http://wiki2.dovecot.org/Pigeonhole/Sieve/Plugins/Pipe

Nice to know.


You'd still be better off feeding messages to SA from the MTA, and let
sieve just move messages around based on added headers.

I agree and that's exactly my current solution, but I have some
questions regarding how I'm doing that. Without repeating myself, can
you please have a look at my configuration in the mail that originated
this thread and comment on my solution?

I don't use SA myself so I have no experience with integrating it with
postfix, but some slacking around on the spamasasin website led me to
http://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix, whose
first lines clearly mention the flaws you're system will run into
(generate backscatter, for instance)

My previous attempts in setting up a mailsystem that uses all kinds of
bells and whistles, but also tries to do everything on the smallest
scale possible (such as running content filters under system user
accounts), always failed miserable. In the end I implemented an
ISP-style setup even though my setup is only used by three persons and a
cat. I suggest you try the spampd or the amavisd-new approach.

--
Regards,
Tom
For me a very smooth way to integrate spamassassin into postfix is via 
spamass-milter. An advantage of milter is that it can access the body of 
a mail before the server sends the accept to the  client. It possible to 
deny messages based on score during the smtp session and the job of 
creating a bounce is on the sending side :-)
I use spamass-milter on two postfix servers running on debian-squeeze. 
Works really very nice


tobi

Conditional use of smtp_fallback_relay?

[tobi]

Hello,

is it somehow possible to tell postfix in which error cases the 
smtp_fallback_relay should be used? I'm trying to find a way to seperate 
real rejects from temporary errors. I want my postfix to use the 
fallback only if a reject occured and not if a temporary error (like 
from greylisting) happend. In the later case the mails should go to the 
queue and no fallback should be used.

Anyway to achieve this?
Thanks for any hints and tipps

tobi

Re: Added a Check - Asking for a Review

[tobi]

Carlos Williams schrieb:
 On Wed, Jan 20, 2010 at 10:34 AM, Ralf Hildebrandt
 ralf.hildebra...@charite.de wrote:
 I would merge:

 smtpd_helo_restrictions = permit_mynetworks,
 permit_sasl_authenticated,reject_non_fqdn_helo_hostname,
 reject_invalid_helo_hostname

 smtpd_recipient_restrictions = permit_mynetworks,
 permit_sasl_authenticated,   reject_unauth_pipelining,
 reject_non_fqdn_recipient,   reject_unknown_recipient_domain,
 reject_unauth_destination,   reject_unlisted_recipient,
 check_policy_service unix:postgrey/socket,   check_sender_access
  hash:/etc/postfix/sender_access,
  check_helo_access   pcre:/etc/postfix/helo_checks.pcre,
  reject_rbl_client zen.spamhaus.org,   reject_rbl_client bl.spamcop.net

 into:
 
 Thank you very much for your merge suggestion. I am reading your book
 right now (page 70-72) and trying to understand the concept are the
 merge suggestion. Would you mind explaining what benefit / performance
 is attributed by merging all?
 
 Are you suggestion I leave 'smtpd_helo_restrictions =' blank on my
 main.cf or should I omit that completely since there are no variables
 for this trigger?
 
 Thank you so much for your time and assistance!

For me it makes only sense to have seperate smtpd_helo and
smtp_recipient restrictions if you set smtpd_delay_reject to no. If set
yes the check will anyway be performed only when RCPT TO command is
received.
Furthermore at the time of HELO there is no SASL auth done yet. So this
setting does nothing there.
@Ralf
would it not make more sense to place check_sender_access before the
check_policy_service? Otherwise you might greylist senders you don't
want (like maillists)

Regards

tobi

Re: always get 450 for non-existent domain

[tobi]

Am 19.12.2009 16:30, schrieb D G Teed:
 On Sat, Dec 19, 2009 at 10:40 AM, John Peach post...@johnpeach.com wrote:

   
 On Sat, 19 Dec 2009 04:40:02 -0400
 D G Teed donald.t...@gmail.com wrote:

 [snip]

 
 Due to the hardwired default of 450, all sent mail becomes sluggish
 on the Exchange queue as hundreds of messages are retried
 every few minutes (one mistyped domain in a mail list triggers this
 behaviour in MS Exchange).
   
 Fix the problem, then.

 Hint - the problem is exchange, not postfix.

 
 I'm not the exchange admin and I know little about it.
 I don't know if it retries every 5 minutes or 30 minutes.
 It doesn't matter.  What matters is that email is
 massively slowed down for delivery out of exchange.
 I think I heard someone say the messages actually
 double in the Exchange queue, but that could be
 momentary.

 If we could cause the message to be rejected and bounced back
 to the sender at the Postfix end, it would resolve the problem.

 Usually Postfix has lots of flexibility in handling different scenarios
 but I guess not this time.

 --Donald

   
I don't know if this might help you but in the manual I found this
parameter which should be working from Postfix 2.6 onwards
http://www.postfix.org/postconf.5.html#unknown_address_tempfail_action

Regards

tobi

Re: relayhost and sending some mail directly?

[tobi]

Am 19.12.2009 00:07, schrieb Dasza Seyda:
 If I add a relayhost to main.cf:

 relayhost = relayhost.example.com

 all main will be delivered through relayhost.example.com.



 Now, I would like to deliver mail i.e. for @mylocaldomain directly,
 not through relayhost - how should I do it?

 I tried sender_dependent_relayhost_maps, but I'm not sure what syntax
 I should use if I would like to deliver mail directly for some senders.



If you set mylocaldomain in mydestination or virtual_mailbox_domains of
your main.cf then Postfix should not relay the mail. If you want that
Postfix smtp client sends emails based on sender to different relay
servers then http://www.postfix.org/SASL_README.html would be something
for you

Cheers

tobi

Re: postfix address rewritting

[tobi]

Castagnet Adrien schrieb:
 Hi tobi,
 thank you for your reply.
 In my main.cf
 I uncommented a line mydestination, it's now like this :
 mydestination = $myhostname, localhost.$mydomain, localhost
   
So then $myhostname must be your domain name (mydomain.local) or it wont
work
mydestination defines all the targets (domains or hosts) for which
Postfix is the final station. Emails sent to mydestination will never be
forwarded to an external server.

Just put your local domain name at the line with mydestination and don't
forget to postfix reload.
Then it should work as you want (at least it should as far as my
understanding of Postfix is correct) :-)

Cheers

tobi

Re: postfix address rewritting

[tobi]

Adripop schrieb:

Hi everybody !

Could someone help me, i've been searching everywhere around without 
results.


Almost every local email account has its own email account provided by 
an email provider. I use fetchmail to retreive them and store them 
locally on my server. This configuration permits me to have only one 
account to configure for both local mails and internet mails on the 
client email software.
Although everything working, it's not really what i want, because when 
mails are sent to local users, there are always sent with my email 
provider smtp server and rewrite by postfix and i'd like them to be 
sent through the postfix locally, thus without any email address 
rewritting. 

When i email to someone in my domain like john...@mydomain.local 
mailto:john...@mydomain.local  it's always sent with the address : 
john...@mymailprovider.org mailto:john...@mymailprovider.org.

I've set up a generic rule in /etc/postfix/generic like this :

ad...@mydomain.local mailto:ad...@mydomain.local 
ad...@mymailprovider.org mailto:ad...@mymailprovider.org
john...@mydomain.local mailto:john...@mydomain.local 
john...@mymailprovider.org mailto:john...@mymailprovider.org



I would like to rewrite only the emails going outside my local domain, 
so don't rewrite the mails send to local domain users.

For example :
ad...@mydomain.loca mailto:ad...@mydomain.local to a...@aa.com 
mailto:a...@aa.com should be rewrite as ad...@mymailprovider.org 
mailto:ad...@mymailprovider.org to a...@aa.com mailto:a...@aa.com

and when it's for local sender :
ad...@mydomain.loca mailto:ad...@mydomain.local 
to joh...@mydomain.loca mailto:joh...@mydomain.local should not be 
rewrite




Thanks everyone for reading and helping 
Have a nice day !

Do you  really have mydomain.local set in mydestination in main.cf?

Re: Should Anyone Be Able To Send Telnet Email

[tobi]

Carlos Williams schrieb:
 On Fri, Dec 4, 2009 at 2:22 PM, Matt Hayes domin...@slackadelic.com wrote:
   
 The question is, are you trying to 'relay' through the server or sending
 to a domain that the server hosts?

 -Matt
 

 I don't know how to answer this. The Postfix server is on the same
 network as the clients connecting to it. The clients simply connect to
 the server on the same subnet / domain. It just seems that anyone can
 log in as anybody and send mail on their behalf. This appears bad to
 me...
   
Have a look at http://www.postfix.org/SASL_README.html
Only allow authenticated users to relay through your Postfix Server and
set mynetworks on a local IP like 127.0.0.1

Cheers

tobi

Something like address based relay just the other way around

[Tobi]

Hello

I just wonder whether my idea is technically possible to fullfill with
Postfix. I already use sender based relaying which works fine.
My problem is that I'm running a Postfix Server on my dynamic IP-Address. I
would say for 80% of the receivers is no problem to send the emails
directly (direct-mx). Some domains or receivers do not accept this due to
dynamic IP block. No problem I thought I could set up a receiver-based
relay, but unfortunatly I did not find anything about it in Postfix doc
(maybe I looked for the wrong keywords).
So my question is: Is there a way to conditionally relay emails based on
the receivers address/domain? So I could send emails for defined
addresses/domains via my ISP mailserver instead of direct-mx.
Is there a way to do this in Postfix?

Thanks a lot for all tipps/hints
Cheers

tobi

Re: Something like address based relay just the other way around

[tobi]

Wietse Venema schrieb:
 Tobi:
   
 Hello

 I just wonder whether my idea is technically possible to fullfill with
 Postfix. I already use sender based relaying which works fine.
 My problem is that I'm running a Postfix Server on my dynamic IP-Address. I
 would say for 80% of the receivers is no problem to send the emails
 directly (direct-mx). Some domains or receivers do not accept this due to
 dynamic IP block. No problem I thought I could set up a receiver-based
 relay, but unfortunatly I did not find anything about it in Postfix doc
 (maybe I looked for the wrong keywords).
 

 See this URL: http://www.postfix.org/transport.5.html 

 If I am not mistaken, this has precedence over sender-dependent features.

   Wietse

   
 So my question is: Is there a way to conditionally relay emails based on
 the receivers address/domain? So I could send emails for defined
 addresses/domains via my ISP mailserver instead of direct-mx.
 Is there a way to do this in Postfix?

 Thanks a lot for all tipps/hints
 Cheers

 tobi


 

   
Hello

I tried according to Wietse's link to the manual and it works 50% ;-)
The email is properly forwarded according to receivers domain with the
values in transport conf file
But now Postfix has no user details to perform a SMTP Authentication at
the defined relay server. smtp tries to relay without auth which my
providers server don't like. If I'm using sender_dependent_relay then
smtp takes the details from my sasl password file and therefore can
perform an auth at the relay server.
So my next question is how to tell transport where to lookup for the
login credentials to send an email through an external relay server
which expects user auth.

Is there a way which I have not found in the manual to tell Postfix the
necessary details? Or is it not possible by design?

Thanks and cheers

tobi

Re: Something like address based relay just the other way around

[tobi]

Wietse Venema schrieb:
 tobi:
 [ Charset ISO-8859-1 unsupported, converting... ]
   
 Wietse Venema schrieb:
 
 Tobi:
   
   
 Hello

 I just wonder whether my idea is technically possible to fullfill with
 Postfix. I already use sender based relaying which works fine.
 My problem is that I'm running a Postfix Server on my dynamic IP-Address. I
 would say for 80% of the receivers is no problem to send the emails
 directly (direct-mx). Some domains or receivers do not accept this due to
 dynamic IP block. No problem I thought I could set up a receiver-based
 relay, but unfortunatly I did not find anything about it in Postfix doc
 (maybe I looked for the wrong keywords).
 
 See this URL: http://www.postfix.org/transport.5.html 

 If I am not mistaken, this has precedence over sender-dependent features.
   
 I tried according to Wietse's link to the manual and it works 50% ;-)
 The email is properly forwarded according to receivers domain with the
 values in transport conf file
 But now Postfix has no user details to perform a SMTP Authentication at
 the defined relay server. smtp tries to relay without auth which my
 providers server don't like. If I'm using sender_dependent_relay then
 

 Then you made too many transport map entries.

   Wietse

   
Thanks for your patience :-)
But I only have two entries in transport which look like this

cat /opt/etc/postfix/transport | grep -v #
postfix.org smtp:[smtp.mysip.ch]:587
domain.tld smtp:[smtp.myotherisp.ch]:587

And only once in the config (main.cf transport_maps...).
I can see the unauthorized relay attempts with myisp.ch/myotherisp.ch in
the Postfix logs. So I assume that no login credentials were used. Is
transport meant to use the data from sender_relay and sasl_passwd files
to login to the relay servers?

Regards

tobi

Re: Something like address based relay just the other way around

[tobi]

tobi schrieb:
 Wietse Venema schrieb:
   
 tobi:
 [ Charset ISO-8859-1 unsupported, converting... ]
   
 
 Wietse Venema schrieb:
 
   
 Tobi:
   
   
 
 Hello

 I just wonder whether my idea is technically possible to fullfill with
 Postfix. I already use sender based relaying which works fine.
 My problem is that I'm running a Postfix Server on my dynamic IP-Address. 
 I
 would say for 80% of the receivers is no problem to send the emails
 directly (direct-mx). Some domains or receivers do not accept this due to
 dynamic IP block. No problem I thought I could set up a receiver-based
 relay, but unfortunatly I did not find anything about it in Postfix doc
 (maybe I looked for the wrong keywords).
 
   
 See this URL: http://www.postfix.org/transport.5.html 

 If I am not mistaken, this has precedence over sender-dependent features.
   
 
 I tried according to Wietse's link to the manual and it works 50% ;-)
 The email is properly forwarded according to receivers domain with the
 values in transport conf file
 But now Postfix has no user details to perform a SMTP Authentication at
 the defined relay server. smtp tries to relay without auth which my
 providers server don't like. If I'm using sender_dependent_relay then
 
   
 Then you made too many transport map entries.

  Wietse

   
 
 Thanks for your patience :-)
 But I only have two entries in transport which look like this

 cat /opt/etc/postfix/transport | grep -v #
 postfix.org smtp:[smtp.mysip.ch]:587
 domain.tld smtp:[smtp.myotherisp.ch]:587

 And only once in the config (main.cf transport_maps...).
 I can see the unauthorized relay attempts with myisp.ch/myotherisp.ch in
 the Postfix logs. So I assume that no login credentials were used. Is
 transport meant to use the data from sender_relay and sasl_passwd files
 to login to the relay servers?

 Regards

 tobi
   
Problem found 30cm in front of the screen.
After changing the transport

postfix.org smtp:[smtp.mysip.ch]:submission
domain.tld smtp:[smtp.myotherisp.ch]:submission

it works. I thought :587 would be the same as :submission

Re: Backscatter being generated from mail aliased to other servers.

[tobi]

Jaroslaw Grzabel schrieb:
 Jim Lang pisze:
 John Peach wrote:
 On Mon, 16 Nov 2009 13:07:05 -0700
 Jim Lang post...@guscreek.com wrote:

  
 John Peach wrote:
   
 On Mon, 16 Nov 2009 13:00:26 -0700
 Jim Lang post...@guscreek.com wrote:

   
 Wietse Venema wrote:
   
 Jim Lang:
 
 OK here is the scenario.  Spammer sends mail to:
 u...@myclientsdomain.com from forged
 address vic...@randomdomain.com

 If u...@myclientsdomain.com is delivered locally, not a problem,
 if the address is invalid, postix rejects the mail during the
 smtp connection.

 But if u...@myclientsdomain.com is an alias to
 mycli...@otherserver.com, postfix accepts the mail as deliverable
 and forwards it to hotmail.com. But if
 mycli...@otherserver.com  can for whatever reason not be
 delivered, otherserver.com does what it is supposed to do and
 rejects the mail during the smtp connection, which causes postfix
 to send out a non-delivery  report to vic...@randomdomain.com  --
 backscatter.

 Is there a way to stop this? 
 Yes. Don't forward SPAM.

 Wietse
   
 And how do I do that in this scenario?
 
 You use recipient verification.

 
 I must have been really inarticulate when I wrote out the scenario.
 I do use recipient verification on my server.  How is it that that is
 not clear? Do I need to rewrite this post?

 
 Clearly, you are *NOT* doing recipient verification, or
 myotherserver.com would not be rejecting it. Never accept mail which
 cannot be delivered.
   


 Except no 'myotherserver.com' appeared in my scenario,  nimrod.

 otherserver.com in the scenario is a server not under my control.

 unsubcribing to this useless list
 But server which is out of your control should not accept messages for
 example to non-existant user. So if you're doing verification even
 when spammer connects to your server should recieve an ansewer from
 REMOTE SERVER user not known or something similar. I've got similar
 situation as I had to smart host for a lot of domains and connection,
 but let's say I know people on that remote site, or even if not I've
 got any contact details like email addres so simply... I'm trying to
 explain people that if they will not protect the end server I will
 block them in the smart host as I can't take a risk of block. So
 generally you should use  reject_unverified_recipient and additionally
 you can build a database... you can limit connections, check RBLs,
 CBLs, there is really a lot of things but first of all you would need
 to check which hosts on the other end couses a problem and find out
 what you can do more to prevent spam coming through.
 I know that it's impossible to block all SPAM without being too harsh,
 but there is always something what you can do to prevent it.

 Regards,
 Jarek
This page (http://www.postfix.org/ADDRESS_VERIFICATION_README.html)
looks like it describes part of your problem. Could be the solution

Regards

tobi

Mail not delivered to local users: status=deferred (mail transport unavailable)

[Tobi]

Hi All,
I set up an after-queue content filter following the instructions on
http://www.postfix.org/FILTER_README.html .
Everything works fine except that mail directed to local users is
deferred when it is re-injected to postfix after the content filter.
However, virtual and remote addresses work.
I have the trivial-rewrite, qmgr, local, and error daemons running
with the -v switch.
Here is a `grep id mail.log`  for a re-injected mail:

===
postfix/smtpd[22439]: BA9452DA112C: client=localhost[127.0.0.1]
postfix/cleanup[22435]: BA9452DA112C: message-  
id=20090329202930.dc9872da1...@mail.knmm.de

postfix/qmgr[22419]: qmgr_active_feed: incoming/BA9452DA112C
postfix/qmgr[22419]: qmgr_message_alloc: active BA9452DA112C
postfix/qmgr[22419]: BA9452DA112C: recipient limit 5000
postfix/qmgr[22419]: BA9452DA112C: from=a...@mail.knmm.de, size=516,  
nrcpt=1 (queue active)
postfix/qmgr[22419]: qmgr_peer_select: BA9452DA112C retry 4.3.0 mail  
transport unavailable (1 of 5)

postfix/qmgr[22419]: qmgr_job_retire: BA9452DA112C
postfix/qmgr[22419]: send attr queue_id = BA9452DA112C
postfix/error[22442]: BA9452DA112C: to=a...@mail.knmm.de,  
relay=none, delay=0.17, delays=0.02/0.13/0/0.02, dsn=4.3.0,  
status=deferred (mail transport unavailable)

postfix/qmgr[22419]: qmgr_active_done: BA9452DA112C
postfix/qmgr[22419]: wakeup BA9452DA112C after 300 secs
postfix/qmgr[22419]: qmgr_active_defer: defer BA9452DA112C
postfix/qmgr[22419]: qmgr_job_free: BA9452DA112C local
postfix/qmgr[22419]: qmgr_job_free: BA9452DA112C retry
===

Here is my master.cf section for the re-injection smtpd:

===
127.0.0.1:10025 inetn   -   y   -   -   smtpd
 -o content_filter=
 -o local_recipient_maps=
 -o relay_recipient_maps=
 -o mynetworks=127.0.0.0/8
 -o smtpd_restriction_classes=
 -o smtpd_delay_reject=no
 -o smtpd_client_restrictions=permit_mynetworks,reject
 -o smtpd_helo_restrictions=
 -o smtpd_sender_restrictions=
 -o smtpd_recipient_restrictions=permit_mynetworks,reject
 -o smtpd_data_restrictions=reject_unauth_pipelining
 -o smtpd_end_of_data_restrictions=
 -o smtpd_error_sleep_time=0
 -o smtpd_soft_error_limit=1001
 -o smtpd_hard_error_limit=1000
 -o smtpd_client_connection_count_limit=0
 -o smtpd_client_connection_rate_limit=0
 -o smtpd_authorized_xforward_hosts=127.0.0.0/8
 -o
receive_override_options 
=no_address_mappings,no_unknown_recipient_checks,no _header_body_checks

===

The local destination domain is included in mydestination.
My transport map has only one entry for an external domain.
I tried removing the '-o receive_override_options=no_address_mappings'
and '-o local_recipient_maps=', but nothing changed.
I'm out of ideas.

I really appreciate your help.

Thanks,

Tobi 

Re: Mail not delivered to local users: status=deferred (mail transport unavailable)

[Tobi]

On Mar 29, 2009, at 5:10 PM, Wietse Venema wrote:


Tobi:

Hi All,
I set up an after-queue content filter following the instructions on
http://www.postfix.org/FILTER_README.html .
Everything works fine except that mail directed to local users is
deferred when it is re-injected to postfix after the content filter.
However, virtual and remote addresses work.
I have the trivial-rewrite, qmgr, local, and error daemons running
with the -v switch.
Here is a `grep id mail.log`  for a re-injected mail:


Don't turn on verbose logging. You're overwhelming the log
with useless information.

Instead look at all the screams for help that Postfix already logs.

http://www.postfix.org/DEBUG_README.html#logging

Wietse



Wietse,

Thanks much for pointing this out.
It turned out that the problem was caused by:

postfix/local[29798]: fatal: main.cf configuration error:  
mailbox_size_limit is smaller than message_size_limit


My bad.

Many thanks for your support and the great work on postfix!

Tobi