Re: too many postfix smtp active internet connections

[Clunk Werclick]

On Tue, 2009-08-04 at 08:12 +0200, Patrick Ben Koetter wrote:
> 
> You need the milter capabilities from Postfix 2.6. Use the
> batv-milter.
> 
> That's all I know at the moment.

I am confused? batv-milter? Is it not pvrs? I see this:

http://sourceforge.net/projects/batv-milter/

The idea looks very credible, and I have seen mails with pvrs= in the
'from' field. I think there is milter support in 2.5.5 (not just 2.6) as
I have a clam milter running myself - but I am not so sure that this
'batv' milter would require something special to 2.6?

-- 
---
C Werclick .Lot
Technical incompetent
Loyal Order Of The Teapot.

This e-mail and its attachments is intended only to be used as an e-mail
and an attachment. Any use of it for other purposes other than as an
e-mail and an attachment will not be covered by any warranty that may or
may not form part of this e-mail and attachment. 

Re: too many postfix smtp active internet connections

[Patrick Ben Koetter]

* Clunk Werclick :
> On Mon, 2009-08-03 at 16:08 -0400, Wietse Venema wrote:
> > Get rid of the backscatter:
> > http://www.postfix.org/BACKSCATTER_README.html
> > 
> > Wietse
> 
> Has anybody implemented something like this with Postfix?
> 
> http://en.wikipedia.org/wiki/Bounce_Address_Tag_Validation
> 
> Any observations or advice?

You need the milter capabilities from Postfix 2.6. Use the batv-milter.

That's all I know at the moment.

p...@rick

-- 
All technical answers asked privately will be automatically answered on
the list and archived for public access unless privacy is explicitely
required and justified.

saslfinger (debugging SMTP AUTH):

Re: too many postfix smtp active internet connections

[Clunk Werclick]

On Mon, 2009-08-03 at 16:08 -0400, Wietse Venema wrote:
> Get rid of the backscatter:
> http://www.postfix.org/BACKSCATTER_README.html
> 
>   Wietse

Has anybody implemented something like this with Postfix?

http://en.wikipedia.org/wiki/Bounce_Address_Tag_Validation

Any observations or advice?

-- 
---
C Werclick .Lot
Technical incompetent
Loyal Order Of The Teapot.

This e-mail and its attachments is intended only to be used as an e-mail
and an attachment. Any use of it for other purposes other than as an
e-mail and an attachment will not be covered by any warranty that may or
may not form part of this e-mail and attachment. 

Re: too many postfix smtp active internet connections

[Clunk Werclick]

On Mon, 2009-08-03 at 16:08 -0400, Wietse Venema wrote:

> Get rid of the backscatter:
> http://www.postfix.org/BACKSCATTER_README.html

Has anybody inplemented something like this with Postfix yet?



-- 
---
C Werclick .Lot
Technical incompetent
Loyal Order Of The Teapot.

This e-mail and its attachments is intended only to be used as an e-mail
and an attachment. Any use of it for other purposes other than as an
e-mail and an attachment will not be covered by any warranty that may or
may not form part of this e-mail and attachment. 

[SOLVED] RE: allow sasl authenticated on submission port and bypass rbl

[Nick Sharp]

> >>
> >> Nick Sharp wrote:
> smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,r
> eject
> > in the submission bit in master.cf, the connect immediately rejects
> unless
> > matching mynetworks, still not giving a chance to do SASL..
> >
> > Any ideas why this would be?
> >
> > The nearest I can get is accept email to my domains with TLS, with or
> > without AUTH, or block you from even negotiating AUTH? There is no
> middle
> > ground it seems (or more I am missing it! :)
> >
> This is because you changed "smtpd_delay_reject = no" from it's default
> to Yes.
> The client is not given a chance to AUTH with this setting.

Ahh Thats he middle ground I was looking for!

Thanks all for your help.

To summarise, this submission config brought on the majic;

submission inet n   -   n   -   -   smtpd
-o smtpd_tls_security_level=may
-o smtpd_sasl_auth_enable=yes
-o smtp_enforce_tls=yes
-o smtp_tls_enforce_peername=yes
-o broken_sasl_auth_clients=yes
-o
receive_override_options=no_header_body_checks,no_address_mappings
-o
smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
-o smtpd_sasl_security_options=noanonymous,noplaintext
-o smtpd_sasl_tls_security_options=noanonymous

Nick

Re: No hash in Solaris 10

[Henrik K]

On Mon, Aug 03, 2009 at 03:38:35PM -0400, Mauricio Tavares wrote:
>
> I thought it would be there since I have db 4.7 installed in the  
> machine. Am I missing something here or just being mistaken as usual? Is  
> it being called something else?

PS. Consider using simple and fast http://www.postfix.org/CDB_README.html
instead and forget the BDB behemoth.

Re: Reverse DNS requirement

[LuKreme]

On 3-Aug-2009, at 15:57, Robert Schetterer wrote:

yes i know many mailling services from big companies
who missed the reverse dns, but its their problem,
after all if they cant get out their mail it should finally bounce to
someone responsable



No, you're still not understanding.

Say you have a ... oh, I dunno, a DHCP server/router that your entire  
office network plugs into. And say it has a feature, as so many do, to  
send alerts via email if say the uplink goes down. Now, that email  
configuration is very primitive, has almost not options, and also  
doesn’t likely have rDNS configured correctly on it.


When the uplink goes down and the emails get rejected, there's no one  
to know.  The human is involved, you just don't get the alert you are  
expecting when you expect it.


Who gets blamed when it's discovered all those emails where never  
delivered? The person in charge of the mailserver.


--
With excitement like this, who is needing enemas?

Re: mynetworks

[LuKreme]

On 3-Aug-2009, at 16:03, AMP Admin wrote:
OH! So when I do it w/o the -d it shows my current config?!  I do  
see mynetworks is correct now w/o the -d!!!


run postconf -n for your settings minus the default. This is generally  
all you care about.


Also, read man postconf

And lastly, don't top post.

--
And the three men I admire most, the father son and the holly ghost
they caught the last train for the coast...

Re: mynetworks

[Sahil Tandon]

On Mon, 03 Aug 2009, AMP Admin wrote:

> OH! So when I do it w/o the -d it shows my current config?!  I do see
> mynetworks is correct now w/o the -d!!!

Yes, read the postconf(1) manual to understand the meaning of '-d' and other
flags.

> Thank you so much... sometimes it's the little things that make us happy.
> I'm obviously new to postfix. :)

Welcome.  Please stop top-posting.  If you are not familiar with this term,
google it.

-- 
Sahil Tandon 

Re: lost my Delivered-To: header

[Sahil Tandon]

On Mon, 03 Aug 2009, Tim Coote wrote:

> I've been a happy user and recommender of postfix for about 8 years now. 

You've been using Postfix long enough to include 'postconf -n' and the other
information as outlined in DEBUG_README. :-)

> For historical reasons, I was using the Delivered-To: header as part of 
> an IMAP Sieve rule. However, I seem to have lost this header in my  
> inbound mail. I'm using Cyrus IMAP as my Message Store and Spambayes as a 
> content filter. Cyrus is driven through LMTP.  I'm using a fedora build 
> of postfix "postfix-2.5.6-1.fc10.i386".  I also have postfix on a 
> firewall (postfix-2.2.11-1.rh8), which I used to use to forward mail to 
> my more current system. However, the firewall MTA now merely forwards to 
> the 'internal' MTA.  I'd guess that the firewall MTA used to prepend the 
> Delivered-To: header, but I haven't been able to check that.
>
> The problem that I have is that I cannot get that Delivered-To: header  
> reinstated. I've changed the smtp entry in master.cf to:
> smtp  inet  n   -   n   -   -   smtpd
>  -o content_filter=spambayes:dummy
>
> and added the spambayes entry:
>
> spambayes unix  -   n   n   -   -   pipe
>  flags=O user=tim argv=/usr/local/bin/sbwrapper.sh ${sender} $ 
> {recipient}
>
> I've added the following to main.cf as recommended:
> spambayes_destination_recipient_limit = 1
>
> Although it doesn't seem to make much difference.
>
> The flags=O in master.cf gives me an X-Originally-To: mail header  
> and there's no 'Delivered-To:' header, but if I change it to  
> flags=D, mail gets bounced by the loop detection code.

The bounce is sensible; you add a Delivered-To: header before the mail is
actually delivered by the appropriate delivery agent, which by design bounces
mail that is destined for f...@bar.org when f...@bar.org already appears in the
Delivered-To:.

> I see from the documentation that some loop detection logic may have  
> changed around version 2.3, but I don't think that the Delivered-To:  
> header was removed. 

The header was not 'removed'; for example, local(8) and virtual(8) still add
the header when delivering mail to intended recipients.

> There's no particular reason for trying to generate the Delivered-To:  
> header through the callout to the content filter, but it seemed an easy 
> place to plug it in.  

It is a bad place to plug it in given the way loop detection works.

> I've tried the debugging suggested, but I cannot see any Delivered-To:  
> header at all.
>
> Hoping someone can help, even if it's just to point me at something that 
> says that Delivered-To's dead so that I can rework what I want to do.

Show 'postconf -n', some log output of the bounce, and the rest of master.cf.

-- 
Sahil Tandon 

Re: lost my Delivered-To: header

[LuKreme]

On 3-Aug-2009, at 07:46, Tim Coote wrote:

For historical reasons, I was using the Delivered-To: header as part
of an IMAP Sieve rule. However, I seem to have lost this header in my
inbound mail.



from the headers I got of your mail:

Return-Path: 
X-Original-To: krem...@kreme.com
Delivered-To: krem...@covisp.net

So, postfix 2.6.2 is still putting the header in. Something else must  
be taking it out?


--
Can I tell you the truth? I mean this isn't like TV news, is it?

Re: virtual_alias_maps and pipe to command

[David Zejda]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thank you for the extensive reply, you pointed me to look on the config
in whole more seriously and really, there were odd remains of
experiments from the past, which caused the behavior.. it seems, that
everything works OK now.

D.

/dev/rob0 napsal(a):
> On Monday 03 August 2009 15:27:40 David Zejda wrote:
>> I have many mappings in virtual_alias_maps to other mail addresses, but
>> I am not succesfull in aliasing to a command using the "|" in the form:
>>
>> virtal...@zejda.net  |"/usr/bin/procmail /home/veronika/.procmailrc"
> 
> That's because it was never implemented. Absence from the Postfix
> documentation can be inferred to mean that the feature does not exist.
> 
>> If I try to add the entry to the alias_maps, I get:
> 
> You need to understand that alias_maps is ONLY used by the local(8)
> delivery agent.
> 
>> Aug  3 22:18:14 o-it postfix/smtp[14594]: 1D1DC7FC2:
>> to=, relay=127.0.0.1[127.0.0.1]:27, delay=0.94,
>> delays=0.04/0.01/0.04/0.85, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued
>> as 2B29180A3)
>> Aug  3 22:18:14 o-it postfix/qmgr[14586]: 1D1DC7FC2: removed
>> Aug  3 22:18:14 o-it postfix/virtual[14598]: 2B29180A3:
>> to=, relay=virtual, delay=0.86,
>> delays=0.85/0.01/0/0.01, dsn=5.1.1, status=bounced (unknown user:
>> "al...@zejda.net")
> 
> The address you gave it is using the virtual(8) delivery agent.
> 
>> Please, how can I let postfix to deliver to external command?
>   ^
> Incomplete question. Insert "virtual mailbox addresses" above. And BTW,
> this is indeed a FAQ here, where did you look?
> 
> mydestination = [ ... what you needed before ... ], localhost,
>   localhost.$mydomain
> virtual_alias_maps containing:
>   addr...@virtual_mailbox  al...@localhost
> virtual_mailbox_maps containing:
>   addr...@virtual_mailbox  anything here
> alias_maps containing:
>   alias:   |"/path/to/your/command and arguments"
> 
> See aliases(5) for the details of running commands from an alias. Offer
> void where taxed or prohibited by law, or if you failed to build any
> necessary files with postmap(1)/newaliases(1).
> 
>> postconf -n
>>
>> alias_maps = btree:/etc/postfix/aliases
>> allow_mail_to_commands = alias,forward,include
>> append_dot_mydomain = no
> 
> This setting removes the need for "localhost.$mydomain" as I gave you
> above.
> 
>> bounce_size_limit = 64000
>> command_directory = /usr/sbin
>> config_directory = /etc/postfix
>> content_filter = smtp:[127.0.0.1]:27
>> daemon_directory = /usr/lib/postfix
>> default_privs = neznamy
> 
> Know what this one means. See postconf.5.html#default_privs .
> 
>> local_recipient_maps =
> 
> Why?
> 
>> local_transport = virtual
> 
> No, take this out.
> 
>> mail_owner = postfix
>> mydestination = $myhostname, $mydomain, btree:/etc/postfix/virtdomains
> 
> "virtdomains" included in mydestination? You seem to be very confused
> here. Did you try to follow some HOWTO or tutorial which you did not
> understand?
> 
> *If* you really need virtual mailboxes (small sites and beginners
> generally do not!) you should follow the real documentation:
>   http://www.postfix.org/VIRTUAL_README.html
> and understand the choices you have:
>   http://www.postfix.org/ADDRESS_CLASS_README.html
> 
> My guess is that you would have been better off forgetting about
> virtual mailboxes and just using the BASIC_CONFIGURATION_README.
> Virtual alias domains can easily provide namespace separation for
> multiple domains, still using local(8) delivery.
> 
>> myhostname = smtp.o-it.info
>> mynetworks = 127.0.0.0/8, 82.113.54.166/32, 81.92.145.161/32,
>> 192.168.30.136/32
>> myorigin = $mydomain
>> relay_domains = $mynetworks
> 
> Wrong. Most sites should just unset this. Anyway, $mynetworks is a
> network list, not a domain list.
> 
>> smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
>> smtpd_delay_reject = yes
>> smtpd_recipient_restrictions = permit_mynetworkscheck_policy_service
>> inet:127.0.0.1:6check_recipient_access
>> btree:/etc/postfix/virtaccessreject
> 
> This looks very odd too. Is "virtaccess" what you used in place of
> doing virtual_mailbox_domains/maps the documented way?
> 
>> transport_maps = btree:/etc/postfix/transport
> 
> Why? What's in here?
> 
>> virtual_alias_maps = btree:/etc/postfix/virtalias
>> virtual_gid_maps = static:8
> 
> Such a low GID/UID is an unusual choice. Not necessarily wrong per se,
> but you should know why you chose it.
> 
>> virtual_mailbox_base = /var/mail
>> virtual_mailbox_maps = btree:/etc/postfix/virtmbox
>> virtual_minimum_uid = 7
>> virtual_uid_maps = btree:/etc/postfix/virtuid
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkp3Z5oACgkQ3oCkkciamVF5PgCfU96TqJlTOf/HGTS0YQIXiomq
NX8Anik8BZIOmp/7MV6JNpv1WKwy2gfa
=Odrx
-END PGP SIGNATURE-

Re: postfix mx check

[Udo Mueller]

sosogh schrieb:

2009-08-03 22:18:09 John Peach wrote:


...and you would really expect vodafone to accept those emails?


How to route the mail is a matter of postfix, whether 
accept those mails or not is a matter of the receiver server


Isn't that Udo Mueller's thought


I *know* that this server doesnt accept those emails and i already told 
that to my customer.


i just want to show my customer, that i did what they wanted me to do.

Postfix now doesnt check the domain name and tries to send email to 
me.vodafone.com. This mx denies acception.

Thats ok for me.

ty for your help.

Regards Udo

RE: mynetworks

[AMP Admin]

OH! So when I do it w/o the -d it shows my current config?!  I do see 
mynetworks is correct now w/o the -d!!!

Thank you so much... sometimes it's the little things that make us happy.  I'm 
obviously new to postfix. :)

-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
On Behalf Of Sahil Tandon
Sent: Monday, August 03, 2009 4:28 PM
To: AMP Admin
Cc: 
Subject: Re: mynetworks

On Aug 3, 2009, at 5:03 PM, "AMP Admin"  wrote:

> Maybe a dumb question but I can’t seem to change mynetworks in main. 
> cf.
>
>
>
> I change it to something like:
>
> mynetworks = 127.0.0.0/8, xx.xx.xx.0/8, xx.xx.xxx.xxx, xx.xx.xxx.xxx
>
> # mynetworks_style = subnet
>
>
>
> Then I restart postfix and run  postconf –d and I get this:
>
> mynetworks = 127.0.0.0/8 127.0.0.1/32 xx.xx.xxx.xxx/32
>
> mynetworks_style = subnet
>
>
>
> any thoughts?
>
Yes, RTFM.  Hint: 'd' for DEFAULT.

Re: Reverse DNS requirement

[Robert Schetterer]

Jorey Bump schrieb:
> Robert Schetterer wrote, at 08/03/2009 03:40 PM:
> 
>> lost mail to where ? gone universe *g?
>> the mail got rejected at last with a debug code
>> so the sender may take his brain to fix its problem
>> or try to reach you by phone , valid mailservers etc
>> if the sender cant fix it you can simply whitelist
>> them by ip or else for reject_unknown_reverse_client_hostname
>> mail must always be supported
>> using reject_unknown_reverse_client_hostname is relativly save these
>> spam days ,shows every day work here, the few problems a year are easy
>> to fix, make sure that you have very good dns resolves ( i.e use local
>> dns cache too)
>> i changed the reject code to 550, to let senders know at once about the
>> the problem, for fighting bots it very effective ,and dont break your head
>> about crying users behind if the senders cant show bounces and call it
>> lost mail *g
> 
> In this particular case, human senders are rarely the issue. As you
> suggest, they will often find ways to communicate to the recipient that
> there is a problem. Unfortunately, a substantial portion of the messages
> rejected by reject_unknown_(reverse_)client_hostname are sent by
> automated processes using misconfigured software or machines that bypass
> the more sensibly configured relays for a domain.

yes i know many mailling services from big companies
who missed the reverse dns, but its their problem,
after all if they cant get out their mail it should finally bounce to
someone responsable ,and then they should react, mail
must be supported ever, looking logs is daily work, there are scripts
which help,
if i find something i mean to whitelist i can do ever, or if someone
from my reciepts tells me to look at, i see no problem with thousends
of mail boxes here, nobody can create the ultimate solution which fixes
all thinkable problems, ever admin has to decide
whats fits best to his needs , here nearly no mails which was
rejected by unknown reverse was needed or asked for
 and mostly i know the senders very well *g
but why should i support others problems not asked by my reciepts


 Nobody will attempt to
> contact the recipient, who will often determine there is a problem when
> it is too late. Maintaining whitelists isn't an attractive option when
> there is already too much guesswork involved.
> 


-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

Re: mynetworks

[Sahil Tandon]

On Aug 3, 2009, at 5:03 PM, "AMP Admin"  wrote:

Maybe a dumb question but I can’t seem to change mynetworks in main. 
cf.




I change it to something like:

mynetworks = 127.0.0.0/8, xx.xx.xx.0/8, xx.xx.xxx.xxx, xx.xx.xxx.xxx

# mynetworks_style = subnet



Then I restart postfix and run  postconf –d and I get this:

mynetworks = 127.0.0.0/8 127.0.0.1/32 xx.xx.xxx.xxx/32

mynetworks_style = subnet



any thoughts?


Yes, RTFM.  Hint: 'd' for DEFAULT.

Re: Reverse DNS requirement

[Jorey Bump]

Robert Schetterer wrote, at 08/03/2009 03:40 PM:

> lost mail to where ? gone universe *g?
> the mail got rejected at last with a debug code
> so the sender may take his brain to fix its problem
> or try to reach you by phone , valid mailservers etc
> if the sender cant fix it you can simply whitelist
> them by ip or else for reject_unknown_reverse_client_hostname
> mail must always be supported
> using reject_unknown_reverse_client_hostname is relativly save these
> spam days ,shows every day work here, the few problems a year are easy
> to fix, make sure that you have very good dns resolves ( i.e use local
> dns cache too)
> i changed the reject code to 550, to let senders know at once about the
> the problem, for fighting bots it very effective ,and dont break your head
> about crying users behind if the senders cant show bounces and call it
> lost mail *g

In this particular case, human senders are rarely the issue. As you
suggest, they will often find ways to communicate to the recipient that
there is a problem. Unfortunately, a substantial portion of the messages
rejected by reject_unknown_(reverse_)client_hostname are sent by
automated processes using misconfigured software or machines that bypass
the more sensibly configured relays for a domain. Nobody will attempt to
contact the recipient, who will often determine there is a problem when
it is too late. Maintaining whitelists isn't an attractive option when
there is already too much guesswork involved.

Re: Black magic rejecting header Subjects

[/dev/rob0]

On Monday 03 August 2009 15:34:59 Lukas Ruf wrote:
> I cannot understand why Postfix/cleanup rejects particular Subject
> lines, since I have been searching for the respective regexps but
> haven't found what I've been looking for.  My question is simple: why
> are subject lines rejected that I cannot find definitions for?

Probably because they match expressions in your undisclosed [!!] file
of header_checks(5).

> Hence my *questions*: is there any black magic implemented in cleanup
> header checks?  If so, where can I disable that black magic?  Or what
> needs to be tweaked?  I am using "postfix 2.6.2~rc1-1".

The black magic is either regexp_table(5) or pcre_table(5), as
determined by your undisclosed [!!] "postconf -n". postmap(1) is the
ideal tool for debugging all kinds of Postfix lookups. See "-q".

"I had a problem, and decided to solve it with regular expressions.
Now I have two problems."

> My real problem is, that regularly I make use of the German term
> "Offerte" (Offer) due to business reasons when I send eMails.  Much
> worse it would be if "Offerte" is rejected on the inbound way.
>
> I would definitely appreciate any help very much!  Please let me know
> if I can provide further information.

The real problem is that you're trying to use the wrong tool. :)
header_checks(5) is rarely the right approach, but it's often a first
choice for people who:
1. don't understand regular expressions
2. don't understand email

Now, what was the undisclosed [!!] reason you thought you wanted to
reject these headers?

See the [!!] for items you might need to provide.
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

mynetworks

[AMP Admin]

Maybe a dumb question but I can't seem to change mynetworks in main.cf.

 

I change it to something like:

mynetworks = 127.0.0.0/8, xx.xx.xx.0/8, xx.xx.xxx.xxx, xx.xx.xxx.xxx

# mynetworks_style = subnet

 

Then I restart postfix and run  postconf -d and I get this:

mynetworks = 127.0.0.0/8 127.0.0.1/32 xx.xx.xxx.xxx/32

mynetworks_style = subnet

 

any thoughts? 

 

 

Re: virtual_alias_maps and pipe to command

[/dev/rob0]

On Monday 03 August 2009 15:27:40 David Zejda wrote:
> I have many mappings in virtual_alias_maps to other mail addresses, but
> I am not succesfull in aliasing to a command using the "|" in the form:
>
> virtal...@zejda.net   |"/usr/bin/procmail /home/veronika/.procmailrc"

That's because it was never implemented. Absence from the Postfix
documentation can be inferred to mean that the feature does not exist.

> If I try to add the entry to the alias_maps, I get:

You need to understand that alias_maps is ONLY used by the local(8)
delivery agent.

> Aug  3 22:18:14 o-it postfix/smtp[14594]: 1D1DC7FC2:
> to=, relay=127.0.0.1[127.0.0.1]:27, delay=0.94,
> delays=0.04/0.01/0.04/0.85, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued
> as 2B29180A3)
> Aug  3 22:18:14 o-it postfix/qmgr[14586]: 1D1DC7FC2: removed
> Aug  3 22:18:14 o-it postfix/virtual[14598]: 2B29180A3:
> to=, relay=virtual, delay=0.86,
> delays=0.85/0.01/0/0.01, dsn=5.1.1, status=bounced (unknown user:
> "al...@zejda.net")

The address you gave it is using the virtual(8) delivery agent.

> Please, how can I let postfix to deliver to external command?
  ^
Incomplete question. Insert "virtual mailbox addresses" above. And BTW,
this is indeed a FAQ here, where did you look?

mydestination = [ ... what you needed before ... ], localhost,
localhost.$mydomain
virtual_alias_maps containing:
addr...@virtual_mailbox  al...@localhost
virtual_mailbox_maps containing:
addr...@virtual_mailbox  anything here
alias_maps containing:
alias:   |"/path/to/your/command and arguments"

See aliases(5) for the details of running commands from an alias. Offer
void where taxed or prohibited by law, or if you failed to build any
necessary files with postmap(1)/newaliases(1).

> postconf -n
>
> alias_maps = btree:/etc/postfix/aliases
> allow_mail_to_commands = alias,forward,include
> append_dot_mydomain = no

This setting removes the need for "localhost.$mydomain" as I gave you
above.

> bounce_size_limit = 64000
> command_directory = /usr/sbin
> config_directory = /etc/postfix
> content_filter = smtp:[127.0.0.1]:27
> daemon_directory = /usr/lib/postfix
> default_privs = neznamy

Know what this one means. See postconf.5.html#default_privs .

> local_recipient_maps =

Why?

> local_transport = virtual

No, take this out.

> mail_owner = postfix
> mydestination = $myhostname, $mydomain, btree:/etc/postfix/virtdomains

"virtdomains" included in mydestination? You seem to be very confused
here. Did you try to follow some HOWTO or tutorial which you did not
understand?

*If* you really need virtual mailboxes (small sites and beginners
generally do not!) you should follow the real documentation:
http://www.postfix.org/VIRTUAL_README.html
and understand the choices you have:
http://www.postfix.org/ADDRESS_CLASS_README.html

My guess is that you would have been better off forgetting about
virtual mailboxes and just using the BASIC_CONFIGURATION_README.
Virtual alias domains can easily provide namespace separation for
multiple domains, still using local(8) delivery.

> myhostname = smtp.o-it.info
> mynetworks = 127.0.0.0/8, 82.113.54.166/32, 81.92.145.161/32,
> 192.168.30.136/32
> myorigin = $mydomain
> relay_domains = $mynetworks

Wrong. Most sites should just unset this. Anyway, $mynetworks is a
network list, not a domain list.

> smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
> smtpd_delay_reject = yes
> smtpd_recipient_restrictions = permit_mynetworkscheck_policy_service
> inet:127.0.0.1:6check_recipient_access
> btree:/etc/postfix/virtaccessreject

This looks very odd too. Is "virtaccess" what you used in place of
doing virtual_mailbox_domains/maps the documented way?

> transport_maps = btree:/etc/postfix/transport

Why? What's in here?

> virtual_alias_maps = btree:/etc/postfix/virtalias
> virtual_gid_maps = static:8

Such a low GID/UID is an unusual choice. Not necessarily wrong per se,
but you should know why you chose it.

> virtual_mailbox_base = /var/mail
> virtual_mailbox_maps = btree:/etc/postfix/virtmbox
> virtual_minimum_uid = 7
> virtual_uid_maps = btree:/etc/postfix/virtuid
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: too many postfix smtp active internet connections (2)

[Brian Evans - Postfix List]

jessk...@brel.com wrote:
> Hi again
>
> here is my postconf output. I had configured my
> smtpd_client_restrictions =
>   check_client_access hash:/usr/local/etc/postfix/access
> and hash a file, access with the list of ip addresses that I would like to
> block. But I am not sure if this is a good solution.
>
> Thanks in advanced!
> Jessica
>
> ---
>
>   
Please do not top post (Google for definition if you don't understand). 
It makes it harder to follow.
I'm assuming bad line wrapping.  If this is not the case, please fix it.
> Here is my postconf -n output.
>
> mydestination = $myhostname, localhost, localhost.$mydomain,
> gareth.brel.com, gareth.bnn.com
> mydomain = brel.com
> myhostname = mailhost.brel.com
> mynetworks = 127.0.0.1, 165.21.73.173/32 165.21.73.174/32, 165.21.73.176/32
> 165.21.73.177/32, 165.21.73.178/32, 165.21.73.165/32
> relay_domains = $mydestination hash:/usr/local/etc/postfix/virt.access 
> $virtual_maps
>   

What is the point of this?
It looks like a bad attempt at virtual aliasing.
[snip]
> smtpd_client_restrictions = check_client_access 
> hash:/usr/local/etc/postfix/access  permit
> smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname
> smtpd_recipient_restrictions = permit_mynetworks check_client_access 
> btree:/usr/local/etc/dracd  check_sender_access 
> hash:/usr/local/etc/postfix/virt.access reject_non_fqdn_hostname, 
> reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unauth_destination, 
> reject_unauth_pipelining, reject_invalid_hostname, reject_rbl_client 
> list.dsbl.org, reject_rbl_client bl.spamcop.net,
> reject_rbl_client zen.spamhaus.org, reject_rbl_client 
> ipwhois.rfc-ignorant.org,reject_rhsbl_sender dsn.rfc-ignorant.org
>   

This a recipe for disaster if the virt.access file includes a domain + OK.
Anyone can exploit this pretending to be that sender. 
It MUST go after reject_unauth_destination to be safe.
A spammer likely found this out and started to (ab)use  your mail server.

In addition, dsbl.org is dead.  You should remove it.
> smtpd_sender_restrictions = reject_unknown_sender_domain
> smtpd_soft_error_limit = 1
> transport_retry_time = 60
> unknown_local_recipient_reject_code = 550
>
>
>   
>> jessk...@brel.com wrote:
>> 
>>> Dear netizens
>>>
>>> sorry to trouble you. My server is just overloaded with too much spams.
>>>
>>> When I view the output of netstat -ln, there are over 400 ip addresses
>>> connecting to my postfix server actively. In our mail.log, the
>>> connections
>>> are from these ip addresses that had nothing to do with our company.
>>>
>>> Would greatly appreciate if if someone can help me out... I am using an
>>> old Freebsd 4.9 running postfix.
>>>
>>>   
>> Welcome to the list!
>> Unfortunately, you seem to have missed the important welcome message:
>> "TO REPORT A PROBLEM, PLEASE SEE
>> http://www.postfix.org/DEBUG_README.html#mail";
>>
>> With such a general description, no one can help you with out some basic
>> information such as 'postconf -n' as noted in the README
>>
>> 
>
>   

Re: Black magic rejecting header Subjects

[Terry Carmen]

> It rejects the reception of eMails from within cleanup with the error
> code
> 5.7.1 message content rejected
> and the log reports
> [postfix/cleanup] 99C2312CEAC: reject: header Subject: ferte e

What does postconf -n say?

Terry

Black magic rejecting header Subjects

[Lukas Ruf]

Dear all

I cannot understand why Postfix/cleanup rejects particular Subject
lines, since I have been searching for the respective regexps but
haven't found what I've been looking for.  My question is simple: why
are subject lines rejected that I cannot find definitions for?

When a subject contains words like
"Offerte eB"

or minimally
"ferte e"

It rejects the reception of eMails from within cleanup with the error
code
5.7.1 message content rejected
and the log reports
[postfix/cleanup] 99C2312CEAC: reject: header Subject: ferte e

However, cleanup accepts subjects like
"ferten e"
or hence
"Offerten eB"

But running egreps on /etc/postfix/* does not reveal any definition
mentioned above:

  email:~!70> sudo egrep 'ferte.*e' /etc/postfix/*
  email:~!71> sudo egrep 'ferte.*' /etc/postfix/*
  email:~!72> sudo egrep 'erte.*' /etc/postfix/*
  email:~!73> sudo egrep 'erte' /etc/postfix/*

Hence my *questions*: is there any black magic implemented in cleanup
header checks?  If so, where can I disable that black magic?  Or what
needs to be tweaked?  I am using "postfix 2.6.2~rc1-1".

My real problem is, that regularly I make use of the German term
"Offerte" (Offer) due to business reasons when I send eMails.  Much
worse it would be if "Offerte" is rejected on the inbound way.

I would definitely appreciate any help very much!  Please let me know
if I can provide further information.

Thank you very much in advance.

wbr,
Lukas
-- 
Lukas Ruf    | Ad Personam
Consecom   | Ad Laborem

virtual_alias_maps and pipe to command

[David Zejda]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

I have many mappings in virtual_alias_maps to other mail addresses, but
I am not succesfull in aliasing to a command using the "|" in the form:

virtal...@zejda.net |"/usr/bin/procmail /home/veronika/.procmailrc"

If I simply add entry to the virtual alias map, I get:

Aug  3 22:18:21 o-it postfix/smtp[14594]: DCF107FC2:
to=<|/usr/bin/procmail /home/veronika/.procmai...@o-it.info>,
orig_to=, relay=127.0.0.1[127.0.0.1]:27,
delay=0.84, delays=0.01/0/0.04/0.79, dsn=2.0.0, status=sent (250 2.0.0
Ok: queued as E6B2780A3)
Aug  3 22:18:21 o-it postfix/qmgr[14586]: DCF107FC2: removed
Aug  3 22:18:21 o-it postfix/virtual[14598]: E6B2780A3:
to=<|/usr/bin/procmail /home/veronika/.procmai...@o-it.info>,
relay=virtual, delay=0.79, delays=0.79/0/0/0, dsn=5.1.1, status=bounced
(unknown user: "|/usr/bin/procmail /home/veronika/.procmai...@o-it.info")

If I try to add the entry to the alias_maps, I get:

Aug  3 22:18:14 o-it postfix/smtp[14594]: 1D1DC7FC2:
to=, relay=127.0.0.1[127.0.0.1]:27, delay=0.94,
delays=0.04/0.01/0.04/0.85, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued
as 2B29180A3)
Aug  3 22:18:14 o-it postfix/qmgr[14586]: 1D1DC7FC2: removed
Aug  3 22:18:14 o-it postfix/virtual[14598]: 2B29180A3:
to=, relay=virtual, delay=0.86,
delays=0.85/0.01/0/0.01, dsn=5.1.1, status=bounced (unknown user:
"al...@zejda.net")

Please, how can I let postfix to deliver to external command?

postconf -n

alias_maps = btree:/etc/postfix/aliases
allow_mail_to_commands = alias,forward,include
append_dot_mydomain = no
bounce_size_limit = 64000
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp:[127.0.0.1]:27
daemon_directory = /usr/lib/postfix
default_privs = neznamy
local_recipient_maps =
local_transport = virtual
mail_owner = postfix
mydestination = $myhostname, $mydomain, btree:/etc/postfix/virtdomains
myhostname = smtp.o-it.info
mynetworks = 127.0.0.0/8, 82.113.54.166/32, 81.92.145.161/32,
192.168.30.136/32
myorigin = $mydomain
relay_domains = $mynetworks
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_delay_reject = yes
smtpd_recipient_restrictions = permit_mynetworkscheck_policy_service
inet:127.0.0.1:6check_recipient_access
btree:/etc/postfix/virtaccessreject
transport_maps = btree:/etc/postfix/transport
virtual_alias_maps = btree:/etc/postfix/virtalias
virtual_gid_maps = static:8
virtual_mailbox_base = /var/mail
virtual_mailbox_maps = btree:/etc/postfix/virtmbox
virtual_minimum_uid = 7
virtual_uid_maps = btree:/etc/postfix/virtuid


Thank you!

David
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkp3SDwACgkQ3oCkkciamVEiLwCfWGr8G+2qoJDUAHHEG7G9nz1H
Iu8An1SoXowBhzPj+esWTme7E/EnqCBj
=gaip
-END PGP SIGNATURE-

Re: Differ between rejects

[/dev/rob0]

On Monday 03 August 2009 07:10:42 Christian Wittwer wrote:
> Is there a way to differ between rejected mails?
> I'm just interested in outgoing mails from my server which got rejected.
> All the mails I'm rejecting from the internet are not important for my
> pflogsumm report.

grep(1) is your friend. Pipe the results to pflogsumm.pl, enjoy.
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: Postfix HELO FQDN requirement

[/dev/rob0]

On Monday 03 August 2009 07:58:48 Robin Smidsrød wrote:
> Wietse Venema wrote:
> > John Peach:
> >> On Mon, 03 Aug 2009 13:18:52 +0200
> >> Robin Smidsr__d  wrote:
> >> [snip]
> >>
> >>> Willy De la Court wrote:
> >>>
> >>>
> >>> Does this mean that all of the reject rules are in fact not
> >>> RFC-conformant?
> >>>
> >>> The reason I mention reject_invalid_helo_hostname is that I'm unsure
> >>> if the IPv(4|6) address syntax is part of this rule (postfix version
> >>> 2.5.5, distributed with ubuntu 9.04).
> >>>
> >>> What about the two other reject rules? As far as I can tell, they are
> >>> both non-conformant.
> >>
> >> Your server, your rules.
> >
> > Indeed.  RFCs are relevant only when parties want to interoperate.
> > Generally, there is no such desire on the receiving end of SPAM.
>
> I'm just trying to figure out what to write in a policy document about
> this behaviour. A behaviour which is backed by a RFC has a lot of more
> weight (conserning interoperability) than our own policies about what is
> accepted behaviour or not.

It's subjective. In my subjective experience, I have never seen a bad
HELO (non-FQDN or invalid, or even valid bracketed [ip.add.re.ss])
delivering good mail. (YMMV if you don't know how to separate your
users' submission from MX. MUAs often do EHLO with the bracketed
[ip.add.re.ss] syntax. But no real MTA does it, IME.)

It's difficult to put your subjective experiences into a policy
document that would allow a person who lacks knowledge of the subject
area to make an informed decision. A lot of the "informed" part can
only come with experience.

> When a legitimate server is rejected it is generally easier to say "the
> admin of that server has not set up his server correctly according to
> the standard. Make him fix it if you want to receive email from them."
> than it is to say "our policies does not allow a connection like that
> because the email is usually spam". The last one is a tempting reason
> for a customer to leave and find another service provider (because it

Does this happen in the real world? Possibly. But what are the
alternatives? Allow ALL the spam through, maybe doing some expensive
content filtering which is slightly less accurate than pre-DATA checks
(and far more prone to actual loss of mail, when users do not check
their spam folders) -- or, block what you know to be garbage and take
your chance with clueless customers and clueless competitors?

But seriously, reject_non_fqdn_helo_hostname and
reject_invalid_helo_hostname are not likely to block real MX mail.

> rejects legitimate email). Whitelisting is (usually) a manual job, and
> anything that is manual work requires human intervention (i.e. usually
> not something you want).
>
> What does the reject_invalid_helo_hostname rule do with the IPv(4|6)
> HELO response? I mean, when the "domain" looks like [10.1.2.3] or [::1]?
> Does it accept or reject it? According to the RFC it should be valid.

It IS valid. "Invalid" means "not valid under RFC standards." However,
again, I have never known a real MTA to use that syntax, only MUAs and
spambots. I therefore made the policy decision to reject those (after
permit_* restrictions.)

> reject_non_fqdn_helo_hostname means that the "domain" needs to contain
> at least a dot, and otherwise conform to the DNS naming standards, am I
> correct? Will this rule short-circuit *accept* a IPv4/6 "domain", as
> defined above, or will it reject it?

A bracketed [ip.add.re.ss] is not a non-FQDN HELO. Common ones I've
seen include "friend", and strings which appear to be infected Windows
PC netbios names.

> If you don't use these reject rules, will warnings (as suggested by the
> RFCs) be inserted in the Received: line (or somewhere else in the
> header)? If it is I can use this as input to a mail filter.

Received lines are constructed the same way for all accepted mail,
augmented only by some TLS settings.

> Regards,
> Robin, which is trying to build a mail system which puts the
> choice of rejecting/filtering email in the hands of the end user.

While that sounds like a noble goal, I see lots of problems with it.
Chief among those is the fact that end users often cannot distinguish
spam from unwanted legitimate email. I think mail administration needs
much MORE professionalism (paternalism, you might even say), not less.
Good luck.
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: No hash in Solaris 10

[Wietse Venema]

Mauricio Tavares:
> make makefiles CC=gcc \
>CCARGS='-DUSE_TLS -DHAS_PCRE -DUSE_SASL_AUTH  \
>-DDEF_SERVER_SASL_TYPE=\"dovecot\" \
>-I/usr/sfw/include -I/opt/sfw/include -I/usr/local/include \
>-I/usr/local/BerkeleyDB.4.7/include ' \

That does not enable any of the Postfix Berkeley DB support.
See DB_README for instructions.

Wietse

Re: too many postfix smtp active internet connections (2)

[jesskung]

Hi again

here is my postconf output. I had configured my
smtpd_client_restrictions =
  check_client_access hash:/usr/local/etc/postfix/access
and hash a file, access with the list of ip addresses that I would like to
block. But I am not sure if this is a good solution.

Thanks in advanced!
Jessica

---

Here is my postconf -n output.

alias_database = hash:/etc/mail/aliases
alias_maps = hash:/etc/mail/aliases
body_checks = regexp:/usr/local/etc/postfix/body_checks
bounce_size_limit = 5
command_directory = /usr/local/sbin
config_directory = /usr/local/etc/postfix
daemon_directory = /usr/local/libexec/postfix
debug_peer_level = 2
default_destination_concurrency_limit = 10
default_privs = nobody
duplicate_filter_limit = 2500
header_checks = regexp:/usr/local/etc/postfix/header_checks
header_size_limit = 102400
in_flow_delay = 1s
line_length_limit = 2048
local_destination_concurrency_limit = 2
mail_owner = postfix
mail_spool_directory = /home/mailspool
mailbox_command = /usr/local/bin/procmail
mailbox_size_limit = 104857600
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
maximal_queue_lifetime = 3
message_size_limit = 20971520
mydestination = $myhostname, localhost, localhost.$mydomain,
gareth.brel.com, ga
reth.bnn.com
mydomain = brel.com
myhostname = mailhost.brel.com
mynetworks = 127.0.0.1, 165.21.73.173/32 165.21.73.174/32, 165.21.73.176/32
165.21.73.177/32, 165.21.73.178/32, 165.21.73.165/32
mynetworks_style = host
newaliases_path = /usr/local/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = no
relay_domains = $mydestination hash:/usr/local/etc/postfix/virt.access
$virtual_
maps
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_client_restrictions = check_client_access
hash:/usr/local/etc/postfix/acce
ss  permit
smtpd_error_sleep_time = 20
smtpd_hard_error_limit = 3
smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname
smtpd_junk_command_limit = 2
maps
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_client_restrictions = check_client_access
hash:/usr/local/etc/postfix/acce
ss  permit
smtpd_error_sleep_time = 20
smtpd_hard_error_limit = 3
smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname
smtpd_junk_command_limit = 2
smtpd_recipient_limit = 100
smtpd_recipient_restrictions = permit_mynetworks   
check_client_access btre
e:/usr/local/etc/dracd  check_sender_access
hash:/usr/local/etc/postfix/virt.acc
ess reject_non_fqdn_hostname, reject_non_fqdn_sender,
reject_non_fqdn_recipi
ent, reject_unauth_destination, reject_unauth_pipelining,
reject_invalid_hostnam
e, reject_rbl_client list.dsbl.org, reject_rbl_client bl.spamcop.net,
reject_rbl
_client zen.spamhaus.org, reject_rbl_client ipwhois.rfc-ignorant.org,
reject_rhs
bl_sender dsn.rfc-ignorant.org
smtpd_sender_restrictions = reject_unknown_sender_domain
smtpd_soft_error_limit = 1
transport_retry_time = 60
unknown_local_recipient_reject_code = 550


> jessk...@brel.com wrote:
>> Dear netizens
>>
>> sorry to trouble you. My server is just overloaded with too much spams.
>>
>> When I view the output of netstat -ln, there are over 400 ip addresses
>> connecting to my postfix server actively. In our mail.log, the
>> connections
>> are from these ip addresses that had nothing to do with our company.
>>
>> Would greatly appreciate if if someone can help me out... I am using an
>> old Freebsd 4.9 running postfix.
>>
>
> Welcome to the list!
> Unfortunately, you seem to have missed the important welcome message:
> "TO REPORT A PROBLEM, PLEASE SEE
> http://www.postfix.org/DEBUG_README.html#mail";
>
> With such a general description, no one can help you with out some basic
> information such as 'postconf -n' as noted in the README
>

Re: too many postfix smtp active internet connections

[Wietse Venema]

jessk...@brel.com:
> Dear netizens
> 
> sorry to trouble you. My server is just overloaded with too much spams.
> 
> When I view the output of netstat -ln, there are over 400 ip addresses
> connecting to my postfix server actively. In our mail.log, the connections
> are from these ip addresses that had nothing to do with our company.

Make Postfix faster:
http://www.postfix.org/STRESS_README.html

Get rid of the backscatter:
http://www.postfix.org/BACKSCATTER_README.html

Wietse

Re: too many postfix smtp active internet connections

[Brian Evans - Postfix List]

jessk...@brel.com wrote:
> Dear netizens
>
> sorry to trouble you. My server is just overloaded with too much spams.
>
> When I view the output of netstat -ln, there are over 400 ip addresses
> connecting to my postfix server actively. In our mail.log, the connections
> are from these ip addresses that had nothing to do with our company.
>
> Would greatly appreciate if if someone can help me out... I am using an
> old Freebsd 4.9 running postfix.
>   

Welcome to the list!
Unfortunately, you seem to have missed the important welcome message:
"TO REPORT A PROBLEM, PLEASE SEE
http://www.postfix.org/DEBUG_README.html#mail";

With such a general description, no one can help you with out some basic
information such as 'postconf -n' as noted in the README

too many postfix smtp active internet connections

[jesskung]

Dear netizens

sorry to trouble you. My server is just overloaded with too much spams.

When I view the output of netstat -ln, there are over 400 ip addresses
connecting to my postfix server actively. In our mail.log, the connections
are from these ip addresses that had nothing to do with our company.

Would greatly appreciate if if someone can help me out... I am using an
old Freebsd 4.9 running postfix.

Sincerely,
Jessica

Re: No hash in Solaris 10

[Brian Evans - Postfix List]

Mauricio Tavares wrote:
> I am compiling postfix 2.6.1 in a Solaris 10 box using the
> following script:
>
> #!/bin/bash
> make tidy
> make makefiles CC=gcc \
>   CCARGS='-DUSE_TLS -DHAS_PCRE -DUSE_SASL_AUTH  \
>   -DDEF_SERVER_SASL_TYPE=\"dovecot\" \
>   -I/usr/sfw/include -I/opt/sfw/include -I/usr/local/include \
>   -I/usr/local/BerkeleyDB.4.7/include ' \
>   AUXLIBS="-R/usr/sfw/lib -R/opt/sfw/lib -R/usr/local/lib \
>   -R/usr/local/BerkeleyDB.4.7/lib  \
>   -L/usr/sfw/lib -L/opt/sfw/lib -L/usr/local/lib \
>   -L/usr/local/BerkeleyDB.4.7/lib \
>   -lssl -lcrypto -lpcre"
> make
> if [ -r postfix-install ]; then
>   /bin/bash postfix-install -non-interactive -package
> install_root=/tmp/postfix-install mail_owner=postfix setgid_group=postfix
> fi
>
> Once it is compiled and installed, it seems not to have hash in its
> list of supported lookup table types:
>
> [r...@mail:~/todo/postfix-2.6.1] $ sudo /usr/local/sbin/postconf -m
> Password:
> cidr
> dbm
> environ
> nis
> nisplus
> pcre
> proxy
> regexp
> static
> unix
> [r...@mail:~/todo/postfix-2.6.1] $
>
> I thought it would be there since I have db 4.7 installed in the
> machine. Am I missing something here or just being mistaken as usual?
> Is it being called something else?
This is to be expected from the provided build string.  Notice that
btree isn't there either.
You seem to have missed http://www.postfix.org/DB_README.html

It's easy to find your missing support if you review that document.

Re: Reverse DNS requirement

[Robert Schetterer]

Jorey Bump schrieb:
> Mikael Bak wrote, at 08/03/2009 10:38 AM:
> 
>> I'm currently blocking all attepmts to connect from hosts not having a
>> valid reverse DNS name with "reject_unknown_reverse_client_hostname".
>>
>> This is very effective for dealing with spam. This is not our only
>> protection though :-)
>>
>> Although from time to time we get feedback from users about lost email.

lost mail to where ? gone universe *g?
the mail got rejected at last with a debug code
so the sender may take his brain to fix its problem
or try to reach you by phone , valid mailservers etc
if the sender cant fix it you can simply whitelist
them by ip or else for reject_unknown_reverse_client_hostname
mail must always be supported
using reject_unknown_reverse_client_hostname is relativly save these
spam days ,shows every day work here, the few problems a year are easy
to fix, make sure that you have very good dns resolves ( i.e use local
dns cache too)
i changed the reject code to 550, to let senders know at once about the
the problem, for fighting bots it very effective ,and dont break your head
about crying users behind if the senders cant show bounces and call it
lost mail *g


>> When checking our logs it turns out that most of the time the email is
>> lost because the sending part fails the reverse DNS lookup.
>>
>> So now I'm a bit puzzled. Are we being too restrictive? Do you guys find
>> it OK to reject hosts that fail reverse DNS checks? Do you guys find it
>> common that legit mail servers does not have a reverse DNS name? What do
>> you tell your users?
> 
> Although both reject_unknown_client_hostname and the more permissive
> reject_unknown_reverse_client_hostname are currently very effective at
> blocking spam, there are too many misconfigured mail servers out there
> for us to use either for outright blocking. Such tests are still very
> useful in a scoring system.
> 
>> I occationally try to send an email to the mail administrator of such a
>> sending server. Once they replied and they accepted my complaints and
>> fixed the problem, and they were happy I told them about it. But this
>> was the only time anyone ever answered such a request from me, so
>> perhaps it's not worth the effort.
> 
> I've discovered the same.
> 
>> Nevermind. To make it short: Is it ok to reject such sending servers or
>> not? :-)
> 
> I don't, because it would block important messages. You'd be surprised
> at how many emergency alert systems fail this test, let alone banks,
> schools, governments and other key institutions.
> 
> 
> 


-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

No hash in Solaris 10

[Mauricio Tavares]

	I am compiling postfix 2.6.1 in a Solaris 10 box using the following 
script:


#!/bin/bash
make tidy
make makefiles CC=gcc \
  CCARGS='-DUSE_TLS -DHAS_PCRE -DUSE_SASL_AUTH  \
  -DDEF_SERVER_SASL_TYPE=\"dovecot\" \
  -I/usr/sfw/include -I/opt/sfw/include -I/usr/local/include \
  -I/usr/local/BerkeleyDB.4.7/include ' \
  AUXLIBS="-R/usr/sfw/lib -R/opt/sfw/lib -R/usr/local/lib \
  -R/usr/local/BerkeleyDB.4.7/lib  \
  -L/usr/sfw/lib -L/opt/sfw/lib -L/usr/local/lib \
  -L/usr/local/BerkeleyDB.4.7/lib \
  -lssl -lcrypto -lpcre"
make
if [ -r postfix-install ]; then
  /bin/bash postfix-install -non-interactive -package 
install_root=/tmp/postfix-install mail_owner=postfix setgid_group=postfix

fi

Once it is compiled and installed, it seems not to have hash in its list 
of supported lookup table types:


[r...@mail:~/todo/postfix-2.6.1] $ sudo /usr/local/sbin/postconf -m
Password:
cidr
dbm
environ
nis
nisplus
pcre
proxy
regexp
static
unix
[r...@mail:~/todo/postfix-2.6.1] $

I thought it would be there since I have db 4.7 installed in the 
machine. Am I missing something here or just being mistaken as usual? Is 
it being called something else?

Re: Content_filter exceptions

[Noel Jones]

Luis Daniel Lucio Quiroz wrote:

Hi Mice,

As I've set up postfix+amavisd with content_filter option, I'd like to have some 
exceptions,some users wont passed to amavisd, instead next-hope will be 
forwarded,


Is there a easy way to do this?
TIA
LD


The easy way is to set those users as virus lovers and spam 
lovers in amavisd-new.


To completely bypass amavisd-new, you need two postfix 
instances and use transport_maps to route messages either to 
the amavisd-new or to the postfix back end.  The 
content_filter setting is no longer used - routing decisions 
are made by the transport table.  This is a more complicated 
but very flexible setup.  Multiple postfix instances are 
supported in every version of postfix, but greatly simplified 
in postfix 2.6 and newer.

Re: allow sasl authenticated on submission port and bypass rbl

[Brian Evans - Postfix List]

Nick Sharp wrote:
>> -Original Message-
>> From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
>> us...@postfix.org] On Behalf Of Brian Evans - Postfix List
>> Sent: Tuesday, August 04, 2009 12:30 AM
>> To: Postfix users
>> Subject: Re: allow sasl authenticated on submission port and bypass rbl
>>
>> Nick Sharp wrote:
>> 
>>> Sorry, was referring to the same log in my previous email, but didn't
>>> consider people may not always have that handy..
>>>
>>> Aug  3 22:08:27 mail1 postfix/smtpd[25798]: NOQUEUE: reject: CONNECT
>>>   
>> from
>> 
>>> unknown[58.171.194.208]: 554 5.7.1 : Client
>>>   
>> host
>> 
>>> rejected: Access denied; proto=SMTP
>>>
>>>   
>> This transaction did not have a SASL auth that was successful.
>> Therefore, any permit_sasl_authenticated will not work.
>>
>> All log entries where SASL is successful, in smtpd, will have
>> "sasl_username=" and "sasl_method=" defined
>>  
>> 
>
> Ok, with smtpd_tls_security_level=encrypt as recommended, AUTH wasn't
> offered and therefore wouldn't match permit_sasl_authenticated. I got that
> going by changing encrypt to may and it now shows when I telnet..
>
> 250-PIPELINING
> 250-SIZE 26214400
> 250-ETRN
> 250-STARTTLS
> 250-AUTH DIGEST-MD5 CRAM-MD5
> 250-AUTH=DIGEST-MD5 CRAM-MD5
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 DSN
>
> Now if I have -o
> smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
> in the submission bit in master.cf, the connect immediately rejects unless
> matching mynetworks, still not giving a chance to do SASL.. 
>
> Any ideas why this would be?
>
> The nearest I can get is accept email to my domains with TLS, with or
> without AUTH, or block you from even negotiating AUTH? There is no middle
> ground it seems (or more I am missing it! :)
>   
This is because you changed "smtpd_delay_reject = no" from it's default
to Yes.
The client is not given a chance to AUTH with this setting.

Chasing down postmaster of large organizations

[Andrew T. Robinson]

Bryan Irvine wrote:

When I was still managing an email system and got a complaint like
that.  I'd actually contact the postmaster for the mail system with
the errors and let them know it's failing.  
Let's say the problem is yahoo.com or gmail.com.  Have you ever tried to 
reach a postmaster at large corporate mail and web sites?  I am having 
problems with domains of mine being 'tarpitted' by some of the big email 
providers but I am unable to get in touch with anyone to find out a) why 
and b) if it can be fixed.


I managed it once by chasing down an SEC filing and calling the 
corporate counsel, who returned my call instantly because he thought I 
was accusing his company of SPAM (I never said or implied any such 
thing, but the misunderstanding was fortuitous).


Andy
begin:vcard
fn:Andrew T. Robinson, CISM, CGEIT, CISSP, CSSLP
n:Robinson;Andrew
org:NMI InfoSecurity Solutions
adr:;;100 Christopher Columbus Drive Suite 2121;Jersey City;NJ;07302;USA
email;internet:a...@nmi.net
title:President & Owner
tel;work:207-780-6381 x226
tel;fax:207-780-6301
tel;cell:347-327-4224
note;quoted-printable:Member of ISACA New York Area Board of Directors=0D=0A=
	andrew.robin...@isacany.org
x-mozilla-html:TRUE
url:http://www.nmi.net
version:2.1
end:vcard

RE: allow sasl authenticated on submission port and bypass rbl

[Nick Sharp]

> -Original Message-
> From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
> us...@postfix.org] On Behalf Of Brian Evans - Postfix List
> Sent: Tuesday, August 04, 2009 12:30 AM
> To: Postfix users
> Subject: Re: allow sasl authenticated on submission port and bypass rbl
> 
> Nick Sharp wrote:
> > Sorry, was referring to the same log in my previous email, but didn't
> > consider people may not always have that handy..
> >
> > Aug  3 22:08:27 mail1 postfix/smtpd[25798]: NOQUEUE: reject: CONNECT
> from
> > unknown[58.171.194.208]: 554 5.7.1 : Client
> host
> > rejected: Access denied; proto=SMTP
> >
> 
> This transaction did not have a SASL auth that was successful.
> Therefore, any permit_sasl_authenticated will not work.
> 
> All log entries where SASL is successful, in smtpd, will have
> "sasl_username=" and "sasl_method=" defined
>  

Ok, with smtpd_tls_security_level=encrypt as recommended, AUTH wasn't
offered and therefore wouldn't match permit_sasl_authenticated. I got that
going by changing encrypt to may and it now shows when I telnet..

250-PIPELINING
250-SIZE 26214400
250-ETRN
250-STARTTLS
250-AUTH DIGEST-MD5 CRAM-MD5
250-AUTH=DIGEST-MD5 CRAM-MD5
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

Now if I have -o
smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
in the submission bit in master.cf, the connect immediately rejects unless
matching mynetworks, still not giving a chance to do SASL.. 

Any ideas why this would be?

The nearest I can get is accept email to my domains with TLS, with or
without AUTH, or block you from even negotiating AUTH? There is no middle
ground it seems (or more I am missing it! :)

TIA
Nick

Content_filter exceptions

[Luis Daniel Lucio Quiroz]

Hi Mice,

As I've set up postfix+amavisd with content_filter option, I'd like to have 
some 
exceptions,some users wont passed to amavisd, instead next-hope will be 
forwarded,

Is there a easy way to do this?
TIA
LD

Re: Reverse DNS requirement

[Bryan Irvine]

When I was still managing an email system and got a complaint like
that.  I'd actually contact the postmaster for the mail system with
the errors and let them know it's failing.  Typically they'd just fix
it right up.  Only once did I have someone argue with me over a
misconfigured mail server but I sent them the snippets from the 3
RFC's they were breaking before they gave in.

Make sure of 2 things before taking that tactic though.

1> That you are polite.
2> That you are right.

:-D

-Bryan





On Mon, Aug 3, 2009 at 7:38 AM, Mikael Bak wrote:
> Hi list,
>
> Maybe a little OT, but I thought maybe you guys know how to deal with this.
>
> I'm currently blocking all attepmts to connect from hosts not having a
> valid reverse DNS name with "reject_unknown_reverse_client_hostname".
>
> This is very effective for dealing with spam. This is not our only
> protection though :-)
>
> Although from time to time we get feedback from users about lost email.
> When checking our logs it turns out that most of the time the email is
> lost because the sending part fails the reverse DNS lookup.
>
> So now I'm a bit puzzled. Are we being too restrictive? Do you guys find
> it OK to reject hosts that fail reverse DNS checks? Do you guys find it
> common that legit mail servers does not have a reverse DNS name? What do
> you tell your users?
>
> I occationally try to send an email to the mail administrator of such a
> sending server. Once they replied and they accepted my complaints and
> fixed the problem, and they were happy I told them about it. But this
> was the only time anyone ever answered such a request from me, so
> perhaps it's not worth the effort.
>
> Nevermind. To make it short: Is it ok to reject such sending servers or
> not? :-)
>
> TIA,
> Mikael
>

Re: Reverse DNS requirement

[Thomas Gelf]

Mikael Bak wrote:
> I'm currently blocking all attepmts to connect from hosts not having a
> valid reverse DNS name with "reject_unknown_reverse_client_hostname".
> ...
> Nevermind. To make it short: Is it ok to reject such sending servers or
> not? :-)


In my believes using reject_unknown_reverse_client_hostname is fine, I
wouldn't use reject_unknown_client_hostname. The latter would reject
many many SOHO-setups, but the former is a restriction we are enforcing
since more than a year right now (with peaks of slightly more than 6
million delivery attempts a day - so not that large, but large enough
to encounter all sorts of trouble you could run into when enabling such
a setting ;-)).

You will for sure have a few people complaining, but as I can tell from
my experience they'll satisfied if you can explain them, why you are
doing so - and why you are also helping their business partners if you
are doing so. It is far, far better to reject a mail than to put it
into quarantine (as you reached the required spam score as of your
missing PTR).

Quarantine folders are seldom checked, mail there is always on risk
to be completely lost. Rejected mail usually is able to inform at
least the sender - and he will for sure call someone to ask for
clarification (the recipient, his admin, his ISP...).

You should prepare a mail template explaining WHY you are doing so (you
are helping them  - a very good argument is stating that their mails
will be lost in large ISP's quarantine, if they don't fix their setup).
Also explaing WHAT their business partner should fix this ("tell his
server admin he should tell your ISP to configure a Reverse-DNS entry
for their IP or use a correctly configured mail relay").

Be prepared to meet missconfigured hosts, and be prepared to add
exceptions to your config (Hash file, DB, whatever). Many public
entities are running badly configured systems - they'll NOT fix them
and your customers will insist on receiving their mail. Therefore you
will need a "whitelist"-feature.

Best regards,
Thomas Gelf

Message Size from network and localhost

[Ing. Davy Leon]

Hi guys

There is a way I currently have a postfix 2.3.3 running. The parameter 

message_size_limit = 100

and it's working fine. My question is. There is a way to keep this limits for 
network conections, but stablish a bigger limit or less restrictive limit to 
conections from localhost or own IP ? Lets say 300 

Thanks in advance

David

Re: Question about address verification in MX2 when primary MX is down...

[Charles Marcus]

On 8/3/2009, Santiago Romero (srom...@servicom2000.com) wrote:
> This works nicely when MX1 servers are working and answering RCPT-TO
> checks, but then I asked ... what happens if my server can't reach
> the primary MX (server stopped, misconfiguration, power outage...) ?
> 
> In that case my server reacts rejecting ALL email because if cannot
> be verified with "Recipient address rejected: unverified address:
> Address verification in progress".

Unless you have a really good reason, you'd be much better off just
losing the MX2, and let smtp work as designed (retries if the primary is
down)...

The only time I personally would try to keep a secondary is if my
primary was prone to going down for extended lengths of time - but of
course it woul dbe better to solve that problem (worst case, host with
someone more reliable) than put a band-aid on it...

-- 

Best regards,

Charles

Re: Reverse DNS requirement

[Jorey Bump]

Mikael Bak wrote, at 08/03/2009 10:38 AM:

> I'm currently blocking all attepmts to connect from hosts not having a
> valid reverse DNS name with "reject_unknown_reverse_client_hostname".
> 
> This is very effective for dealing with spam. This is not our only
> protection though :-)
> 
> Although from time to time we get feedback from users about lost email.
> When checking our logs it turns out that most of the time the email is
> lost because the sending part fails the reverse DNS lookup.
> 
> So now I'm a bit puzzled. Are we being too restrictive? Do you guys find
> it OK to reject hosts that fail reverse DNS checks? Do you guys find it
> common that legit mail servers does not have a reverse DNS name? What do
> you tell your users?

Although both reject_unknown_client_hostname and the more permissive
reject_unknown_reverse_client_hostname are currently very effective at
blocking spam, there are too many misconfigured mail servers out there
for us to use either for outright blocking. Such tests are still very
useful in a scoring system.

> I occationally try to send an email to the mail administrator of such a
> sending server. Once they replied and they accepted my complaints and
> fixed the problem, and they were happy I told them about it. But this
> was the only time anyone ever answered such a request from me, so
> perhaps it's not worth the effort.

I've discovered the same.

> Nevermind. To make it short: Is it ok to reject such sending servers or
> not? :-)

I don't, because it would block important messages. You'd be surprised
at how many emergency alert systems fail this test, let alone banks,
schools, governments and other key institutions.

Re: allow sasl authenticated on submission port and bypass rbl

[Brian Evans - Postfix List]

Nick Sharp wrote:
> Sorry, was referring to the same log in my previous email, but didn't
> consider people may not always have that handy..
>
> Aug  3 22:08:27 mail1 postfix/smtpd[25798]: NOQUEUE: reject: CONNECT from
> unknown[58.171.194.208]: 554 5.7.1 : Client host
> rejected: Access denied; proto=SMTP
>   

This transaction did not have a SASL auth that was successful.
Therefore, any permit_sasl_authenticated will not work.

All log entries where SASL is successful, in smtpd, will have
"sasl_username=" and "sasl_method=" defined

Reverse DNS requirement

[Mikael Bak]

Hi list,

Maybe a little OT, but I thought maybe you guys know how to deal with this.

I'm currently blocking all attepmts to connect from hosts not having a
valid reverse DNS name with "reject_unknown_reverse_client_hostname".

This is very effective for dealing with spam. This is not our only
protection though :-)

Although from time to time we get feedback from users about lost email.
When checking our logs it turns out that most of the time the email is
lost because the sending part fails the reverse DNS lookup.

So now I'm a bit puzzled. Are we being too restrictive? Do you guys find
it OK to reject hosts that fail reverse DNS checks? Do you guys find it
common that legit mail servers does not have a reverse DNS name? What do
you tell your users?

I occationally try to send an email to the mail administrator of such a
sending server. Once they replied and they accepted my complaints and
fixed the problem, and they were happy I told them about it. But this
was the only time anyone ever answered such a request from me, so
perhaps it's not worth the effort.

Nevermind. To make it short: Is it ok to reject such sending servers or
not? :-)

TIA,
Mikael

RE: allow sasl authenticated on submission port and bypass rbl

[Nick Sharp]

> -Original Message-
> From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
> us...@postfix.org] On Behalf Of Brian Evans - Postfix List
> Sent: Monday, August 03, 2009 11:35 PM
> To: Postfix users
> Subject: Re: allow sasl authenticated on submission port and bypass rbl
> 
> Nick Sharp wrote:
> >> A sample submission entry in master.cf:
> >>
> >> submission inet n   -   n   -   -   smtpd
> >> -o smtpd_tls_security_level=encrypt
> >> -o smtpd_tls_auth_only=yes
> >> -o smtpd_sasl_auth_enable=yes
> >> -o broken_sasl_auth_clients=yes
> >> -o
> >> receive_override_options=no_header_body_checks,no_address_mappings
> >> -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
> >> -o content_filter=lmtp-amavis:[127.0.0.1]:10026
> >>
> >> The key is the smtpd_recipient_restrictions'
> permit_sasl_authenticated
> >> coming first or early.  Thus, port 587 users who authenticate pass
> the
> >> green light.
> >>
> >>
> >
> > Just tried this configuration and moved client restrictions to
> master.cf
> > under smtp;
> > smtp  inet  n   -   -   -   50   smtpd
> > -o cleanup_service_name=pre-cleanup
> > -o content_filter=procmail:filter
> > -o smtpd_client_restrictions=$master_client_restrictions
> > submission inet n   -   n   -   -   smtpd
> > -o smtpd_tls_security_level=encrypt
> > -o smtpd_tls_auth_only=yes
> > -o smtpd_sasl_auth_enable=yes
> > -o broken_sasl_auth_clients=yes
> > -o
> > receive_override_options=no_header_body_checks,no_address_mappings
> > -o
> >
> smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,r
> eject
> >
> > main.cf changes;
> >
> master_client_restrictions=permit_sasl_authenticated,permit_mynetworks
> > reject_rbl_client blackholes.easynet.nl,
> > 
> >
> > #smtpd_client_restrictions =
> >
> > and I still get Client Host: Access denied in the logs from
> everywhere
> > without permit_mynetworks in the submission
> smtpd_client_restrictions, that
> > just makes it work from our networks, but not from the wireless
> broadband.
> >
> > So I am concluding that it is not acknowledging sasl_authentication
> for some
> > reason? (I am now not seeing any rbl failed requests though..
> probably since
> > its not asked to check anymore.
> >
> > Any ideas? I am a little stumped, so any suggestions are welcomed
> with open
> > arms (and 10 minutes to test them :)
> >
> 
> With the number of restrictions you have, it is difficult to tell
> without a full, unaltered log entry.  You may replace the user with
> "u...@example.com" if you like, but the rest is crucial to understand
> *which* action caused the reject.

Sorry, was referring to the same log in my previous email, but didn't
consider people may not always have that handy..

Aug  3 22:08:27 mail1 postfix/smtpd[25798]: NOQUEUE: reject: CONNECT from
unknown[58.171.194.208]: 554 5.7.1 : Client host
rejected: Access denied; proto=SMTP

Re: Re: postfix mx check

[sosogh]

2009-08-03 22:18:09 John Peach wrote:

>...and you would really expect vodafone to accept those emails?

How to route the mail is a matter of postfix, whether 
accept those mails or not is a matter of the receiver server

Isn't that Udo Mueller's thought




--   
sosogh
2009-08-03

Re: postfix mx check

[John Peach]

On Mon, 3 Aug 2009 22:11:49 +0800
"sosogh"  wrote:

> 
> 2009-08-03 21:02:01 Udo Mueller wrote:
> 
> >My question: Is it possible to disable the domain check an let
> >postfix send these emails to me.vodafone.com 
> 
> Yes.You can use transport_maps
> http://www.postfix.org/transport.5.html
> 
> debian:/etc/postfix# postconf  -e 'transport_maps =
> hash:/etc/postfix/transport_maps.txt'
> 
> add this line into file /etc/postfix/transport_maps.txt
> vf.uk.vodafone.com   smtp:vodafone.com
> 
> debian:/etc/postfix# postmap /etc/postfix/transport_maps.txt
> debian:/etc/postfix# /etc/init.d/postfix reload
> 

...and you would really expect vodafone to accept those emails?


-- 
John

Re: postfix mx check

[sosogh]

2009-08-03 21:02:01 Udo Mueller wrote:

>My question: Is it possible to disable the domain check an let postfix 
>send these emails to me.vodafone.com 

Yes.You can use transport_maps
http://www.postfix.org/transport.5.html

debian:/etc/postfix# postconf  -e 'transport_maps = 
hash:/etc/postfix/transport_maps.txt'

add this line into file /etc/postfix/transport_maps.txt
vf.uk.vodafone.com   smtp:vodafone.com

debian:/etc/postfix# postmap /etc/postfix/transport_maps.txt
debian:/etc/postfix# /etc/init.d/postfix reload


--   
sosogh
2009-08-03

Re: allow sasl authenticated on submission port and bypass rbl

[Brian Evans - Postfix List]

Nick Sharp wrote:
>> A sample submission entry in master.cf:
>>
>> submission inet n   -   n   -   -   smtpd
>> -o smtpd_tls_security_level=encrypt
>> -o smtpd_tls_auth_only=yes
>> -o smtpd_sasl_auth_enable=yes
>> -o broken_sasl_auth_clients=yes
>> -o
>> receive_override_options=no_header_body_checks,no_address_mappings
>> -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
>> -o content_filter=lmtp-amavis:[127.0.0.1]:10026
>>
>> The key is the smtpd_recipient_restrictions' permit_sasl_authenticated
>> coming first or early.  Thus, port 587 users who authenticate pass the
>> green light.
>>
>> 
>
> Just tried this configuration and moved client restrictions to master.cf
> under smtp;
> smtp  inet  n   -   -   -   50   smtpd
> -o cleanup_service_name=pre-cleanup
> -o content_filter=procmail:filter
> -o smtpd_client_restrictions=$master_client_restrictions
> submission inet n   -   n   -   -   smtpd
> -o smtpd_tls_security_level=encrypt
> -o smtpd_tls_auth_only=yes
> -o smtpd_sasl_auth_enable=yes
> -o broken_sasl_auth_clients=yes
> -o
> receive_override_options=no_header_body_checks,no_address_mappings
> -o
> smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
>
> main.cf changes;
> master_client_restrictions=permit_sasl_authenticated,permit_mynetworks
> reject_rbl_client blackholes.easynet.nl,
>   
>
> #smtpd_client_restrictions =
>
> and I still get Client Host: Access denied in the logs from everywhere
> without permit_mynetworks in the submission smtpd_client_restrictions, that
> just makes it work from our networks, but not from the wireless broadband.
>
> So I am concluding that it is not acknowledging sasl_authentication for some
> reason? (I am now not seeing any rbl failed requests though.. probably since
> its not asked to check anymore.
>
> Any ideas? I am a little stumped, so any suggestions are welcomed with open
> arms (and 10 minutes to test them :)
>   

With the number of restrictions you have, it is difficult to tell
without a full, unaltered log entry.  You may replace the user with
"u...@example.com" if you like, but the rest is crucial to understand
*which* action caused the reject.

RE: allow sasl authenticated on submission port and bypass rbl

[Nick Sharp]

> 
> A sample submission entry in master.cf:
> 
> submission inet n   -   n   -   -   smtpd
> -o smtpd_tls_security_level=encrypt
> -o smtpd_tls_auth_only=yes
> -o smtpd_sasl_auth_enable=yes
> -o broken_sasl_auth_clients=yes
> -o
> receive_override_options=no_header_body_checks,no_address_mappings
> -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
> -o content_filter=lmtp-amavis:[127.0.0.1]:10026
> 
> The key is the smtpd_recipient_restrictions' permit_sasl_authenticated
> coming first or early.  Thus, port 587 users who authenticate pass the
> green light.
> 

Just tried this configuration and moved client restrictions to master.cf
under smtp;
smtp  inet  n   -   -   -   50   smtpd
-o cleanup_service_name=pre-cleanup
-o content_filter=procmail:filter
-o smtpd_client_restrictions=$master_client_restrictions
submission inet n   -   n   -   -   smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_tls_auth_only=yes
-o smtpd_sasl_auth_enable=yes
-o broken_sasl_auth_clients=yes
-o
receive_override_options=no_header_body_checks,no_address_mappings
-o
smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject

main.cf changes;
master_client_restrictions=permit_sasl_authenticated,permit_mynetworks
reject_rbl_client blackholes.easynet.nl,


#smtpd_client_restrictions =

and I still get Client Host: Access denied in the logs from everywhere
without permit_mynetworks in the submission smtpd_client_restrictions, that
just makes it work from our networks, but not from the wireless broadband.

So I am concluding that it is not acknowledging sasl_authentication for some
reason? (I am now not seeing any rbl failed requests though.. probably since
its not asked to check anymore.

Any ideas? I am a little stumped, so any suggestions are welcomed with open
arms (and 10 minutes to test them :)

postconf  -n
alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
content_filter = amavis:[127.0.0.1]:10024
delay_warning_time = 4h
disable_vrfy_command = yes
inet_interfaces = all
mailbox_size_limit = 0
message_size_limit = 26214400
mydestination = 
myhostname = 
mynetworks = 
myorigin = /etc/mailname
recipient_delimiter = +
relay_domains = mysql:/etc/postfix/mysql_relay_domains.cf
relayhost = 
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_delay_reject = no
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname, permit
smtpd_recipient_restrictions = permit_sasl_authenticated,
reject_unauth_pipelining,permit_mynetworks,
reject_non_fqdn_recipient,reject_unauth_destination,
permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = 
smtpd_sasl_path = smtpd
smtpd_sasl_security_options = noanonymous
smtpd_sender_restrictions = permit_sasl_authenticated,
permit_mynetworks,reject_non_fqdn_sender,
reject_unauth_pipelining,check_sender_access
hash:/etc/postfix/spoofprotection,permit
smtpd_timeout = 60s
smtpd_tls_cert_file = /etc/apache2/ssl/_.valex.com.au.crt
smtpd_tls_key_file = /etc/apache2/ssl/valexnew.key
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtpd_use_tls = yes
transport_maps = mysql:/etc/postfix/mysql_transport2.cf
virtual_alias_maps = mysql:/etc/postfix/mysql_alias.cf
virtual_gid_maps = mysql:/etc/postfix/mysql_gid.cf
virtual_mailbox_base = /var/spool/mail/virtual
virtual_mailbox_domains = mysql:/etc/postfix/mysql_domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql_mailbox.cf
virtual_transport = mysql:/etc/postfix/mysql_transport2.cf
virtual_uid_maps = mysql:/etc/postfix/mysql_uid.cf

TIA
Nick

Re: Question about address verification in MX2 when primary MX is down...

[Brian Evans - Postfix List]

Santiago Romero wrote:
>
> This works nicely when MX1 servers are working and answering RCPT-TO
> checks, but then I asked ... what happens if my server can't reach the
> primary MX (server stopped, misconfiguration, power outage...) ?
>
> In that case my server reacts rejecting ALL email because if cannot be
> verified with "Recipient address rejected: unverified address: Address
> verification in progress".
>
> Is it possible to change behaviour to ACCEPT all email when the
> primary MX cannot be contacted for address verification?. I mean:
If you want this behavior,  do not use reject_unverified*.
Instead, use a relay_recipient_maps that can be checked locally.

Postfix will then know the mail is valid and will queue the mail for
when the primary *is* available.

lost my Delivered-To: header

[Tim Coote]

Hullo

I've been a happy user and recommender of postfix for about 8 years  
now. I've tried to work out what's wrong in my situation through the  
documentation, but failed. Must be something obvious, I'm sure.


For historical reasons, I was using the Delivered-To: header as part  
of an IMAP Sieve rule. However, I seem to have lost this header in my  
inbound mail. I'm using Cyrus IMAP as my Message Store and Spambayes  
as a content filter. Cyrus is driven through LMTP.  I'm using a fedora  
build of postfix "postfix-2.5.6-1.fc10.i386".  I also have postfix on  
a firewall (postfix-2.2.11-1.rh8), which I used to use to forward mail  
to my more current system. However, the firewall MTA now merely  
forwards to the 'internal' MTA.  I'd guess that the firewall MTA used  
to prepend the Delivered-To: header, but I haven't been able to check  
that.


The problem that I have is that I cannot get that Delivered-To: header  
reinstated. I've changed the smtp entry in master.cf to:

smtp  inet  n   -   n   -   -   smtpd
 -o content_filter=spambayes:dummy

and added the spambayes entry:

spambayes unix  -   n   n   -   -   pipe
 flags=O user=tim argv=/usr/local/bin/sbwrapper.sh ${sender} $ 
{recipient}


I've added the following to main.cf as recommended:
spambayes_destination_recipient_limit = 1

Although it doesn't seem to make much difference.

The flags=O in master.cf gives me an X-Originally-To: mail header  
and there's no 'Delivered-To:' header, but if I change it to  
flags=D, mail gets bounced by the loop detection code.


I see from the documentation that some loop detection logic may have  
changed around version 2.3, but I don't think that the Delivered-To:  
header was removed. So I must be doing something wrong as I either get  
no Delivered-To: headers (flags=O), or 'too many' (flags=D).


There's no particular reason for trying to generate the Delivered-To:  
header through the callout to the content filter, but it seemed an  
easy place to plug it in.  I can see that I could have misinterpreted  
the meaning of the prepend_delivered_header key, which I leave  
untouched, but it's not obvious to me how.


I've tried the debugging suggested, but I cannot see any Delivered-To:  
header at all.


Hoping someone can help, even if it's just to point me at something  
that says that Delivered-To's dead so that I can rework what I want to  
do.


Tim




Tim Coote
t...@coote.org
vincit veritas

Re: Log analysis

[Sahil Tandon]

On Aug 3, 2009, at 9:08 AM, Martina Tomisova  
 wrote:


each recipient will be in its own log line when the message is  
delivered.

So I've got 101 lines like this one:

Jul 27 xx:yy:zz server postfix/qmgr[2580]: 50B106A60A8:
from=, size=754061, nrcpt=436 (queue active)

The time differs (this line is printed there approx. ones an hour so
it seems that he sends this batch of emails approx. each hour), it's
the same user and the same nrcpt and the same queue id. So there
should be approx. 101*436=44036 lines containing the string
50B106A60A8 at least. But there is only 1173 line like that. How is
that possible? How this works? It's possible to tell postfix that I'm
going to send message to 436 recipients and then send just a few
recipients? I'm sorry if this is a stupid question :)


As I wrote in my initial reply, nrcpt= denotes the ORIGINAL number of  
recipients.  The later log lines are very likely Postfix trying to  
deliver to different destinations for that same original message  
submission.




grep for the QUEUEID will show you other log lines. some of these  
will

include the Message-Id. The Message-Id can also be used to find other
related log lines.

I investigated lines containing the message id and the recepient and
all of them contained the queue id too.

Thanks, M.

Re: postfix mx check

[Jorey Bump]

Udo Mueller wrote, at 08/03/2009 09:01 AM:
> Hello all,
> 
> i'am having a problem at customer's site. I'am using postfix 2.5.5
> 
> Customer tries to send email to @vf.uk.vodafone.com. This domain does
> not exist:
> 
> $ dig -t any vf.uk.vodafone.com
> 
> ; <<>> DiG 9.4.3-P1 <<>> -t any vf.uk.vodafone.com
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32074
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;vf.uk.vodafone.com.INANY
> 
> ;; AUTHORITY SECTION:
> vodafone.com.1800INSOAns1.dc-ratingen.de.
> hostmaster.vodafone.com. 2008081051 28800 7200 604800 14400
> 
> ;; Query time: 75 msec
> ;; SERVER: 10.22.0.1#53(10.22.0.1)
> ;; WHEN: Mon Aug  3 14:57:17 2009
> ;; MSG SIZE  rcvd: 101
> 
> (see NXDOMAIN)
> 
> Postfix quits sending these emails with "host not found". Customers
> says, that these emails have to be sent to the mx of the domain
> vodafone.com which is me.vodafone.com because vodafone.com ist
> authoritative for vf.uk.vodafone.com (i dont think that this is correct).
> 
> My question: Is it possible to disable the domain check an let postfix
> send these emails to me.vodafone.com or am i right, that there is no
> responsible MX for the domain vf.uk.vodafone.com and postfix behaves
> correct?

If the customer wants the message to be sent to the MX for vodafone.com,
then the customer should use @vodafone.com. There is little to gain by
trying to support the use of arbitrary imaginary domains. Unless you
manage vodafone.com, you can't fix the customer's problem.

Re: Log analysis

[Martina Tomisova]

> each recipient will be in its own log line when the message is delivered.
So I've got 101 lines like this one:

Jul 27 xx:yy:zz server postfix/qmgr[2580]: 50B106A60A8:
from=, size=754061, nrcpt=436 (queue active)

The time differs (this line is printed there approx. ones an hour so
it seems that he sends this batch of emails approx. each hour), it's
the same user and the same nrcpt and the same queue id. So there
should be approx. 101*436=44036 lines containing the string
50B106A60A8 at least. But there is only 1173 line like that. How is
that possible? How this works? It's possible to tell postfix that I'm
going to send message to 436 recipients and then send just a few
recipients? I'm sorry if this is a stupid question :)

> grep for the QUEUEID will show you other log lines. some of these will
> include the Message-Id. The Message-Id can also be used to find other
> related log lines.
I investigated lines containing the message id and the recepient and
all of them contained the queue id too.

Thanks, M.

postfix mx check

[Udo Mueller]

Hello all,

i'am having a problem at customer's site. I'am using postfix 2.5.5

Customer tries to send email to @vf.uk.vodafone.com. This domain does 
not exist:


$ dig -t any vf.uk.vodafone.com

; <<>> DiG 9.4.3-P1 <<>> -t any vf.uk.vodafone.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32074
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;vf.uk.vodafone.com.IN  ANY

;; AUTHORITY SECTION:
vodafone.com.		1800	IN	SOA	ns1.dc-ratingen.de. hostmaster.vodafone.com. 
2008081051 28800 7200 604800 14400


;; Query time: 75 msec
;; SERVER: 10.22.0.1#53(10.22.0.1)
;; WHEN: Mon Aug  3 14:57:17 2009
;; MSG SIZE  rcvd: 101

(see NXDOMAIN)

Postfix quits sending these emails with "host not found". Customers 
says, that these emails have to be sent to the mx of the domain 
vodafone.com which is me.vodafone.com because vodafone.com ist 
authoritative for vf.uk.vodafone.com (i dont think that this is correct).


My question: Is it possible to disable the domain check an let postfix 
send these emails to me.vodafone.com or am i right, that there is no 
responsible MX for the domain vf.uk.vodafone.com and postfix behaves 
correct?


Hope you can help.

Regards Udo

Question about address verification in MX2 when primary MX is down...

[Santiago Romero]

Hi!.

I have a secondary MX server and I'm trying to configure it to "check" 
recipient addresses against primary SMTP servers to reject emails 
directed to non existing addresses.


I've read the following:

http://www.postfix.org/ADDRESS_VERIFICATION_README.html

So I added this to my main.cf:

address_verify_map = btree:/var/lib/postfix/verify
address_verify_positive_refresh_time = 14d

and:

smtpd_recipient_restrictions =
   permit_mynetworks,
   permit_sasl_authenticated,
   reject_unauth_pipelining,
   reject_non_fqdn_recipient,
   reject_unknown_recipient_domain,
   reject_unauth_destination,
   reject_rbl_client bl.spamcop.net,
   reject_rbl_client dnsbl.ahbl.org,
   reject_rbl_client zen.spamhaus.org,
   check_policy_service unix:private/policy-spf,
   reject_unverified_recipient, <--- This
   permit

This works nicely when MX1 servers are working and answering RCPT-TO 
checks, but then I asked ... what happens if my server can't reach the 
primary MX (server stopped, misconfiguration, power outage...) ?


In that case my server reacts rejecting ALL email because if cannot be 
verified with "Recipient address rejected: unverified address: Address 
verification in progress".


Is it possible to change behaviour to ACCEPT all email when the primary 
MX cannot be contacted for address verification?. I mean:


- If MX can be contacted -> check it and reject if 550.
- If MX cannot be contacted -> just accept it.

This machine is a secondary MX server for some domains so I'm supposed 
to accept email for them when they are not available...


I'm using postfix 2.5.1 .

Thanks a lot, and sorry if this is a very obvious question...


--
Santiago Romero

Re: Postfix HELO FQDN requirement

[Robin Smidsrød]

Wietse Venema wrote:
> John Peach:
>> On Mon, 03 Aug 2009 13:18:52 +0200
>> Robin Smidsr__d  wrote:
>> [snip]
>>> Willy De la Court wrote:
>>>
>>>
>>> Does this mean that all of the reject rules are in fact not
>>> RFC-conformant?
>>>
>>> The reason I mention reject_invalid_helo_hostname is that I'm unsure
>>> if the IPv(4|6) address syntax is part of this rule (postfix version
>>> 2.5.5, distributed with ubuntu 9.04).
>>>
>>> What about the two other reject rules? As far as I can tell, they are
>>> both non-conformant.
>> Your server, your rules.
> 
> Indeed.  RFCs are relevant only when parties want to interoperate.
> Generally, there is no such desire on the receiving end of SPAM.

I'm just trying to figure out what to write in a policy document about
this behaviour. A behaviour which is backed by a RFC has a lot of more
weight (conserning interoperability) than our own policies about what is
accepted behaviour or not.

When a legitimate server is rejected it is generally easier to say "the
admin of that server has not set up his server correctly according to
the standard. Make him fix it if you want to receive email from them."
than it is to say "our policies does not allow a connection like that
because the email is usually spam". The last one is a tempting reason
for a customer to leave and find another service provider (because it
rejects legitimate email). Whitelisting is (usually) a manual job, and
anything that is manual work requires human intervention (i.e. usually
not something you want).

What does the reject_invalid_helo_hostname rule do with the IPv(4|6)
HELO response? I mean, when the "domain" looks like [10.1.2.3] or [::1]?
Does it accept or reject it? According to the RFC it should be valid.

reject_non_fqdn_helo_hostname means that the "domain" needs to contain
at least a dot, and otherwise conform to the DNS naming standards, am I
correct? Will this rule short-circuit *accept* a IPv4/6 "domain", as
defined above, or will it reject it?

If you don't use these reject rules, will warnings (as suggested by the
RFCs) be inserted in the Received: line (or somewhere else in the
header)? If it is I can use this as input to a mail filter.

Regards,
Robin, which is trying to build a mail system which puts the choice of
rejecting/filtering email in the hands of the end user.

Re: Postfix HELO FQDN requirement

[Willy De la Court]

On Mon, 3 Aug 2009 08:05:26 -0400 (EDT), wie...@porcupine.org (Wietse
Venema) wrote:
> John Peach:
>> On Mon, 03 Aug 2009 13:18:52 +0200
>> Robin Smidsr__d  wrote:
>> [snip]
>> > Willy De la Court wrote:
>> >

This was the question asked by robin. Something went wrong with the
quoting.

>> > 
>> > Does this mean that all of the reject rules are in fact not
>> > RFC-conformant?
>> > 
>> > The reason I mention reject_invalid_helo_hostname is that I'm unsure
>> > if the IPv(4|6) address syntax is part of this rule (postfix version
>> > 2.5.5, distributed with ubuntu 9.04).
>> > 
>> > What about the two other reject rules? As far as I can tell, they are
>> > both non-conformant.
>> 
>> Your server, your rules.

And if that rule blocks about 40% of the spam

> 
> Indeed.  RFCs are relevant only when parties want to interoperate.
> Generally, there is no such desire on the receiving end of SPAM.
> 
>   Wietse

I totally agree.


-- 
Simple things make people happy.
Willy De la Court
PGP Public Key at http://www.linux-lovers.be/download/public_key.asc
PGP Key fingerprint = 784E E18F 7F85 9C7C AC1A D5FB FE08 686C 37C7 A689

Differ between rejects

[Christian Wittwer]

Hi,
Is there a way to differ between rejected mails?
I'm just interested in outgoing mails from my server which got rejected.
All the mails I'm rejecting from the internet are not important for my
pflogsumm report.

Chris

Re: Postfix HELO FQDN requirement

[Wietse Venema]

John Peach:
> On Mon, 03 Aug 2009 13:18:52 +0200
> Robin Smidsr__d  wrote:
> [snip]
> > Willy De la Court wrote:
> >
> > 
> > Does this mean that all of the reject rules are in fact not
> > RFC-conformant?
> > 
> > The reason I mention reject_invalid_helo_hostname is that I'm unsure
> > if the IPv(4|6) address syntax is part of this rule (postfix version
> > 2.5.5, distributed with ubuntu 9.04).
> > 
> > What about the two other reject rules? As far as I can tell, they are
> > both non-conformant.
> 
> Your server, your rules.

Indeed.  RFCs are relevant only when parties want to interoperate.
Generally, there is no such desire on the receiving end of SPAM.

Wietse

Re: Postfix HELO FQDN requirement

[John Peach]

On Mon, 03 Aug 2009 13:18:52 +0200
Robin Smidsr__d  wrote:
[snip]
> Willy De la Court wrote:
>
> 
> Does this mean that all of the reject rules are in fact not
> RFC-conformant?
> 
> The reason I mention reject_invalid_helo_hostname is that I'm unsure
> if the IPv(4|6) address syntax is part of this rule (postfix version
> 2.5.5, distributed with ubuntu 9.04).
> 
> What about the two other reject rules? As far as I can tell, they are
> both non-conformant.

Your server, your rules.


> 
> -- Robin
> 


-- 
John

Re: Postfix HELO FQDN requirement

[Robin Smidsrød]

Willy De la Court wrote:
> On Mon, 03 Aug 2009 11:14:10 +0200, Robin Smidsrød 
> wrote:
[snip]
> 
> rfc2821 contains the following
> 
>  -  the clarifications and applicability statements in RFC 1123 [2],
[snip]
> http://www.freesoft.org/CIE/RFC/1123/90.htm
> 
> where it states
> 
>  The sender-SMTP MUST ensure that the  parameter in a HELO command
> is a valid principal host domain name for the client host. As a result,
> the
> receiver-SMTP will not have to perform MX resolution on this name in order
> to validate the HELO parameter.
> 
>  The HELO receiver MAY verify that the HELO parameter really corresponds
> to
> the IP address of the sender. However, the receiver MUST NOT refuse to
> accept a message, even if the sender's HELO command fails verification. 
> 
> 
> So it seems it's not allowed to refuse msgs when the HELO is incorrect.
> 
>> The main.cf options I'm referring to are these:
>>
>> http://www.postfix.org/postconf.5.html#reject_non_fqdn_helo_hostname
>> http://www.postfix.org/postconf.5.html#reject_unknown_helo_hostname

my main.cf has these lines (among others):

smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions =
 permit_mynetworks,
 permit_sasl_authenticated,
 check_client_access mysql:$config_directory/sql/accept_bad_helo.cf,
 reject_invalid_helo_hostname,
 reject_non_fqdn_helo_hostname,
 reject_unknown_helo_hostname,
 permit

Does this mean that all of the reject rules are in fact not RFC-conformant?

The reason I mention reject_invalid_helo_hostname is that I'm unsure if
the IPv(4|6) address syntax is part of this rule (postfix version 2.5.5,
distributed with ubuntu 9.04).

What about the two other reject rules? As far as I can tell, they are
both non-conformant.

-- Robin

Re: Postfix HELO FQDN requirement

[Willy De la Court]

On Mon, 03 Aug 2009 12:18:53 +0200, Willy De la Court

wrote:
> On Mon, 03 Aug 2009 11:14:10 +0200, Robin Smidsrød 
> wrote:
>> I read John Peach's response to a mail regarding the Postfix option to
>> reject non-FQDN HELO transactions.
>> 
>> http://www.irbs.net/internet/postfix/0302/0183.html
>> 
>> He states that Joris Benschop is correct in that email.
>> 
>> I was scanning through RFC 821 (and also through RFC2821 which has
>> superseeded it) and I cannot find the quote referenced in the message
>> above in either of those documents.
>> 
>> Where can I find an official reference which validates what he stated
in
>> the message above?
>> 
>> As far as I can tell, section 5.2.5 does not exist in in RFC821 and
>> section 3.5 does not contain the quote specified in the above mentioned
>> message.
>> 
>> I used these references to verify the content of the RFCs.
>> 
>> http://www.ietf.org/rfc/rfc821.txt
>> http://www.ietf.org/rfc/rfc2821.txt
>> http://www.faqs.org/rfcs/rfc821.html
>> http://www.faqs.org/rfcs/rfc2821.html
> 
> rfc2821 contains the following
> 
>  -  the clarifications and applicability statements in RFC 1123 [2],
> 
> and rfc1123
> 
> http://www.freesoft.org/CIE/RFC/1123/index.htm
> 
> contains 
> 
> http://www.freesoft.org/CIE/RFC/1123/90.htm
> 
> where it states
> 
>  The sender-SMTP MUST ensure that the  parameter in a HELO
command
> is a valid principal host domain name for the client host. As a result,
> the
> receiver-SMTP will not have to perform MX resolution on this name in
order
> to validate the HELO parameter.
> 
>  The HELO receiver MAY verify that the HELO parameter really corresponds
> to
> the IP address of the sender. However, the receiver MUST NOT refuse to
> accept a message, even if the sender's HELO command fails verification. 
> 
> 
> So it seems it's not allowed to refuse msgs when the HELO is incorrect.
> 

and this I found in the rfc2821

  If the EHLO command is not acceptable to the SMTP server, 501, 500,
   or 502 failure replies MUST be returned as appropriate.  The SMTP
   server MUST stay in the same state after transmitting these replies
   that it was in before the EHLO was received.

   The SMTP client MUST, if possible, ensure that the domain parameter
   to the EHLO command is a valid principal host name (not a CNAME or MX
   name) for its host.  If this is not possible (e.g., when the client's
   address is dynamically assigned and the client does not have an
   obvious name), an address literal SHOULD be substituted for the
   domain name and supplemental information provided that will assist in
   identifying the client.

   An SMTP server MAY verify that the domain name parameter in the EHLO
   command actually corresponds to the IP address of the client.
   However, the server MUST NOT refuse to accept a message for this
   reason if the verification fails: the information about verification
   failure is for logging and tracing only.

and the same for the EHLO

>> 
>> The main.cf options I'm referring to are these:
>> 
>> http://www.postfix.org/postconf.5.html#reject_non_fqdn_helo_hostname
>> http://www.postfix.org/postconf.5.html#reject_unknown_helo_hostname
>> 
>> Apparently RFC2821 also allows IP-adress syntax (see section 4.1.1.1).
>> 
>> Can someone enlighten me as to what is actually correct behaviour
>> according to RFC?
>> 
>> Regards,
>> Robin Smidsrød

-- 
Simple things make people happy.
Willy De la Court
PGP Public Key at http://www.linux-lovers.be/download/public_key.asc
PGP Key fingerprint = 784E E18F 7F85 9C7C AC1A D5FB FE08 686C 37C7 A689

Re: Postfix HELO FQDN requirement

[Willy De la Court]

On Mon, 03 Aug 2009 11:14:10 +0200, Robin Smidsrød 
wrote:
> I read John Peach's response to a mail regarding the Postfix option to
> reject non-FQDN HELO transactions.
> 
> http://www.irbs.net/internet/postfix/0302/0183.html
> 
> He states that Joris Benschop is correct in that email.
> 
> I was scanning through RFC 821 (and also through RFC2821 which has
> superseeded it) and I cannot find the quote referenced in the message
> above in either of those documents.
> 
> Where can I find an official reference which validates what he stated in
> the message above?
> 
> As far as I can tell, section 5.2.5 does not exist in in RFC821 and
> section 3.5 does not contain the quote specified in the above mentioned
> message.
> 
> I used these references to verify the content of the RFCs.
> 
> http://www.ietf.org/rfc/rfc821.txt
> http://www.ietf.org/rfc/rfc2821.txt
> http://www.faqs.org/rfcs/rfc821.html
> http://www.faqs.org/rfcs/rfc2821.html

rfc2821 contains the following

 -  the clarifications and applicability statements in RFC 1123 [2],

and rfc1123

http://www.freesoft.org/CIE/RFC/1123/index.htm

contains 

http://www.freesoft.org/CIE/RFC/1123/90.htm

where it states

 The sender-SMTP MUST ensure that the  parameter in a HELO command
is a valid principal host domain name for the client host. As a result,
the
receiver-SMTP will not have to perform MX resolution on this name in order
to validate the HELO parameter.

 The HELO receiver MAY verify that the HELO parameter really corresponds
to
the IP address of the sender. However, the receiver MUST NOT refuse to
accept a message, even if the sender's HELO command fails verification. 


So it seems it's not allowed to refuse msgs when the HELO is incorrect.

> 
> The main.cf options I'm referring to are these:
> 
> http://www.postfix.org/postconf.5.html#reject_non_fqdn_helo_hostname
> http://www.postfix.org/postconf.5.html#reject_unknown_helo_hostname
> 
> Apparently RFC2821 also allows IP-adress syntax (see section 4.1.1.1).
> 
> Can someone enlighten me as to what is actually correct behaviour
> according to RFC?
> 
> Regards,
> Robin Smidsrød

-- 
Simple things make people happy.
Willy De la Court
PGP Public Key at http://www.linux-lovers.be/download/public_key.asc
PGP Key fingerprint = 784E E18F 7F85 9C7C AC1A D5FB FE08 686C 37C7 A689

Postfix HELO FQDN requirement

[Robin Smidsrød]

I read John Peach's response to a mail regarding the Postfix option to
reject non-FQDN HELO transactions.

http://www.irbs.net/internet/postfix/0302/0183.html

He states that Joris Benschop is correct in that email.

I was scanning through RFC 821 (and also through RFC2821 which has
superseeded it) and I cannot find the quote referenced in the message
above in either of those documents.

Where can I find an official reference which validates what he stated in
the message above?

As far as I can tell, section 5.2.5 does not exist in in RFC821 and
section 3.5 does not contain the quote specified in the above mentioned
message.

I used these references to verify the content of the RFCs.

http://www.ietf.org/rfc/rfc821.txt
http://www.ietf.org/rfc/rfc2821.txt
http://www.faqs.org/rfcs/rfc821.html
http://www.faqs.org/rfcs/rfc2821.html

The main.cf options I'm referring to are these:

http://www.postfix.org/postconf.5.html#reject_non_fqdn_helo_hostname
http://www.postfix.org/postconf.5.html#reject_unknown_helo_hostname

Apparently RFC2821 also allows IP-adress syntax (see section 4.1.1.1).

Can someone enlighten me as to what is actually correct behaviour
according to RFC?

Regards,
Robin Smidsrød

Re: allow sasl authenticated on submission port and bypass rbl

[Mike Cappella]

On 8/3/09 12:26 AM, Nick Sharp wrote:

Hi all,

Since adding check_sender_access to stop our domain from emailing unauthed
from the outside and our Wireless Broadband now being in the
pbl.spamhaus.org list, we want to allow TLS/SASL Auth'd users to email from
their broadband cards and get them bypassing the rbl's, ie RBL checks on
port 25 without auth, no rbl checks on 587 but reject those not
authenticated.

I thought I could just overwrite smtpd restrictions from main.cf with
additional rules in master.cf and get it working, but all combinations I
have tried have failed.


A sample submission entry in master.cf:

submission inet n   -   n   -   -   smtpd
   -o smtpd_tls_security_level=encrypt
   -o smtpd_tls_auth_only=yes
   -o smtpd_sasl_auth_enable=yes
   -o broken_sasl_auth_clients=yes
   -o receive_override_options=no_header_body_checks,no_address_mappings
   -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
   -o content_filter=lmtp-amavis:[127.0.0.1]:10026

The key is the smtpd_recipient_restrictions' permit_sasl_authenticated 
coming first or early.  Thus, port 587 users who authenticate pass the 
green light.





Do I have to move main.cf smtpd_(client|recipient|sender)_restrictions into
master.cf under smtp and then use the alternative restrictions under the
submission port? If so I wonder what else will loose restriction options.


Tailor as you see fit for your users.  The restrictions you'll add under 
submission overrides those in main.cf.




I am pretty sure that I can whitelist their subnet, but I must be able to
bypass the rbl checks for any auth'ed user on port 587.


Whitelisting == not so good.



Any suggestions gratefully received.

The error I seem to get if its not the rbl error;
Aug  3 15:39:14 mail1 postfix/smtpd[25528]: NOQUEUE: reject: CONNECT from
unknown[58.171.177.107]: 554 5.7.1: Client host
rejected: Access denied; proto=SMTP

allow sasl authenticated on submission port and bypass rbl

[Nick Sharp]

Hi all,

Since adding check_sender_access to stop our domain from emailing unauthed
from the outside and our Wireless Broadband now being in the
pbl.spamhaus.org list, we want to allow TLS/SASL Auth'd users to email from
their broadband cards and get them bypassing the rbl's, ie RBL checks on
port 25 without auth, no rbl checks on 587 but reject those not
authenticated.

I thought I could just overwrite smtpd restrictions from main.cf with
additional rules in master.cf and get it working, but all combinations I
have tried have failed. 

Do I have to move main.cf smtpd_(client|recipient|sender)_restrictions into
master.cf under smtp and then use the alternative restrictions under the
submission port? If so I wonder what else will loose restriction options.

I am pretty sure that I can whitelist their subnet, but I must be able to
bypass the rbl checks for any auth'ed user on port 587.

Any suggestions gratefully received.

The error I seem to get if its not the rbl error;
Aug  3 15:39:14 mail1 postfix/smtpd[25528]: NOQUEUE: reject: CONNECT from
unknown[58.171.177.107]: 554 5.7.1 : Client host
rejected: Access denied; proto=SMTP


master.cf;
smtp  inet  n   -   -   -   50   smtpd
-o cleanup_service_name=pre-cleanup 
-o content_filter=procmail:filter
#submission inet n   -   -   -   -   smtpd
#  -o smtpd_enforce_tls=yes
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
smtps inet  n   -   n   -   -   smtpd
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
#628  inet  n   -   -   -   -   qmqpd
587 inetn   -   n   -   -   smtpd 
-o smtpd_enforce_tls=yes 
-o smtpd_sasl_auth_enable=yes
#tried various combinations of these 3 (with and without reject)
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
#  -o smtpd_sender_restrictions=permit_sasl_authenticated,reject
pickupfifo  n   -   -   60  1   pickup
cleanup   unix  n   -   -   -   0   cleanup
-o mime_header_checks= 
-o nested_header_checks= 
-o body_checks= 
-o header_checks=
qmgr  fifo  n   -   n   300 1   qmgr
#qmgr fifo  n   -   -   300 1   oqmgr
tlsmgrunix  -   -   n   300   1   tlsmgr
rewrite   unix  -   -   -   -   -   trivial-rewrite
bounceunix  -   -   -   -   0   bounce
defer unix  -   -   -   -   0   bounce
trace unix  -   -   -   -   0   bounce
verifyunix  -   -   -   -   1   verify
flush unix  n   -   -   1000?   0   flush
proxymap  unix  -   -   n   -   -   proxymap
smtp  unix  -   -   -   -   -   smtp
# When relaying mail as backup MX, disable fallback_relay to avoid MX loops
relay unix  -   -   -   -   -   smtp
-o fallback_relay=
#   -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq unix  n   -   -   -   -   showq
error unix  -   -   -   -   -   error
discard   unix  -   -   -   -   -   discard
local unix  -   n   n   -   -   local
virtual   unix  -   n   n   -   -   virtual
lmtp  unix  -   -   -   -   -   lmtp
anvil unix  -   -   -   -   1   anvil
scacheunix  -   -   -   -   1   scache

#Vacation Handler
#vacation  unix  -  n   n   -   -   pipe
#   flags=Rhu user=vacation argv=/var/spool/vacation/vacation.pl

#Procmail
procmail  unix  -   n   n   -   -   pipe
  flags=Rq user=virtual argv=/usr/bin/procmail -t -m /etc/procmailrc
${sender} ${recipient}

maildrop  unix  -   n   n   -   -   pipe
  flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}
uucp  unix  -   n   n   -   -   pipe
  flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail
($recipient)
ifmailunix  -   n   n   -   -   pipe
  flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp unix  -   n   n   -   -   pipe
  flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender
$recipient
scalemail-backend unix  -   n   n   -   2   pipe
  flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store
${nexthop} ${user} ${extension}
mailman   unix  -   n   n   -   -   pipe
  flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
  ${nexthop} ${user}
amavisunix  -   -   -   -   2   smtp
-o smtp_data_do

Re: [OT] Spam Prevention

[Clunk Werclick]

On Mon, 2009-08-03 at 16:52 +1000, Thomas wrote:
> Hey,
> 
> [..]
> > Yes, I use that too - but I like a quick summary on demand.
> See: 
> You can use the scripts _without_ logwatch and get an instant summary of 
> your mail.log.
> 
> Cheers,
> Thomas
Indeed it does and that is interesting, thank you. My long term goal is
to get my Perl to log, in single line;

DATE/TIME INBOUND/OUTBOUND TO FROM SUBJECT SPAM SCORE IP

That is what I really would like to be able to do - but so far I do not
find a way that is easy or straightforward to bring all of this
information together in a single 'delivered' log. Rejected or dropped
mail is straightforward, but delivered mail seems to be harder to cobble
something together to give it, how do you say, 'the inside leg
measurements' ? 

-- 
---
C Werclick .Lot
Technical incompetent
Loyal Order Of The Teapot.

This e-mail and its attachments is intended only to be used as an e-mail
and an attachment. Any use of it for other purposes other than as an
e-mail and an attachment will not be covered by any warranty that may or
may not form part of this e-mail and attachment.