Re: unknown host error clarification

[Nick Edwards]

On Sun, Dec 25, 2011 at 1:46 PM, Sahil Tandon wrote:

> On Sun, 2011-12-25 at 13:37:52 +1000, Nick Edwards wrote:
>
> > I am wondering why I have two different errors for same reason?
> >
> > : NOQUEUE: reject: RCPT from unknown[41.203.141.1]: 450 4.7.1 Client host
> > rejected: cannot find your hostname,
> >
> > : NOQUEUE: reject: RCPT from unknown[115.153.142.125]: 550 5.7.1 Client
> > host rejected: cannot find your hostname
> > ...
>
> Show the entire log snippet, of which you elided important parts.
>
>
no, I did not, all I did not include was the from/to/helo, from/to are
irrelevant and the helo, I already mentioned
the 5xx resolved and the 4xx did not

> ...
> > unknown_client_reject_code = 550
> > unknown_address_reject_code = 550
> > unknown_hostname_reject_code = 550
> > unverified_sender_reject_code = 550
> > unknown_local_recipient_reject_code = 550
> >
> > the relevant smtpd_recipient_restrictions options I using for this are
> > ...
>
> Show the output of 'postconf -n' instead of cut & pasting from your
> main.cf.
>
>
Why? The information above is all that is needed as relevant, nothing else
in postconf output would, apart from sticky beaks wanting to know the ins
and outs of everyones configs when it clearly is not needed, reveal any
further information related to this, as already pointed out the SERVFAIL
results in 4x error always which is the answer to my query, Im not trying
to be a smart ass here, I am not new to mail adminstration, and we both
know that if my google fu had worked first time round I wouldnt needed to
have asked the question, it was more or less directed because two different
errors show a sprintf of the same reason.

Thanks anyway

--
> Sahil Tandon
>

Re: unknown host error clarification

[Nick Edwards]

On Mon, Dec 26, 2011 at 12:33 AM, Wietse Venema wrote:

> Sahil Tandon:
> > On Sun, 2011-12-25 at 13:37:52 +1000, Nick Edwards wrote:
> >
> > In the absence of full information, here's a WAG:
> >
> > > ...
> > > : NOQUEUE: reject: RCPT from unknown[41.203.141.1]: 450 4.7.1 Client
> host
> > > rejected: cannot find your hostname,
> >
> >  % host 41.203.141.1
> >  Host 1.141.203.41.in-addr.arpa not found: 2(SERVFAIL)
> >  
> > This is treated as a temporary error condition, so Postfix applies
> > reject_tempfail_action, which defaults to defer_if_permit.
>
> Confirmed. According to my copy of /usr/include/netdb.h:
>
> #define TRY_AGAIN   2 /* Non-Authoritative Host not found, or
> SERVERFAIL */
>
> Postfix uses the main.cf reject codes only in case of non-error.
>
>Wietse
>

Thanks, I got a private reply saying exactly that :-)

>  NXDOMAIN will 5xx, but SERVFAIL will 4xx

Re: unknown host error clarification

[Nick Edwards]

On Sun, Dec 25, 2011 at 2:14 PM, Noel Jones  wrote:

> On 12/24/2011 9:37 PM, Nick Edwards wrote:
> > Merry Christmas All!
> >
> > I am wondering why I have two different errors for same reason?
> >
> > : NOQUEUE: reject: RCPT from unknown[41.203.141.1]: 450 4.7.1 Client
> > host rejected: cannot find your hostname,
> >
> > : NOQUEUE: reject: RCPT from unknown[115.153.142.125]: 550 5.7.1
> > Client host rejected: cannot find your hostname
> >
> > I would prefer all of these 5xx
> >
> > But there appears to be two different checks here reporting the same
> > reason.
>
> Both these messages are from reject_unknown_client_hostname.  Maybe
> consulting the docs will give a clue as to why one is 4xx and one is
> 5xx.
>
> http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname
>
>
thanks, guess I am too used to qmail and expected a different response for
a different fail


> Also note that this restriction is known to reject a considerable
> amount of legit mail.  Use with caution.
>
>
>
True, but having used it since I became a SP admin, mostly due to places I
worked at always already using it and their admins some of which have been
mail admins for over twenty years, sticking by it, say and I too have
found,  the benefits have always outweighed the risks.
As is the words of my first mentor "why is it our problem, if the sender is
not RFC compliant"

All the best

Re: unknown host error clarification

[Charles Marcus]

On 2011-12-26 5:46 AM, Nick Edwards  wrote:
> On Sun, Dec 25, 2011 at 1:46 PM, Sahil Tandon wrote:
>> Show the entire log snippet, of which you elided important parts.

> no, I did not, all I did not include was the from/to/helo, from/to
> are irrelevant and the helo, I already mentioned the 5xx resolved and
> the 4xx did not

What you *think* may be irrelevant is very often *very* relevant.

>> Show the output of 'postconf -n' instead of cut & pasting from your
>> main.cf .

> Why? The information above is all that is needed as relevant, nothing
> else in postconf output would, apart from sticky beaks wanting to
> know the ins and outs of everyones configs when it clearly is not
> needed, reveal any further information related to this,

One of the main  things it will reveal is whether or not you are using 
the config that you *think* you are using. It is a very common error for 
someone to be editing the wrong main.cf (a secondary one that is 
somewhere else that is not actually being read/used by the running 
version of postfix), and using postconf -n output will *always* show 
what is actually being used - and there is generally nothing there that 
if posted to the list would result in any security risk to your system.


The last reason to post *full* logs of the problem transaction *and* 
full postconf -n output (feel free to anonymize domain names/IP 
addresses if you like *after* you have confirmed that they are actually 
correct, but that is almost always not necessary either - security 
through obscurity only leads to a *false* sense of security) is simple - 
that is the bare minimum of info that is needed for anyone here to be 
able to *help* you with any level of certainty, and that is why the 
welcome message you got when you joined this list instructs you to 
provide said info.


On 2011-12-26 5:54 AM, Nick Edwards  wrote:

On Sun, Dec 25, 2011 at 2:14 PM, Noel Jones 
Also note that this restriction is known to reject a considerable
amount of legit mail.  Use with caution.



True, but having used it since I became a SP admin, mostly due to places
I worked at always already using it and their admins some of which have
been mail admins for over twenty years, sticking by it, say and I too
have found,  the benefits have always outweighed the risks.
As is the words of my first mentor "why is it our problem, if the sender
is not RFC compliant"


As has been stated, you *will* lose/reject *legitimate* mail using this 
setting. Yes, in a perfect world, all servers would be RFC compliant - 
but a perfect world this isn't.


--

Best regards,

Charles

Re: unknown host error clarification

[Sahil Tandon]

On Mon, 2011-12-26 at 20:46:03 +1000, Nick Edwards wrote:

> > ...
> > Show the entire log snippet, of which you elided important parts.
> 
> no, I did not, all I did not include was the from/to/helo, from/to are
> irrelevant and the helo, I already mentioned
> the 5xx resolved and the 4xx did not

When you are asking for help on a technical mailing list, let the
experts determine what is relevant.

> > ...
> > Show the output of 'postconf -n' instead of cut & pasting from your
> > main.cf.
>
> Why? The information above is all that is needed as relevant, nothing
> else in postconf output would, apart from sticky beaks wanting to know
> the ins and outs of everyones configs when it clearly is not needed,
> reveal any further information related to this, as already pointed out
> the SERVFAIL results in 4x error 

Yes, as I already indicated in my second response to your query.  And
your "sticky beaks" comment laughably strains credulity; no one cares
about the ins and outs of your configuration.  Before asking for help
again, make sure to review the DEBUG_README (a document to which you
were referred upon joining this mailing list). 

> ...

-- 
Sahil Tandon


pgp9iILLYIubx.pgp
Description: PGP signature

Inserting Select Missing Headers

[Sabahattin Gucukoglu]

Hi,

I've got an email client (KeyMail, part of KeySoft, a specialised client in the 
BrailleNote note-takers for the blind) that fails rather gracelessly when 
messages don't have Message-Id: fields.  Being a purist, I *really* don't want 
to add any headers on mail received from outside, but I must have Message-Id: 
in this case.  Unfortunately, only always adding missing headers is an option 
in main.cf, but that adds From/Sender/Resent-* as well as the (acceptable) 
Date: and Message-Id: (To: is controllable separately).

Is there any way to uniquely control each header?  Or am I going to have to 
just lump it and always have a From: header derived from the system accounts or 
envelope sender?

Cheers,
Sabahattin

Re: Inserting Select Missing Headers

[Wietse Venema]

Sabahattin Gucukoglu:
> Hi,
> 
> I've got an email client (KeyMail, part of KeySoft, a specialised
> client in the BrailleNote note-takers for the blind) that fails
> rather gracelessly when messages don't have Message-Id: fields.
> Being a purist, I *really* don't want to add any headers on mail
> received from outside, but I must have Message-Id: in this case.
> Unfortunately, only always adding missing headers is an option in
> main.cf, but that adds From/Sender/Resent-* as well as the
> (acceptable) Date: and Message-Id: (To: is controllable separately).
>
> Is there any way to uniquely control each header?  Or am I going
> to have to just lump it and always have a From: header derived
> from the system accounts or envelope sender?

You could add this at mailbox delivery time (procmail for shell
users, sieve for Dovecot, Cyrus IMAP, etc.). Postfix is not meant
to compete with these features.

Wietse

Re: Inserting Select Missing Headers

[Robert Schetterer]

Am 26.12.2011 17:55, schrieb Sabahattin Gucukoglu:
> Hi,
> 
> I've got an email client (KeyMail, part of KeySoft, a specialised client in 
> the BrailleNote note-takers for the blind) that fails rather gracelessly when 
> messages don't have Message-Id: fields.  Being a purist, I *really* don't 
> want to add any headers on mail received from outside, but I must have 
> Message-Id: in this case.  Unfortunately, only always adding missing headers 
> is an option in main.cf, but that adds From/Sender/Resent-* as well as the 
> (acceptable) Date: and Message-Id: (To: is controllable separately).
> 
> Is there any way to uniquely control each header?  Or am I going to have to 
> just lump it and always have a From: header derived from the system accounts 
> or envelope sender?
> 
> Cheers,
> Sabahattin

your case sounds special, reading
http://www.postfix.org/header_checks.5.html

may help, you may use pcre/regex tables  etc
to add headers
search google/list archive  for examples
and perhaps adapt them to your needs
-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

Re: Inserting Select Missing Headers

[Robert Schetterer]

Am 26.12.2011 18:11, schrieb Robert Schetterer:
> Am 26.12.2011 17:55, schrieb Sabahattin Gucukoglu:
>> Hi,
>>
>> I've got an email client (KeyMail, part of KeySoft, a specialised client in 
>> the BrailleNote note-takers for the blind) that fails rather gracelessly 
>> when messages don't have Message-Id: fields.  Being a purist, I *really* 
>> don't want to add any headers on mail received from outside, but I must have 
>> Message-Id: in this case.  Unfortunately, only always adding missing headers 
>> is an option in main.cf, but that adds From/Sender/Resent-* as well as the 
>> (acceptable) Date: and Message-Id: (To: is controllable separately).
>>
>> Is there any way to uniquely control each header?  Or am I going to have to 
>> just lump it and always have a From: header derived from the system accounts 
>> or envelope sender?
>>
>> Cheers,
>> Sabahattin
> 
> your case sounds special, reading
> http://www.postfix.org/header_checks.5.html
> 
> may help, you may use pcre/regex tables  etc
> to add headers
> search google/list archive  for examples
> and perhaps adapt them to your needs

for sure ,Wietse s comment is the better advice

-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

Re: problem with dspam

[Steve]

 Original-Nachricht 
> Datum: Sun, 25 Dec 2011 19:00:10 +0100
> Von: ml 
> An: Postfix users 
> Betreff: Re: problem with dspam

> Le 25.12.2011 06:35, fakessh @ a écrit :
> > Le dimanche 25 décembre 2011 06:06, fakessh @ a écrit :
> >> Le jeudi 22 décembre 2011 22:19, Andreas Berton a écrit :
> >> > On Tue, 20 Dec 2011, fakessh @ wrote:
> >> > > hello list
> >> > > hello geek
> >> > > hello guru
> >> > > hello Fu
> >
> >> > Hi
> >> > Problem usually occur when you run dspam from pipe, and my guess 
> >> is that
> >> > you do so. Consider switch to daemon mode/lmtp whish in many cases 
> >> solv
> >> > the problem, However if need to run from command line you might 
> >> try this.
> >> >
> >> > dspam unix  -   n   n   -   10  pipe
> >> > flags=Ru user=dspam argv=/usr/bin/dspam --client
> >> > --deliver=spam,innocent
> >> > --user $user --mail-from=$sender --rcpt-to $recipient
> >> > -o destination_recipient_limit=1
> >> >
> >> >
> >> > good luck
> >> > Andreas
> >>
> >> I was not able to configure DSPAM with content_filter using lmtp:
> >> the only connection that I've managed to do that is a pipe as 
> >> described in
> >> the man page of dspam
> >>
> >> how to do manage the connection of dspam
> >> with multiple content_filter and lmtp
> >>
> >> my many test did not allow me to find a solution
> >>
> >> all etstimonials are welcome
> >
> > i reread the doc and i succes manage connection to dspam with lmtp
> > i configured multiple content filter
> > i quote my example
> >
> > # service for accepting messages FROM the DKIM signing proxy
> > 127.0.0.1:10030 inet  n  -  n   -   10  smtpd
> > -o content_filter=lmtp:unix:/var/run/dspam/dspam.sock
> > -o
> > 
> >
> receive_override_options=no_unknown_recipient_checks,no_header_body_checks
> > -o smtpd_helo_restrictions=
> > -o smtpd_client_restrictions=
> > -o smtpd_sender_restrictions=
> > -o smtpd_recipient_restrictions=permit_mynetworks,reject
> > -o mynetworks=127.0.0.0/8
> > -o smtpd_authorized_xforward_hosts=127.0.0.0/8
> >
> >
> > dspam  unix  n   -   n   -   -   lmtp
> > #-o lmtp_data_done_timeout=1200
> > #-o lmtp_send_xforward_command=yes
> > #-o disable_dns_lookups=yes
> > #-o max_use=20
> >
> >
> > 127.0.0.1:10037 inet  n -   n   -   -smtpd
> >   -o content_filter=
> >   -o
> > 
> >
> receive_override_options=no_unknown_recipient_checks,no_header_body_checks
> >   -o smtpd_helo_restrictions=
> >   -o smtpd_client_restrictions=
> >   -o smtpd_sender_restrictions=
> >   -o smtpd_recipient_restrictions=permit_mynetworks,reject
> >   -o mynetworks=127.0.0.0/8
> >   -o smtpd_authorized_xforward_hosts=127.0.0.0/8
> >
> >
> > that sample it is correct ?
> >
> > all testimonials are welcome
> 
> 
> after some and other test
> dspam break dk dkim signatures
> it is unusable
> 
> any ideas
> 
Yes. Don't modify the body after you have signed the content with dkimproxy.

You surely have configured dspam to sign outgoing mail and for sure you do 
first the signing with dkimproxy and after that you filter with dspam and you 
for sure have configured dspam to add the dspam signature into the mail body. 
Right?

> it is unusable
> 
The configuration you have is "unusable" for your use case.



> -- 
>   http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x092164A7
>   gpg --keyserver pgp.mit.edu --recv-key 092164A7
> 
>   http://urlshort.eu fakessh @
>   http://gplus.to/sshfake
>   http://gplus.to/sshswilting
>   http://gplus.to/john.swilting

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Re: Envelope sender address authorization and command line tool "mail"

[Bartłomiej Romański]

Thank you for your answer.

> UUOC, '/usr/sbin/sendmail -t t...@test.test < mail.txt' :)

I know it doesn't make sense. I just prefer reading from left to right.

> Note, this is controlling the envelope sender, not the From: header.

True, thanks.

> 1. Get rid of untrusted shell users. If you cannot trust them to
> follow the policies you have set, you definitely do not want them
> running commands on your system.

It's not only about shell users. The same problem concerns e.g. PHP scripts.

> 2. Limit shell users' access to sendmail(1) using
> authorized_submit_users:

That would break, for example, the 'at' command. It would like to
allow my users to send emails. I just want to prevent them from faking
"sender" header.

> 3. Alternatively, you could limit access to sendmail(1) using
> filesystem permissions, but this might break in an upgrade.

The same problem as above.

Thanks,
Bartek

Re: Envelope sender address authorization and command line tool "mail"

[Wietse Venema]

Bart?omiej Roma?ski:
> > 2. Limit shell users' access to sendmail(1) using
> > authorized_submit_users:
> 
> That would break, for example, the 'at' command. It would like to
> allow my users to send emails. I just want to prevent them from faking
> "sender" header.
> 
> > 3. Alternatively, you could limit access to sendmail(1) using
> > filesystem permissions, but this might break in an upgrade.
> 
> The same problem as above.

There exists no Postfix equivalent of smtpd_sender_login_maps for
command-line submissions. There has not been sufficient justfication
in fifteen years to write the code for it, and to maintain that
code for eternity.

Wietse

Re: Envelope sender address authorization and command line tool "mail"

[Noel Jones]

On 12/26/2011 6:33 PM, Wietse Venema wrote:
> Bart?omiej Roma?ski:
>>> 2. Limit shell users' access to sendmail(1) using
>>> authorized_submit_users:
>>
>> That would break, for example, the 'at' command. It would like to
>> allow my users to send emails. I just want to prevent them from faking
>> "sender" header.
>>
>>> 3. Alternatively, you could limit access to sendmail(1) using
>>> filesystem permissions, but this might break in an upgrade.
>>
>> The same problem as above.
> 
> There exists no Postfix equivalent of smtpd_sender_login_maps for
> command-line submissions. There has not been sufficient justfication
> in fifteen years to write the code for it, and to maintain that
> code for eternity.
> 
>   Wietse


The BOFH solution is a custom cleanup_service_name with alternate
header_checks on the pickup service that removes user-supplied From:
headers.  Postfix will supply a standard header based on the UID.

Something like:
# master.cf
pickupfifo  n- n-   1pickup
  -o cleanup_service_name=pickup_cleanup

pickup_cleanup  unix  n   -   n-0cleanup
 -o header_checks=pcre:/etc/postfix/header_checks_pickup


# header_checks_pickup
/^From: /  IGNORE  user-supplied From: header not allowed




  -- Noel Jones

Re: Envelope sender address authorization and command line tool "mail"

[Viktor Dukhovni]

On Mon, Dec 26, 2011 at 08:25:42PM -0600, Noel Jones wrote:

> The BOFH solution is a custom cleanup_service_name with alternate
> header_checks on the pickup service that removes user-supplied From:
> headers.  Postfix will supply a standard header based on the UID.

IIRC this won't work. The default uid-based "From: " header is
added by postdrop(1), which is upstream of cleanup(8).

This also breaks "Resent" mail, and .forward files. All in all,
the OP's desire is to do more harm than good. I understand the
motivation, but I've try to persuade my employer to instead just
audit the headers of messages for actual malicious mismatch between
uid and "from:" without implementing largely counter-productive
preventive controls.
 
-- 
Viktor.

Ok. I'm finding a small issue on my server.

[Glenn Sieb]

Dear list,

While I have SASL set up on port 587, I recently found that foreign
IPs can connect, pretend to be, say, me, and send mail to my users.
SPF can catch this, but I think it's something that should/can be
caught by Postfix, no? So I conclude I have fubar'd my SMTP config
somehow.

How do I make it so this kind of transcript won't work unless you're
authenticating using SASL on port 587?

(connect not from my server to my server port 25)
ehlo example.org
mail from:m...@example.org
rcpt to:m...@example.org
data
subject:Testing

testing
.

(where example.org is my server in this case... when I issue the ehlo,
I get this reply:

250-wingfoot.org
250-PIPELINING
250-SIZE 204800
250-ETRN
250-STARTTLS
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN )

:-/

Thanks in advance!
Best,
--Glenn

Re: Ok. I'm finding a small issue on my server.

[Steven King]

Make sure the submission daemon in master.cf is configured with the 
following option:


-o smtpd_sasl_auth_enable=yes

Then ensure that you have SASL properly configured.

Also, ensure that your trusted networks is configured properly to ensure 
you do not inadvertently have an open relay.



On 12/27/11 12:45 AM, Glenn Sieb wrote:

Dear list,

While I have SASL set up on port 587, I recently found that foreign
IPs can connect, pretend to be, say, me, and send mail to my users.
SPF can catch this, but I think it's something that should/can be
caught by Postfix, no? So I conclude I have fubar'd my SMTP config
somehow.

How do I make it so this kind of transcript won't work unless you're
authenticating using SASL on port 587?

(connect not from my server to my server port 25)
ehlo example.org
mail from:m...@example.org
rcpt to:m...@example.org
data
subject:Testing

testing
.

(where example.org is my server in this case... when I issue the ehlo,
I get this reply:

250-wingfoot.org
250-PIPELINING
250-SIZE 204800
250-ETRN
250-STARTTLS
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN )

:-/

Thanks in advance!
Best,
--Glenn


--
Steve King

Senior Linux Engineer - WebMD LLC
Cisco Certified Network Associate
CompTIA Linux+ Certified Professional
CompTIA A+ Certified Professional

Re: Ok. I'm finding a small issue on my server.

[Bjørn Ruberg]

On 12/27/2011 06:45 AM, Glenn Sieb wrote:

Dear list,

While I have SASL set up on port 587, I recently found that foreign
IPs can connect, pretend to be, say, me, and send mail to my users.
SPF can catch this, but I think it's something that should/can be
caught by Postfix, no?


Can, yes. But not by default.


So I conclude I have fubar'd my SMTP config
somehow.


Not necessarily. You're probably looking for smtpd_helo_restrictions, 
under which you can (among other things) reject remote *hosts* 
pretending to be you.



How do I make it so this kind of transcript won't work unless you're
authenticating using SASL on port 587?

(connect not from my server to my server port 25)



SASL will authenticate the user, not the remote server. You won't fix 
the EHLO/HELO issue with SASL. Be advised that if you plan to reject 
*sender addresses* claiming to originate from your own domain, you might 
break legitimate mails.


--
Bjørn

Re: Loadbalancing+failover solution

[Michael Maymann]

Hi All,
Wietse: thanks for your replies - and sorry for not really knowing what I'm
asking...:-)
I guess my question is regarding receiving mail to PostFix: Linux
servers->PostFix.
is "DNS RoundRobin" or "MX record with equal value" preferred


thanks in advance :-) !

~maymann

2011/12/23 Wietse Venema 

> Wietse:
> > According to these:
> >
> > http://www.postfix.org/postconf.5.html#smtp_mx_address_limit
> > http://www.postfix.org/postconf.5.html#smtp_mx_session_limit
> >
> > The Postfix SMTP client will try at least five IP addresses or two
> > SMTP sessions, When it reaches either limit, Postfix will
> > try another delivery later for several days.
> >
> > The retry schedule behaves as documented at:
> >
> > http://www.postfix.org/TUNING_README.html#hammer
>
> Michael Maymann:
> > Hi Wietse,
> >
> > thanks for your nice comments.
> >
> > I guess what you mention is valid for "my internal postfix relay
> > server"->"ISP mailserver" - or am I mistaken ?
>
> What I write is valid for the Postfix SMTP client, whether
> it sends mail to your ISP, or to your internal mail server.
>
>Wietse
>