using header_checks for custom transport

2012-03-16 Thread Pim Zandbergen
I am routing all mail for a domain to another SMTP server using the 
transport map rule


adomain.comrelay:other.server

But I would like to exclude mailing lists, and have them processed locally,
using header_checks entries like this:

/^X-Mailing-List:/FILTER local:

Here, local is the transport name, and the destination is empty as 
suggested in the
comments of the header_checks file. But that doesn't work, no filtering 
takes place,

the mail ends up being relaid.

/^X-Mailing-List:/REDIRECT some@address

does work, but I would prefer not to change the address.

Obviously there is a misunderstanding on my part regarding the FILTER syntax
Can I use a FILTER action to do what I want? I'm using Postfix 2.7.5

Thanks,
Pim


Re: using header_checks for custom transport

2012-03-16 Thread Pim Zandbergen

On 16-3-2012 14:18, Viktor Dukhovni wrote:

/^X-Mailing-List:/REDIRECT some@address

DO NOT do this. If a particular recipient wants his list traffic left
a local mailbox, and the rest forwarded, that's up the to user's
LDA, say procmail(1), or similar. This must not be done at the
message level by the MTA which processes mail for multiple
recipients.


I agree, the other SMTP server that receives all the other mail, a popular
commercial groupware product, should handle the mailing list mail as well.
But it does so in an unsatisfying way.

So I need to intercept this mail before it gets handed over to this other
server. Here, local processing means submitting to Cyrus IMAP, and further
filtering by Cyrus' sieve which works much more satisfying than the other
servers' filtering mechanisms.

Pim


Re: relocated_maps feature causing backscatter - SOLVED

2011-12-15 Thread Pim Zandbergen
I found the problem by investigating the address verification traffic 
between
Postfix and Exchange. I noticed Postfix was not verifying recent 
addresses at all

so I figured Postfix must be caching verification results somewhere.

Indeed,  there is a /var/lib/verify_cache.db and it contained the 7 bouncing
addresses as well as the 15 rejecting addresses. But the bouncing ones
appear to have been verified as OK in the past.

Removing the database and restarting Postfix fixed it.

Thanks,
Pim



Re: relocated_maps feature causing backscatter

2011-12-13 Thread Pim Zandbergen



What is the output of:

postconf smtpd_reject_unlisted_recipient

Reason I ask is that the unlisted recipient check also
does the relocated check.

smtpd_reject_unlisted_recipient = no

I have to accept unlisted recipients as there are no local users.
Everything is being relaid to an Exchange server using the transport map,
except for a few addresses delivered locally using LMTP.

Unfortunately, the relocated check will be missed when the
recipient address exists in virtual_alias_maps or in *canonical_maps,
because those can change the address into something else.

Wietse


The opposite seems to be true for me. If I send 22 messages to 
relocated_u...@my-other-domain.nl

all messages are rejected, none are bounced.

In this example, @my-other-domain.nl is mapped to @my-domain.nl in 
canonical_maps.


Pim


Re: relocated_maps feature causing backscatter

2011-12-13 Thread Pim Zandbergen

On 12/12/2011 8:32 PM, Wietse Venema wrote:

What is the output of:

postconf smtpd_reject_unlisted_recipient

Reason I ask is that the unlisted recipient check also
does the relocated check.

Wietse

It might also be relevant that I'm using recipient address verification
against the Exchange server, using

smtp_recipient_restrictions = [ ... ]  reject_unverified_recipient

and in transport:

local_u...@my-domain.nllocal
my-domain.nl   relay:exchangeserver.my-domain.nl


relocated_maps feature causing backscatter

2011-12-12 Thread Pim Zandbergen

I recently started using the relocated_maps feature and now am seeing some
bounce messages to forged addresses in the queue because of that.

It looks like this feature is bouncing rather than rejecting mail.
How can I avoid this?

Thanks,
Pim




Re: relocated_maps feature causing backscatter

2011-12-12 Thread Pim Zandbergen

I'm using postfix 2.7.5.

Some relocated messages are bounced, some are rejected.

It looks like this is the rule:

Messages to recipients that appear to be local users (through winbind in 
my case) are bounced.

Messages to recipients that do not appear to be local are rejected.

This may be relevant:
The mail is sent to a domain listed as $mydomain in $mydestination
Almost all mail for this domain is relaid to an Exchange server using an 
entry in the transport map.


Thanks,
Pim








Re: relocated_maps feature causing backscatter

2011-12-12 Thread Pim Zandbergen
I can't yet reproduce a bounce;  i'm still figuring out under what 
circumstances
a bounce will happen. Just being a local user, like I suggested in my 
previous post

is not enough.

But here is an actual bounce sitting in my queue right now:


-Queue ID- --Size-- Arrival Time -Sender/Recipient---
36DEA664F  3955 Sat Dec 10 03:47:06  MAILER-DAEMON
  (connect to smtp.anbid.com.br[200.186.108.102]:25: Connection 
timed out)

 wattagex...@anbid.com.br

-- 4 Kbytes in 1 Request.

Here is the log of the arrival


/var/log/maillog-20111211:Dec 10 03:47:04 veldhoen postfix/smtpd[2891]: 
AC3E9664A: client=unknown[186.43.37.99]
/var/log/maillog-20111211:Dec 10 03:47:05 veldhoen 
postfix/cleanup[2895]: AC3E9664A: message-id=0uiljy-wdj5a3...@anbid.com.br
/var/log/maillog-20111211:Dec 10 03:47:06 veldhoen postfix/qmgr[8706]: 
AC3E9664A: from=wattagex...@anbid.com.br, size=1198, nrcpt=1 (queue 
active)
/var/log/maillog-20111211:Dec 10 03:47:06 veldhoen postfix/error[2897]: 
AC3E9664A: to=j...@macroscoop.nl, relay=none, delay=1.5, 
delays=1.5/0/0/0.02, dsn=5.1.6, status=bounced (User has moved to 
j.do...@macroscoop.nl)
/var/log/maillog-20111211:Dec 10 03:47:06 veldhoen postfix/bounce[2900]: 
AC3E9664A: sender non-delivery notification: 36DEA664F
/var/log/maillog-20111211:Dec 10 03:47:06 veldhoen postfix/qmgr[8706]: 
AC3E9664A: removed




Here's my postconf -n output, slightly edited; removed some domain names




alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
canonical_maps = hash:/etc/postfix/canonical
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
disable_vrfy_command = yes
header_checks = regexp:/etc/postfix/header_checks
html_directory = no
inet_interfaces = all
inet_protocols = all
local_destination_concurrency_limit = 5
local_destination_recipient_limit = 300
mail_owner = postfix
mailbox_transport = lmtp:inet:imap.macroscoop.nl
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 2048
message_strip_characters = \0
milter_connect_macros = j {daemon_name} v {if_name} _
mydestination = $myhostname, localhost.$mydomain, localhost, [ other 
domains ... ]

myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.7.5/README_FILES
recipient_delimiter = +
relay_domains = $mydestination,
relocated_maps = hash:/etc/postfix/relocated
sample_directory = /usr/share/doc/postfix-2.7.5/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_mx_session_limit = 5
smtpd_banner = $myhostname ESMTP $mail_name ($mail_version)
smtpd_client_restrictions = reject_unauth_pipelining
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks permit_sasl_authenticated 
reject_invalid_helo_hostname reject_non_fqdn_helo_hostname
smtpd_milters = inet:localhost:7357 
unix:/var/run/spamass-milter/postfix/sock inet:localhost:8891 
smtpd_recipient_restrictions = permit_mynetworks 
permit_sasl_authenticated reject_non_fqdn_recipient 
reject_unknown_recipient_domain reject_unauth_destination 
reject_unverified_recipient

smtpd_reject_unlisted_recipient = no
smtpd_sender_restrictions = permit_mynetworks
smtpd_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtpd_tls_cert_file = /etc/pki/tls/certs/postfix.crt
smtpd_tls_key_file = /etc/pki/tls/private/postfix.key
smtpd_tls_security_level = may
transport_maps = hash:/etc/postfix/transport
unknown_address_reject_code = 550
unknown_client_reject_code = 550
unknown_hostname_reject_code = 550
unknown_local_recipient_reject_code = 550
unverified_recipient_reject_code = 550
virtual_alias_domains = [ yet more domains ]
virtual_alias_maps = hash:/etc/postfix/virtual



Re: relocated_maps feature causing backscatter

2011-12-12 Thread Pim Zandbergen

On 12/12/2011 4:48 PM, Wietse Venema wrote:

The network-facing SMTP server is configured not to validate that
recipient, for example, due to explicit whitelisting in an access
map.


The access map contains whitelisted IP addresses only.

I can now reproduce the bouncing. Out of 22 tested recipients in the 
relocated file,

7 consistently bounce, and 15 others consistently reject.

I really can't tell what sets these recipients apart.
All the lines in the relocated file are like

usere.mailaddr...@mydomain.nl

where user is the user's Active Directory account, and 
e.mailaddr...@mydomain.nl
is their proper e-mail address. The Active Directory user accounts may 
be seen as valid

local Unix user ID's, through Samba's winbind.

The bouncing users appear just as valid as the rejecting ones when using 
the id user command.


The user names don't appear anywhere in /etc/postfix/* (except 
relocated), or /etc/aliases or /etc/passwd


I have removed relocated.db, rebuilt it, and restarted postfix just to 
be sure, without effect.


Thanks,
Pim



Re: relocated_maps feature causing backscatter

2011-12-12 Thread Pim Zandbergen

On 12/12/2011 7:47 PM, Wietse Venema wrote:

Pim Zandbergen:

I can now reproduce the bouncing. Out of 22 tested recipients in
the relocated file, 7 consistently bounce, and 15 others consistently
reject.

What do you mean by that: you talked to the Postfix SMTP daemon
from one IP address, sent all 22 addresses in an RCPT TO command,
and 15 of those RCPT TO commands did not receive a REJECT reply?

Wietse
I sent, from one IP address, to the same Postfix SMTP daemon, 22 
separate messages

to single recipients, all in the same domain, all matching a relocated user.

Of 22 messages, 15 were rejected immediately. 7 others were accepted and 
were

returned shortly later.

I repeated this, randomized the order of the messages and got consistent 
results.


Yes, it sounds weird.
The Postfix  SMTP daemon comes as postfix-2.7.5-1.fc14.x86_64 running on 
Fedora 14.


Pim



online reject_unknown_helo_hostname test?

2011-10-10 Thread Pim Zandbergen

For a couple of weeks I have been using reject_unknown_helo_hostname in
my smtpd_helo_restrictions. This has helped to reject some 500 unsolicited
mail messages per day, on a total of around 1500.

Unfortunately, I've had to whitelist some 10 mail servers that are 
misconfigured
but legitimate. I tried to educate each and everyone of their admins. 
Only one

admin changed their system's helo name; their system runs Postfix...

All the other are Exchange servers or MailMarshal admins that keep claiming
it's our problem, because everyone else accepts their mail.

It would help if there were some authoritative online SMTP test server that
would accept mail from misconfigured mail servers and return an analysis.

All the the online SMTP testers I've seen merely test their incoming mail
for open relaying.

Thanks,
Pim



Re: IPv6, backup MX and 4XX deferrals

2011-08-23 Thread Pim Zandbergen


Pim Zandbergen:

Wietse Venema wrote:

I know of no RFC that says only whitelisted clients can send email
over IPv6.


Well, it's their policy. I can respect that, if their assumption that 
senders

should fall back to IPv4 is valid.


2 - Increase smtp_mx_session_limit (default: 2) so that Postfix
 will knock more doors.


I guess that is what made their assumption fail. I've upped this limit 
to 5,

and now my messages are waiting to be unlisted at their greylist on
their backup IPv4-only MX. Looks promising.



After having reported to the ISP to have already fixed the issue in Postfix,
I got a message stating that they have decided to stop rejecting
non-whitelisted IPv6 addresses.

Thanks,
Pim


IPv6, backup MX and 4XX deferrals

2011-08-17 Thread Pim Zandbergen

I cannot send mail to ISP nines.nl nor to their customers.

Nines.nl have three MX hosts:
two at weight 100, with IPv4 and IPv6 addresses
one  at weight 500, IPv4 only

Their primary MX hosts defer all mail sent to their IPv6 address
with 451 Your IPv6 address is not whitelisted at ipv6whitelist.eu.

Postfix never tries to connect to the IPv4 addresses of the
primary MX hosts, and does not fall back to the IPv4-only MX.
Hence the mail stays queued.

Somehow I think Postfix is doing the right thing. But I would
like some backup before I send a complaint.

Thanks,
Pim





Re: IPv6, backup MX and 4XX deferrals

2011-08-17 Thread Pim Zandbergen

Wietse Venema wrote:

I know of no RFC that says only whitelisted clients can send email
over IPv6.


Well, it's their policy. I can respect that, if their assumption that 
senders

should fall back to IPv4 is valid.


2 - Increase smtp_mx_session_limit (default: 2) so that Postfix
 will knock more doors.


I guess that is what made their assumption fail. I've upped this limit to 5,
and now my messages are waiting to be unlisted at their greylist on
their backup IPv4-only MX. Looks promising.

Thanks,
Pim


Re: IPv6, backup MX and 4XX deferrals

2011-08-17 Thread Pim Zandbergen

Wietse Venema wrote:

This policy is mistaken for the following reasons.

Doesn't that make the whole ipv6whitelist.eu initiave mistaken?
Or could there be a correct way to use it?

As a side note: they do explain how to enable their whitelisting in Postfix:
http://www.ipv6whitelist.eu/implementation-instructions/

Pim