queue refresh time regarding.

[Anant Athavale]

Dear List,

I have a basic question.  Which is parameter I need to use to change  
in order to change the mailq refresh time.


I have the following problem.

Many of my users have their quota filled up and we have set maximum  
queue lifetime to default 5d.  When postfix refreshes its mailq  
(equivalent of sendmail -q) all pending mails to due to overquota  
become active and due to this, access to mails through front end is  
becoming slow (Load on server).


I don't want postfix to run sendmail -q equivalent on its own.  I will  
run sendmail -q through crontab at specific intervals (if it is OK).


Please let me know a practical solution to my problem.

Regards,

Anant Athavale

Re: SBC Global

[Christian Surchi]

Il giorno mer, 03/12/2008 alle 20.49 -0800, Bill Light ha scritto:
> Don't shoot the messenger, but 64.22.79.211 is on 11 different 
> (fiveten...) blacklists.  And, I personally have lots of trouble with 
> Global Net Access which seems to host more than its share of spam 
> houses.  My local blacklist is blocking the /24 subnet.
> 
> Take a look at   http://www.mxtoolbox.com/blacklists.aspx

Precisely it's in five-ten-sg.com, anyway...

http://www.five-ten-sg.com/blackhole.php?ip=64.22.79.211

bye
Christian

-- 
Christian Surchi - christian _at_ truelite.it
Truelite srl - Via Monferrato 6 - 50142 Firenze
Tel. +39 055 7879597 - Fax +39 055 736
http://www.truelite.it

Re: Visibility of Postfix docs, (was: Testing SASL HOWTO using telnet/Postfix/dovecot?)

[Wietse Venema]

M. Fioretti:
> above, one quickly learns that searching directly via Google *without*
> site restrictions is *better*, as in "more efficient" than the
> postfix.org search box.
> 
> Because, very often, it returns at least one or two task-focused
> tutorials, pages from http://postfix.state-of-mind.de/patrick.koetter
> or single messages from this very list which explain what to write in
> main.cf or master.cf to do what you needed.

Unfortunately, many non-postfix-site howtos are wrong, with
exceptions such as Koetter et al.

Do not confuse search engine *popularity* with *quality*.

Wietse

Re: queue refresh time regarding.

[Wietse Venema]

Anant Athavale:
> Dear List,
> 
> I have a basic question.  Which is parameter I need to use to change  
> in order to change the mailq refresh time.
> 
> I have the following problem.
> 
> Many of my users have their quota filled up and we have set maximum  
> queue lifetime to default 5d.  When postfix refreshes its mailq  
> (equivalent of sendmail -q) all pending mails to due to overquota  
> become active and due to this, access to mails through front end is  
> becoming slow (Load on server).
> 
> I don't want postfix to run sendmail -q equivalent on its own.  I will  
> run sendmail -q through crontab at specific intervals (if it is OK).

No, you must let Postfix work the queue.  "sendmail -q" attempts
to deliver all mail at the same time which is bad for performance.

If you let Postfix work the queue it spreads out deliveries over time.

Wietse

Re: Avoiding (trivial) spoofed "mail from"

[Roman Medina-Heigl Hernandez]

mouss escribió:
> Roman Medina-Heigl Hernandez a écrit :
>>> Why is the mail not being rejected due to
>>> reject_unauthenticated_sender_login_mismatch? I must have a silly bug but I
>>>  couldn't find it...  :-(
>> I got to solve it by:
>> smtpd_sender_login_maps = $virtual_mailbox_maps
>>
> 
> do not reuse maps this way. use a script to generate each map instead
> (or use
> 
> note that smtpd_sender_login_maps returns one or more logins, while
> virtual_mailbox_maps returns the path to the mailbox.

Since I'm using Cyrus LMTP, I don't have the "path to mailbox" variable, so
I could return whatever in $virtual_mailbox_maps. What I did was to return
the email address (which in turn corresponds to the SASL login).

So now it's perfectly "compatible" to use the same Mysql map for both
variables. I mean:

hsnew:/etc/postfix# cat /etc/postfix/vuser.mysql
# Virtual users (Mysql)
hosts   = unix:/var/run/mysqld/mysqld.sock
user= postfix
password= xx
dbname  = postfix
query   = select user from user where user = '%s'

And in main.cf:
virtual_mailbox_maps = mysql:/etc/postfix/vuser.mysql
smtpd_sender_login_maps  = mysql:/etc/postfix/vuser.mysql

Ok now? :-)

Cheers,
-r

Re: queue refresh time regarding.

[Anant Athavale]

Dear Wietse,

Thanks for the inputs.  Will adhere to your suggestions.

Regards,
ANANT.


Quoting Wietse Venema <[EMAIL PROTECTED]>:


Anant Athavale:

Dear List,

I have a basic question.  Which is parameter I need to use to change
in order to change the mailq refresh time.

I have the following problem.

Many of my users have their quota filled up and we have set maximum
queue lifetime to default 5d.  When postfix refreshes its mailq
(equivalent of sendmail -q) all pending mails to due to overquota
become active and due to this, access to mails through front end is
becoming slow (Load on server).

I don't want postfix to run sendmail -q equivalent on its own.  I will
run sendmail -q through crontab at specific intervals (if it is OK).


No, you must let Postfix work the queue.  "sendmail -q" attempts
to deliver all mail at the same time which is bad for performance.

If you let Postfix work the queue it spreads out deliveries over time.

Wietse





   Anant Athavale

Re: Visibility of Postfix docs, (was: Testing SASL HOWTO using telnet/Postfix/dovecot?)

[M. Fioretti]

On Thu, Dec 04, 2008 06:38:39 AM -0500, Wietse Venema wrote:

> Unfortunately, many non-postfix-site howtos are wrong, with
> exceptions such as Koetter et al.

OK.

> Do not confuse search engine *popularity* with *quality*.

I never did. I just gave an explanation of something others observed.

It would be a very useful service to the community if you or any other
of the real gurus could compile a short list, say one or two pages at
postfix.org, of which howtos are wrong, where and above all why. It
may save further question and confusion in the future.

Marco
-- 
Your own civil rights and the quality of your life heavily depend on how
software is used *around* you:http://digifreedom.net/node/84

Re: Visibility of Postfix docs,

[Charles Marcus]

On 12/4/2008, M. Fioretti ([EMAIL PROTECTED]) wrote:
> It would be a very useful service to the community if you or any other
> of the real gurus could compile a short list, say one or two pages at
> postfix.org, of which howtos are wrong, where and above all why. It
> may save further question and confusion in the future.

You're not serious?

That said, I am sure that the website maintainer would be happy to post
such a list if you were to provide it...

-- 

Best regards,

Charles

Re: Visibility of Postfix docs,

[Charles Marcus]

On 12/4/2008 8:42 AM, Charles Marcus wrote:
> That said, I am sure that the website maintainer would be happy to post
> such a list if you were to provide it...

Actually, that should have read '...would be happy to *consider* posting
such a list...'

-- 

Best regards,

Charles

Re: Visibility of Postfix docs,

[M. Fioretti]

On Thu, Dec 04, 2008 08:42:34 AM -0500, Charles Marcus wrote:
> On 12/4/2008, M. Fioretti ([EMAIL PROTECTED]) wrote:
> > It would be a very useful service to the community if you or any other
> > of the real gurus could compile a short list, say one or two pages at
> > postfix.org, of which howtos are wrong, where and above all why. It
> > may save further question and confusion in the future.
> 
> You're not serious?

Of course. Why not? What's wrong with the idea?

> That said, I am sure that the website maintainer would be happy to post
> such a list if you were to provide it...

Duh. Smart comment indeed. On one hand, I know enough these days to
(almost) never create personally the problem we're talking about. On
the other hand, I am not skilled enough to compile such a list,
certainly not as much as Wietse or others here who probably already
have such a list in their mind and/or could write it down in very
little time.

If I don't create the problem and don't know enough to *implement* the
solution myself and both of these things were already said, why should
you think that *I* could be the one able to *implement* it myself,
only because I'm the one who *suggested* it (***)?

It's like if a child saw a big rock blocking the street and,
suggesting to a passing-by body builder that he may easily remove it,
were told by a third person "why don't you move it yourself?"

(***) again, please note that mine was and remains a *suggestion*, I'm
not demanding that anybody does this now or anything like that.

Never mind, really, let's move on.

Marco
-- 
Your own civil rights and the quality of your life heavily depend on how
software is used *around* you:http://digifreedom.net/node/84

Domain emails from outside

[Gabriel Hahmann]

Hi all,

I'm new to the list and have a problem with my mail system. Recently I'm
receiving a lot of spam emails coming from the internet but the sender is a
user from my domain. Then I tried the same thing directly from other system,
as described below:

telnet mailsystemwithproblem 25
helo testdomain
MAIL FROM: <[EMAIL PROTECTED]>
RCPT TO: <[EMAIL PROTECTED]>
DATA
test
.

I've done this with success, and the machine that i've used to telnet is not
in the mynetworks or other parameter.
The problem is that all my users are receiving spam from themselfs. My
server is not an open relay because from outside I can't send email to other
domains, but if somebody connects and send to my own domain it works like I
said before.

My configuration is listed below, i just changed the name of the domain with
testdomain.com and another domain that this machine receive mail with
anotherdomain.com:

smtpd_banner = $myhostname ESMTP
biff = no
append_dot_mydomain = no

# TLS parameters
smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt
smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key
smtpd_use_tls = yes
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache

myhostname = mail.testdomain.com
mydomain = testdomain.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = $myhostname, $mydomain, [EMAIL PROTECTED],
anotherdomain.com
mynetworks = 127.0.0.0/8
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
message_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
queue_directory = /var/spool/postfix
debug_peer_level = 2

smtpd_error_sleep_time = 2
smtpd_soft_error_limit = 10
smtpd_hard_error_limit = 10
smtpd_delay_reject = yes
strict_rfc821_envelopes = yes
disable_vrfy_command = yes
maximal_queue_lifetime = 4h
bounce_queue_lifetime = 4h

smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain =
broken_sasl_auth_clients = yes

virtual_maps = hash:/etc/postfix/virtualusertable
virtual_mailbox_base = /var/spool/virtual

body_checks = regexp:/etc/postfix/body-checks.regexp
header_checks = regexp:/etc/postfix/header-checks.regexp

smtpd_sender_restrictions =
permit_mynetworks
,permit_sasl_authenticated
,check_client_access hash:/etc/postfix/helo-whitelist
,reject_unauth_pipelining

smtpd_recipient_restrictions =
permit_mynetworks
,permit_sasl_authenticated
,check_client_access hash:/etc/postfix/helo-whitelist
,reject_unauth_destination
,reject_unauth_pipelining

inet_protocols = all

I hope somebody could help me solve this problem or at least guide me,
showing what can I do or read to solve this.

Thanks in advance.

Gabriel.

Re: Domain emails from outside

[Charles Marcus]

On 12/4/2008, Gabriel Hahmann ([EMAIL PROTECTED]) wrote:
> My configuration is listed below

Output of postconf -n is preferred...

-- 

Best regards,

Charles

Re: Domain emails from outside

[Sahil Tandon]

Gabriel Hahmann <[EMAIL PROTECTED]> wrote:

> I'm new to the list and have a problem with my mail system. Recently I'm
> receiving a lot of spam emails coming from the internet but the sender is a
> user from my domain. Then I tried the same thing directly from other system,
> as described below:
> 
> telnet mailsystemwithproblem 25
> helo testdomain
> MAIL FROM: <[EMAIL PROTECTED]>
> RCPT TO: <[EMAIL PROTECTED]>
> DATA
> test
> .
> 
> I've done this with success, and the machine that i've used to telnet is not
> in the mynetworks or other parameter.

This makes sense; MXs outside your networks should be able to send mail
to your domains.

> The problem is that all my users are receiving spam from themselfs. My
> server is not an open relay because from outside I can't send email to other
> domains, but if somebody connects and send to my own domain it works like I
> said before.

/etc/postfix/main.cf:
smtpd_recipient_restrictions =
...
reject_unauth_destination
check_sender_access hash:/etc/postfix/copycats
...

/etc/postfix/copycats:
testdomain.com  REJECT

Be aware that your own users will not be able to send email to each
other unless they're on mynetworks or SASL authenticated (both permits
should precede the reject_unauth_destination directive).

> My configuration is listed below, i just changed the name of the domain with
> testdomain.com and another domain that this machine receive mail with
> anotherdomain.com:

As advised in the DEBUG_README, next time include the output of
'postconf -n'.

-- 
Sahil Tandon <[EMAIL PROTECTED]>

Re: Domain emails from outside

[Brian Evans - Postfix List]

Gabriel Hahmann wrote:
> Hi all,
>
> I'm new to the list and have a problem with my mail system. Recently
> I'm receiving a lot of spam emails coming from the internet but the
> sender is a user from my domain. Then I tried the same thing directly
> from other system, as described below:
>

The answer to your question is as such.
Add 'check_sender_access pcre:/path/to/config/restrict_internal_domain'
to the end of smtpd_sender_restrictions
(You may use regexp instead of pcre if your postfix does not support it,
use 'postconf -m' to check)

/path/to/config/restrict_internal_domain:
/.*\.example.com/REJECT external email with an internal sender address

> My configuration is listed below, i just changed the name of the
> domain with testdomain.com  and another domain
> that this machine receive mail with anotherdomain.com
> :
>
We recommend 'postconf -n' to make sure you did not make a typo.
Also, please use example.(com|net|org) instead of making up domain names.
> maximal_queue_lifetime = 4h
This is amazingly short.  I hope you, or the recipient, never have any
network issues.

> virtual_maps = hash:/etc/postfix/virtualusertable
Is this a really old Postfix?
This was replaced in Postfix 2.0.
Most likely you mean virtual_alias_maps, but one cannot be sure.

Brian

Re: Visibility of Postfix docs,

[Noel Jones]

M. Fioretti wrote:

On Thu, Dec 04, 2008 08:42:34 AM -0500, Charles Marcus wrote:

On 12/4/2008, M. Fioretti ([EMAIL PROTECTED]) wrote:

It would be a very useful service to the community if you or any other
of the real gurus could compile a short list, say one or two pages at
postfix.org, of which howtos are wrong, where and above all why. It
may save further question and confusion in the future.

You're not serious?


Of course. Why not? What's wrong with the idea?


That said, I am sure that the website maintainer would be happy to post
such a list if you were to provide it...




There is already a list of known useful how-tos at 
http://www.postfix.org/docs.html

Updates for that page are welcome.

I think it's unlikely there will ever be a list on postfix.org 
of "how-tos to avoid".


I think this has gone far enough, over and out.

--
Noel Jones

Re: Visibility of Postfix docs,

[mouss]

M. Fioretti a écrit :
> [snip] On one hand, I know enough these days to
> (almost) never create personally the problem we're talking about. On
> the other hand, I am not skilled enough to compile such a list,
> certainly not as much as Wietse or others here who probably already
> have such a list in their mind and/or could write it down in very
> little time.
> 
> If I don't create the problem and don't know enough to *implement* the
> solution myself and both of these things were already said, why should
> you think that *I* could be the one able to *implement* it myself,
> only because I'm the one who *suggested* it (***)?
> 

don't take it personally. it's a common reply that generally means
"sure, but it requires volunteers".

> It's like if a child saw a big rock blocking the street and,
> suggesting to a passing-by body builder that he may easily remove it,
> were told by a third person "why don't you move it yourself?"
> 
> (***) again, please note that mine was and remains a *suggestion*, I'm
> not demanding that anybody does this now or anything like that.
> 
> Never mind, really, let's move on.
> 
> Marco


yes, it's a good suggestion. unfortunately, writing such list requires
work. otherwise, the list quality would be bad, and thus worst than not
having a list. The "decentralized howto model" is problematic. while you
can talk about a printed book, it's hard to talk about (sometimes
unversioned) moving targets. a bad howto may become good if the author
updates it. a good howto may become bad if the author (or contributors)
introduce errors or bad ideas. note that the wiki you mentioned was
built to get people to write docs there. but as you can see, not much
volunteers...

and there's another problem. many users won't find the list anyway. Most
people visit the site of their OS or distribution. some will google, but
without experience, it's not easy to use the right terms in the search
query. others will use "reasonably good" terms, but won't have enough
experience to quickly ignore "unuseful" links so as to have the
opportunity to visit useful ones...

and let's not even speak of people who are in a hurry to get "something
running" and won't read docs (they will copy paste lines from here and
there).

so, yes. good docs are good, and it's good to have as many of them as
possible. nobody disagrees on that.

Re: Domain emails from outside

[Geert Hendrickx]

On Thu, Dec 04, 2008 at 10:15:55AM -0500, Sahil Tandon wrote:
> Gabriel Hahmann <[EMAIL PROTECTED]> wrote:
> 
> > I'm new to the list and have a problem with my mail system. Recently I'm
> > receiving a lot of spam emails coming from the internet but the sender is a
> > user from my domain. Then I tried the same thing directly from other system,
> > as described below:
> > 
> > telnet mailsystemwithproblem 25
> > helo testdomain
> > MAIL FROM: <[EMAIL PROTECTED]>
> > RCPT TO: <[EMAIL PROTECTED]>
> > DATA
> > test
> > .
> > 
> > I've done this with success, and the machine that i've used to telnet is not
> > in the mynetworks or other parameter.
> 
> This makes sense; MXs outside your networks should be able to send mail
> to your domains.
> 
> > The problem is that all my users are receiving spam from themselfs. My
> > server is not an open relay because from outside I can't send email to other
> > domains, but if somebody connects and send to my own domain it works like I
> > said before.
> 
> /etc/postfix/main.cf:
> smtpd_recipient_restrictions =
>   ...
>   reject_unauth_destination
>   check_sender_access hash:/etc/postfix/copycats
>   ...
> 
> /etc/postfix/copycats:
> testdomain.comREJECT
> 
> Be aware that your own users will not be able to send email to each
> other unless they're on mynetworks or SASL authenticated (both permits
> should precede the reject_unauth_destination directive).


Note that this will also block mail coming from your own users through
forwarders or mailing lists that do not rewrite the original sender.

(eg. [EMAIL PROTECTED] -> [EMAIL PROTECTED] -> [EMAIL PROTECTED])

Geert

Re: Domain emails from outside

[Roman Medina-Heigl Hernandez]

Hello,

I initiated a similar thread, few days ago, with interesting responses.
Have a look at it:
http://archives.neohapsis.com/archives/postfix/2008-12/0010.html

Summaryzing, there's a chance of legitimate mail being filtered. See the
former thread for examples and a nice discussion :-)

PS: And thanks to all who have contributed to it!

Cheers,
-Roman

Geert Hendrickx escribió:
> On Thu, Dec 04, 2008 at 10:15:55AM -0500, Sahil Tandon wrote:
>> Gabriel Hahmann <[EMAIL PROTECTED]> wrote:
>>
>>> I'm new to the list and have a problem with my mail system. Recently I'm
>>> receiving a lot of spam emails coming from the internet but the sender is a
>>> user from my domain. Then I tried the same thing directly from other system,
>>> as described below:
>>>
>>> telnet mailsystemwithproblem 25
>>> helo testdomain
>>> MAIL FROM: <[EMAIL PROTECTED]>
>>> RCPT TO: <[EMAIL PROTECTED]>
>>> DATA
>>> test
>>> .
>>>
>>> I've done this with success, and the machine that i've used to telnet is not
>>> in the mynetworks or other parameter.
>> This makes sense; MXs outside your networks should be able to send mail
>> to your domains.
>>
>>> The problem is that all my users are receiving spam from themselfs. My
>>> server is not an open relay because from outside I can't send email to other
>>> domains, but if somebody connects and send to my own domain it works like I
>>> said before.
>> /etc/postfix/main.cf:
>> smtpd_recipient_restrictions =
>>  ...
>>  reject_unauth_destination
>>  check_sender_access hash:/etc/postfix/copycats
>>  ...
>>
>> /etc/postfix/copycats:
>> testdomain.com   REJECT
>>
>> Be aware that your own users will not be able to send email to each
>> other unless they're on mynetworks or SASL authenticated (both permits
>> should precede the reject_unauth_destination directive).
> 
> 
> Note that this will also block mail coming from your own users through
> forwarders or mailing lists that do not rewrite the original sender.
> 
> (eg. [EMAIL PROTECTED] -> [EMAIL PROTECTED] -> [EMAIL PROTECTED])
> 
>   Geert
> 
> 

RE: Domain emails from outside

[wiskbroom]

I too am trying to achieve this, here is my blocked_senders map followed by my 
postconf -n  output:

Would this achieve the desired results of restricting inbound email with faked 
"From" headers?

Many thanks in advance,

.vp


  ### blocked_senders ###
example.com  554 example.com sender? But you're not in my network 
...
example.org  554 example.org sender? But you're not in my network 
...
example.net  554 example.net sender? But you're not in my network 
...
example.us   554 example.us  sender? But you're not in my network 
...
###


alias_database = dbm:/etc/postfix/aliases
alias_maps = dbm:/etc/postfix/aliases
command_directory = /postfix/sbin
config_directory = /postfix/etc
content_filter = avx:127.0.0.1:10025
daemon_directory = /postfix/libexec
debug_peer_level = 2
default_process_limit = 500
disable_vrfy_command = yes
html_directory = no
mail_owner = postfix
mailbox_size_limit = 102400
mailq_path = /postfix/bin/mailq
manpage_directory = /postfix/man
message_size_limit = 1536
mydomain = dmx.example.com
myhostname = smtp1.dmx.example.com
mynetworks = 127.0.0.0/8, !192.168.1.50, 192.168.1.0/24
myorigin = $myhostname
newaliases_path = /postfix/bin/newaliases
queue_directory = /postfix/var/spool/mqueue
rbl_reply_maps = dbm:/$config_directory/rbl_reply
readme_directory = /postfix/doc
recipient_delimiter = +
relay_domains = example.com example.org example.net us.example.com example.us 
localhost
sample_directory = /postfix/doc/samples
sendmail_path = /postfix/sbin/sendmail
setgid_group = postdrop
smtpd_banner = $myhostname ESMTP
smtpd_client_restrictions = ignore_policy_error,check_policy_service 
inet:localhost:5577
smtpd_helo_required = yes
smtpd_recipient_restrictions = permit_mynetworks,   check_sender_access 
dbm:/etc/postfix/blocked_senders,   reject_rbl_client 67679988282.rbl.com,  
reject_unauth_destination
smtpd_sender_restrictions = reject_unauth_pipelining,   
reject_unknown_sender_domain,   reject_non_fqdn_sender, 
check_recipient_access dbm:/etc/postfix/access
transport_maps = dbm:/etc/postfix/transport
unknown_address_reject_code = 550
unknown_hostname_reject_code = 550
unknown_local_recipient_reject_code = 450



> Date: Thu, 4 Dec 2008 10:02:08 -0500
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: Domain emails from outside
> 
> On 12/4/2008, Gabriel Hahmann ([EMAIL PROTECTED]) wrote:
>> My configuration is listed below
> 
> Output of postconf -n is preferred...
> 
> -- 
> 
> Best regards,
> 
> Charles

Re: Avoiding (trivial) spoofed "mail from"

[LuKreme]

On 3-Dec-2008, at 15:44, DJ Lucas wrote:

LuKreme wrote:

On 2-Dec-2008, at 20:21, DJ Lucas wrote:

I can find absolutely no reason to inadvertently mislead, or worse,
intentionally deceive the recipient by forging the envelope sender's
address.  In fact, the only reason I can see, is
to intentionally deceive the recipient.  Is there any other reason?


Sure there is.


No there isn't.  AFAIK, unless I'm misunderstanding something, the  
rest

of your message simply puts what I said above in different terms and
agrees entirely.  **my mom** was in the From header...nowhere else.
The From header can be changed up to say that it came from somebody
else.  I don't care about that.  The check in question is in the smtp
transaction, not the data.


Ah, I thought you were complaining about mismatches in the From_ and  
the From:




Yes, we agree entirely.

--
Dinosaurs are attacking! Throw a barrel!

Re: Avoiding (trivial) spoofed "mail from"

[LuKreme]

On 3-Dec-2008, at 16:53, mouss wrote:

DJ Lucas a écrit :

LuKreme wrote:

On 2-Dec-2008, at 20:21, DJ Lucas wrote:

I can find absolutely no reason to inadvertently mislead, or worse,
intentionally deceive the recipient by forging the envelope  
sender's

address.  In fact, the only reason I can see, is
to intentionally deceive the recipient.  Is there any other reason?

Sure there is.


No there isn't.


Yes. there is;-p can we agree to disagree or do we need to contact  
the UNO?


Maybe.

The FROM_ (the envelope from, the SMTP transaction from, etc) should  
always be the actual source of the message.  If acme.tld is sending a  
message on behalf of [EMAIL PROTECTED] then the FROM_ has to be  
acme.tld.  The From: should be [EMAIL PROTECTED]  there is no reason to  
lie in the SMTP transaction about who you are, and spoofing that is  
going to be a spam-tag to many servers.


I touched on this in a previous message, the FROM_ and the Received  
headers should match up in some way, even if 'matched up' is simply an  
SPF match for the FROM_



--
Well I've seen the Heart of Darkness/Read the writing on the
wall/an the voice out in the desert/Was the voice out in the
hall

Re: Domain emails from outside

[LuKreme]

On 4-Dec-2008, at 08:18, Brian Evans - Postfix List wrote:
Add 'check_sender_access pcre:/path/to/config/ 
restrict_internal_domain'

to the end of smtpd_sender_restrictions

/path/to/config/restrict_internal_domain:
/.*\.example.com/REJECT external email with an internal sender  
address



You would need to list all the domains you process mail for here,  
right?  And this is a check against the envelope from, right?  (From_  
and not From:)


--
Rincewind had always been happy to think of himself as a racist.
The One Hundred Meters, the Mile, the Marathon -- he'd run them
all.

Re: Domain emails from outside

[Brian Evans - Postfix List]

LuKreme wrote:
> On 4-Dec-2008, at 08:18, Brian Evans - Postfix List wrote:
>> Add 'check_sender_access pcre:/path/to/config/restrict_internal_domain'
>> to the end of smtpd_sender_restrictions
>>
>> /path/to/config/restrict_internal_domain:
>> /.*\.example.com/REJECT external email with an internal sender
>> address
>
>
> You would need to list all the domains you process mail for here,
> right?  And this is a check against the envelope from, right?  (From_
> and not From:)
>
That is correct.
You can also use pcre/regex magic to do multiple domains in a single
check, but test throughly and be comfortable before committing.
Only the envelope matters to me for rejects. 
This allows proper mailing list software to function as well as many web
forms.

Brian

Re: Domain emails from outside

[mouss]

[EMAIL PROTECTED] a écrit :
> 
> I too am trying to achieve this, here is my blocked_senders map followed by 
> my postconf -n  output:
> 
> Would this achieve the desired results of restricting inbound email with 
> faked "From" headers?
> 
> Many thanks in advance,
> 
> .vp
> 
> 
>   ### blocked_senders ###
> example.com  554 example.com sender? But you're not in my network 
> ...
> example.org  554 example.org sender? But you're not in my network 
> ...
> example.net  554 example.net sender? But you're not in my network 
> ...
> example.us   554 example.us  sender? But you're not in my network 
> ...
> ###
> [snip]
> smtpd_recipient_restrictions = permit_mynetworks,   check_sender_access 
> dbm:/etc/postfix/blocked_senders,   reject_rbl_client 67679988282.rbl.com,  
> reject_unauth_destination

this is unsfae. use

smtpd_recipient_restrictions =
permit_mynetworks
reject_unauth_destination
check_sender_access dbm:/etc/postfix/blocked_senders
reject_rbl_client 67679988282.rbl.com

reject_unauth_destination prevent open relay, and should be used before
check_* when maps could return an OK (accidentally or not). it is also
cheap (compared to an rbl lookup, even if it's a local rbl).


PS. please do not top post. put your reply after the text you reply to.

> [snip]

Re: Domain emails from outside

[mouss]

Brian Evans - Postfix List a écrit :
> Gabriel Hahmann wrote:
>> Hi all,
>>
>> I'm new to the list and have a problem with my mail system. Recently
>> I'm receiving a lot of spam emails coming from the internet but the
>> sender is a user from my domain. Then I tried the same thing directly
>> from other system, as described below:
>>
> 
> The answer to your question is as such.
> Add 'check_sender_access pcre:/path/to/config/restrict_internal_domain'
> to the end of smtpd_sender_restrictions
> (You may use regexp instead of pcre if your postfix does not support it,
> use 'postconf -m' to check)
> 
> /path/to/config/restrict_internal_domain:
> /.*\.example.com/REJECT external email with an internal sender address
> 

that should be
/(^|\.)example\.com$/   REJECT ...

but there is no need to use pcre. a hash/cdb/... map is enough:
.example.comREJECT ...
example.com REJECT ...



> [snip]

Spam Help Forged headers

[Chris Funk]

Hi All,

I am getting a lot of spam with forged addresses in the From: header. They
are forging it with our domain addresses.  Here is an example:

Received: from localhost (localhost.localdomain [127.0.0.1]) by
 mail.us-reports.com (Postfix) with ESMTP id 391E716C11F for
 <[EMAIL PROTECTED]>; Thu, 4 Dec 2008 08:40:55 -0700 (MST)
X-Virus-Scanned: amavisd-new at us-reports.com
Received: from mail.us-reports.com ([127.0.0.1]) by localhost
 (mail.us-reports.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id
 dBAU+DdeGeQd for <[EMAIL PROTECTED]>; Thu, 4 Dec 2008 08:40:50 -0700
 (MST)
Received: from 88-109-126-174.dynamic.dsl.as9105.com
 (88-109-126-174.dynamic.dsl.as9105.com [88.109.126.174]) by
 mail.us-reports.com (Postfix) with SMTP id 4541F16C135 for
 <[EMAIL PROTECTED]>; Thu, 4 Dec 2008 08:40:35 -0700 (MST)
To: <[EMAIL PROTECTED]>
Subject: Your Order
From: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Importance: High
Content-Type: text/html
Message-ID: <[EMAIL PROTECTED]>
Date: Thu, 4 Dec 2008 08:40:35 -0700
Return-Path: [EMAIL PROTECTED]

Here is the result of postconf | grep restrict

[EMAIL PROTECTED] postfix]# postconf | grep restrict

smtpd_client_restrictions =

smtpd_data_restrictions = reject_unauth_pipelining

smtpd_end_of_data_restrictions =

smtpd_etrn_restrictions =

smtpd_helo_restrictions = permit_mynetworks,
 permit_sasl_authenticated,
 check_helo_access hash:/etc/postfix/helo_access, reject_invalid_hostname,
 reject_non_fqdn_hostname, permit

smtpd_recipient_restrictions = permit_mynetworks,
 permit_sasl_authenticated,
 check_sender_access hash:/etc/postfix/sender_access,
 reject_non_fqdn_recipient,
 reject_unknown_recipient_domain,
 reject_rbl_client sbl.spamhaus.org,
 reject_rbl_client list.dsbl.org,
 reject_unauth_pipelining,
 reject_unauth_destination

smtpd_restriction_classes =
***
/etc/postfix/sender_access

us-reports.com   554   SPAM

my.ip.add.res   554   SPAM

I tried setting up a header check that rejected anything from  *.
us-reports.com in the From:

Obviously not a good thing to do as then no one internally could send mail.

Is there anything I can do that would say,  If the From: address is *@
us-reports.com and it is not from mynetworks then REJECT it?

The check_sender_access option is working great for the MAIL FROM: header,
but that isn't catching these other ones.

Thanks for any pointers on this.

Postfix version 2.2.10

Chris

Re: Spam Help Forged headers

[mouss]

Chris Funk a écrit :
> Hi All,
> 
> I am getting a lot of spam with forged addresses in the From: header.
> They are forging it with our domain addresses.  Here is an example:
> 
> Received: from localhost (localhost.localdomain [127.0.0.1
> ]) by
>  mail.us-reports.com  (Postfix) with ESMTP
> id 391E716C11F for
>  <[EMAIL PROTECTED] >; Thu, 4 Dec 2008
> 08:40:55 -0700 (MST)
> X-Virus-Scanned: amavisd-new at us-reports.com 
> Received: from mail.us-reports.com 
> ([127.0.0.1 ]) by localhost
>  (mail.us-reports.com  [127.0.0.1
> ]) (amavisd-new, port 10024) with ESMTP id
>  dBAU+DdeGeQd for <[EMAIL PROTECTED] >;
> Thu, 4 Dec 2008 08:40:50 -0700
>  (MST)
> Received: from 88-109-126-174.dynamic.dsl.as9105.com
> 
>  (88-109-126-174.dynamic.dsl.as9105.com
>  [88.109.126.174
> ]) by
>  mail.us-reports.com  (Postfix) with SMTP id
> 4541F16C135 for
>  <[EMAIL PROTECTED] >; Thu, 4 Dec 2008
> 08:40:35 -0700 (MST)
> To: <[EMAIL PROTECTED] >
> Subject: Your Order
> From: <[EMAIL PROTECTED] >
> MIME-Version: 1.0
> Importance: High
> Content-Type: text/html
> Message-ID: <[EMAIL PROTECTED]
> >
> Date: Thu, 4 Dec 2008 08:40:35 -0700
> Return-Path: [EMAIL PROTECTED] 
> 
> Here is the result of postconf | grep restrict
> 
> [EMAIL PROTECTED] postfix]# postconf | grep restrict
> 
> smtpd_client_restrictions =
> 
> smtpd_data_restrictions = reject_unauth_pipelining
> 
> smtpd_end_of_data_restrictions =
> 
> smtpd_etrn_restrictions =
> 
> smtpd_helo_restrictions = permit_mynetworks, 
>  permit_sasl_authenticated, 
>  check_helo_access hash:/etc/postfix/helo_access, reject_invalid_hostname, 
>  reject_non_fqdn_hostname, permit
> 
> smtpd_recipient_restrictions = permit_mynetworks, 
>  permit_sasl_authenticated, 

put
reject_unauth_destination
here.

>  check_sender_access hash:/etc/postfix/sender_access, 
>  reject_non_fqdn_recipient, 
>  reject_unknown_recipient_domain, 
>  reject_rbl_client sbl.spamhaus.org 

if you used zen.spamhaus.org instead, the spam would have been
blocked... the IP is litsed in xbl.

you can also use check_client_access to block
.dynamic.dsl.as9105.com REJECT blah blah



>  reject_rbl_client list.dsbl.org, 

dsbl is gone since some time now. please remove it from your configuration.

>  reject_unauth_pipelining, 

reject_unauth_pipelining is useless here. put it under
smtpd_data_restrictions.

>  reject_unauth_destination
> 
> smtpd_restriction_classes =
> ***
> /etc/postfix/sender_access
> 
> us-reports.com    554   SPAM
> 
> my.ip.add.res   554   SPAM
> 
> I tried setting up a header check that rejected anything from
>  *.us-reports.com  in the From:  
> 
> Obviously not a good thing to do as then no one internally could send mail.
> 

and you would reject mailing lists, which is bad...

> Is there anything I can do that would say,  If the From: address is
> [EMAIL PROTECTED]  and it is not from mynetworks
> then REJECT it?
> 

no. you could write a milter or a proxy_filter, but I don't think this
is worth the pain.

> The check_sender_access option is working great for the MAIL FROM:
> header, but that isn't catching these other ones.
> 
> Thanks for any pointers on this.
> 
> Postfix version 2.2.10
> 
> Chris
> 

Re: Avoiding (trivial) spoofed "mail from"

[mouss]

Roman Medina-Heigl Hernandez a écrit :
> mouss escribió:
>> Roman Medina-Heigl Hernandez a écrit :
 Why is the mail not being rejected due to
 reject_unauthenticated_sender_login_mismatch? I must have a silly bug but I
  couldn't find it...  :-(
>>> I got to solve it by:
>>> smtpd_sender_login_maps = $virtual_mailbox_maps
>>>
>> do not reuse maps this way. use a script to generate each map instead
>> (or use
>>
>> note that smtpd_sender_login_maps returns one or more logins, while
>> virtual_mailbox_maps returns the path to the mailbox.
> 
> Since I'm using Cyrus LMTP, I don't have the "path to mailbox" variable, so
> I could return whatever in $virtual_mailbox_maps. What I did was to return
> the email address (which in turn corresponds to the SASL login).
> 

I guessed that, but still... see below.

> So now it's perfectly "compatible" to use the same Mysql map for both
> variables. I mean:
> 
> hsnew:/etc/postfix# cat /etc/postfix/vuser.mysql
> # Virtual users (Mysql)
> hosts   = unix:/var/run/mysqld/mysqld.sock
> user= postfix
> password= xx
> dbname  = postfix
> query   = select user from user where user = '%s'
> 
> And in main.cf:
> virtual_mailbox_maps = mysql:/etc/postfix/vuser.mysql
> smtpd_sender_login_maps  = mysql:/etc/postfix/vuser.mysql
> 
> Ok now? :-)
> 

yes it's better! now if a new admin has to replace you, he won't get mad
trying to figure out what's really configured :)

Re: Spam Help Forged headers

[Sahil Tandon]

Chris Funk <[EMAIL PROTECTED]> wrote:

> I am getting a lot of spam with forged addresses in the From: header. They
> are forging it with our domain addresses.  Here is an example:

This has been discussed recently on the list; check the archives for 
others' opinions and solutions.

> Received: from localhost (localhost.localdomain [127.0.0.1]) by
>  mail.us-reports.com (Postfix) with ESMTP id 391E716C11F for
>  <[EMAIL PROTECTED]>; Thu, 4 Dec 2008 08:40:55 -0700 (MST)
> X-Virus-Scanned: amavisd-new at us-reports.com
> Received: from mail.us-reports.com ([127.0.0.1]) by localhost
>  (mail.us-reports.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id
>  dBAU+DdeGeQd for <[EMAIL PROTECTED]>; Thu, 4 Dec 2008 08:40:50 -0700
>  (MST)
> Received: from 88-109-126-174.dynamic.dsl.as9105.com
>  (88-109-126-174.dynamic.dsl.as9105.com [88.109.126.174]) by

% host 174.126.109.88.zen.spamhaus.org
174.126.109.88.zen.spamhaus.org has address 127.0.0.4
174.126.109.88.zen.spamhaus.org has address 127.0.0.11

You should consider rejecting email at SMTP time with the 
zen.spamhaus.org RBL.  FWIW, this IP is also listed on several 
other RBLs: http://openrbl.org/client/#88.109.126.174

Did the spam sending machine HELO with that dynamic hostname?  Several
people block such hosts with the following PCRE (from the archives) in
smtpd_helo_checks:

/\d+([-\.]\d+){3}/  REJECT  Generic hostnames prohibited. 

> Here is the result of postconf | grep restrict

Next time, 'postconf -n' instead.

> smtpd_recipient_restrictions = permit_mynetworks,
>  permit_sasl_authenticated,
>  check_sender_access hash:/etc/postfix/sender_access,

Hopefully you don't OK anyone in here; if you do, consider placing it
after reject_unauth_destination, which should anyway appear much higher
in your set of restrictions.

>  reject_non_fqdn_recipient,
>  reject_unknown_recipient_domain,
>  reject_rbl_client sbl.spamhaus.org,

Again, consider zen.spamhaus.org, which combines SBL, XBL and PBL
blocklists.

>  reject_rdbl_client list.dsbl.org,
>  reject_unauth_pipelining,

Move this to smtpd_data_restrictions; from postconf(5):

Note: reject_unauth_pipelining is not useful outside
smtpd_data_restrictions when 1) the client uses ESMTP (EHLO instead of
HELO) and 2) with "smtpd_delay_reject = yes" (the default). The use of
reject_unauth_pipelining in the other restriction contexts is therefore
not recommended. 

> smtpd_restriction_classes =
> ***
> /etc/postfix/sender_access
> 
> us-reports.com   554   SPAM
> 
> my.ip.add.res   554   SPAM
> 
> I tried setting up a header check that rejected anything from  *.
> us-reports.com in the From:
> 
> Obviously not a good thing to do as then no one internally could send mail.
> 
> Is there anything I can do that would say,  If the From: address is *@
> us-reports.com and it is not from mynetworks then REJECT it?

Place the check after permitting your networks, SASL auth'd clients, and
reject_unauth_destination.

> The check_sender_access option is working great for the MAIL FROM: header,
> but that isn't catching these other ones.

check_sender_access works on the ENVELOPE, not the HEADER.

-- 
Sahil Tandon <[EMAIL PROTECTED]>

[no subject]

[George Forman]

Hi,I have compiled 2.5.1 and installed postfix on my dev box. Everything is 
working as expected.Red Hat Enterprise Linux Server release 5.1 (Tikanga)Linux 
devserver 2.6.18-53.1.14.el5xen #1 SMP Tue Feb 19 07:33:17 EST 2008 x86_64 
x86_64 x86_64 GNU/LinuxI installed the same version on a second box (and go 
through the same configuration/setup procedures).Red Hat Enterprise Linux 
Server release 5.2 (Tikanga)Linux serverA 2.6.18-92.1.1.el5 #1 SMP Thu May 22 
09:01:47 EDT 2008 x86_64 x86_64 x86_64 GNU/LinuxWhen I enable TLS, I get the 
following error.Dec  3 15:56:23 serverA postfix/tlsmgr[4776]: 
tls_prng_dev_open: opened entropy device /dev/urandomDec  3 15:56:23 serverA 
postfix/tlsmgr[4776]: set_eugid: euid 89 egid 89Dec  3 15:56:23 serverA 
postfix/tlsmgr[4776]: fatal: tls_prng_exch_open: cannot open PRNG exchange file 
/opt/zimbra/postfix-2.5.1/data/prng_exch: Permission deniedDec  3 15:56:24 
serverA postfix/master[4704]: warning: process 
/opt/zimbra/postfix-2.5.1/libexec/tlsmgr pid 4776 exit status 1Dec  3 15:56:24 
serverA postfix/master[4704]: warning: 
/opt/zimbra/postfix-2.5.1/libexec/tlsmgr: bad command startup -- throttlingI've 
read where SELinux has been an issue. However, serverA system's SELinux is 
disabled. cat /etc/selinux/config# This file controls the state of SELinux on 
the system.# SELINUX= can take one of these three values:#   enforcing - 
SELinux security policy is enforced.#   permissive - SELinux prints 
warnings instead of enforcing.#   disabled - SELinux is fully 
disabled.SELINUX=disabled# SELINUXTYPE= type of policy in use. Possible values 
are:#   targeted - Only targeted network daemons are protected.#   
strict - Full SELinux protection.SELINUXTYPE=targeted# SETLOCALDEFS= Check 
local definition changesSETLOCALDEFS=0 I have confirmed that 
/opt/zimbra/postfix-2.5.1/data directory ownership and permissionsare the same 
on both boxes.drwx--2 postfix  root 4096 Dec  3 15:15 dataAny 
help is greatly appreciated!!
_
Suspicious message? There’s an alert for that. 
http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_broad2_122008

Sender = Receiver?

[Christian Desrochers]

Hi all,

We have a spam problem. We get a lot of emails, where the sender (MAIL FROM)
address is equal to the receiver (RCPT TO) address. When I look at the
"Received:" header field, the IP address of the server it's coming from, is
not  our mail server.

I would like to know if there is a way to block (or tag as spam) those
emails, either with Postfix, SpamAssassin or Procmail, if they don't come
from our mail server?

Thanks,

Chris

Re: Sender = Receiver?

[Sturgis, Grant]

On Thu, 2008-12-04 at 11:51 -0700, Christian Desrochers wrote:
> Hi all,
> 
> We have a spam problem. We get a lot of emails, where the sender (MAIL
> FROM) address is equal to the receiver (RCPT TO) address. When I look
> at the "Received:" header field, the IP address of the server it's
> coming from, is not  our mail server.
> 
> I would like to know if there is a way to block (or tag as spam) those
> emails, either with Postfix, SpamAssassin or Procmail, if they don't
> come from our mail server?
> 
> Thanks,
> 
> Chris

Have you read the archives for the past few days?  There has been
extensive discussion on this very issue.










This electronic message transmission is a PRIVATE communication which
contains information which may be confidential or privileged. The
information is intended to be for the use of the individual or entity
named above. If you are not the intended recipient, please be aware that
any disclosure, copying, distribution or use of the contents of this
information is prohibited. Please notify the sender  of the delivery
error by replying to this message, or notify us by telephone
(877-633-2436, ext. 0), and then delete it from your system.

Re: Sender = Receiver?

[J.P. Trosclair]

Christian Desrochers wrote:

Hi all,

We have a spam problem. We get a lot of emails, where the sender (MAIL FROM)
address is equal to the receiver (RCPT TO) address. When I look at the
"Received:" header field, the IP address of the server it's coming from, is
not  our mail server.

I would like to know if there is a way to block (or tag as spam) those
emails, either with Postfix, SpamAssassin or Procmail, if they don't come
from our mail server?

Thanks,

Chris



This has been the popular topic for the past few days. You can block it 
with postfix using something like this:


smtpd_recipient_restrictions =
permit_sasl_authenticated
permit_mynetworks
reject_unauth_destination
reject_unlisted_recipient
check_sender_access hash:/etc/postfix/sender_access  # Look Here
reject_non_fqdn_recipient

/etc/postfix/sender_access:
.my_domain.ext REJECT Rejection reason here
[EMAIL PROTECTED] REJECT Not authenticated

There are pitfalls to using this approach. Forwarded mail from another 
server will be rejected, for example. Thus, there are cases where you 
get false positives. It's up to you to make the decision of what's 
acceptable and what not. You can implement it on a per-user basis as 
well which is what I'm really doing. I chose to inform the users of the 
change and let them opt-in after knowing the potential risks. I can't 
help you with solving the problem from spamassassin or procmail.


J.P.

Re: Testing SASL HOWTO using telnet/Postfix/dovecot?

[Magnus Bäck]

On Wednesday, December 03, 2008 at 23:06 CET,
 "Roderick A. Anderson" <[EMAIL PROTECTED]> wrote:

> Magnus Bäck wrote:

[...]

> > You can choose any username you like as long as it matches whatever
> > is in your credential database. So far we don't know anything about
> > that. MySQL, sasldb, LDAP, what?
> 
> smtpd_sasl_type = dovecot

Yes, but how does Dovecot store the credentials? But never mind, let's
see some logs from the failed authentication attempt.

> > Why do you insist on testing this with telnet? You will introduce
> > another possible error source (incorrect encoding of the credentials)
> > and it's a use case that you're supposedly not really interested in.
> 
> Because I can do it one step at a time and see the results that
> Postfix sends back.  I hadn't thought of telnet possibly munging
> base64 encoded values.  They looked like ASCII-only to me.

Telnet won't munge your encoded credentials (they are indeed pure ASCII),
but you may do the encoding incorrectly or mess up in some other way.
We've seen that on the list quite a few times, so I'd recommend using a
real MUA for this testing.  Postfix will log everything that's relevant
anyway.

But it's a good instinct you've got -- generally it's of course good to
introduce complexity gradually and module test things separately
before you put them together.

> > Useless since local_transport != local.
> 
> Thanks.  This was built by looking at _many_ HOWTOs and documentation
> pages and based on a working non-virtual main.cf file.

Sadly many how to documents are written by people who aren't that
very knowledgable.

[...]

-- 
Magnus Bäck
[EMAIL PROTECTED]

Re: Sender = Receiver?

[Sturgis, Grant]

On Thu, 2008-12-04 at 12:05 -0700, Christian Desrochers wrote:
> Hi, 
> 
> Thanks for you reply. Where can I read the archives, please?
> 
> Christian

Have you tried Google?

> 
> 
> 
> On Thu, Dec 4, 2008 at 1:53 PM, Sturgis, Grant
> <[EMAIL PROTECTED]> wrote:
> 
> On Thu, 2008-12-04 at 11:51 -0700, Christian Desrochers wrote:
> > Hi all,
> >
> > We have a spam problem. We get a lot of emails, where the
> sender (MAIL
> > FROM) address is equal to the receiver (RCPT TO) address.
> When I look
> > at the "Received:" header field, the IP address of the
> server it's
> > coming from, is not  our mail server.
> >
> > I would like to know if there is a way to block (or tag as
> spam) those
> > emails, either with Postfix, SpamAssassin or Procmail, if
> they don't
> > come from our mail server?
> >
> > Thanks,
> >
> > Chris
> 
> 
> Have you read the archives for the past few days?  There has
> been
> extensive discussion on this very issue.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> This electronic message transmission is a PRIVATE
> communication which
> contains information which may be confidential or privileged.
> The
> information is intended to be for the use of the individual or
> entity
> named above. If you are not the intended recipient, please be
> aware that
> any disclosure, copying, distribution or use of the contents
> of this
> information is prohibited. Please notify the sender  of the
> delivery
> error by replying to this message, or notify us by telephone
> (877-633-2436, ext. 0), and then delete it from your system.
> 

This electronic message transmission is a PRIVATE communication which
contains information which may be confidential or privileged. The
information is intended to be for the use of the individual or entity
named above. If you are not the intended recipient, please be aware that
any disclosure, copying, distribution or use of the contents of this
information is prohibited. Please notify the sender  of the delivery
error by replying to this message, or notify us by telephone
(877-633-2436, ext. 0), and then delete it from your system.

Re: Sender = Receiver?

[Duane Hill]

On Thu, 4 Dec 2008, Sturgis, Grant wrote:


On Thu, 2008-12-04 at 12:05 -0700, Christian Desrochers wrote:

Hi,

Thanks for you reply. Where can I read the archives, please?

Christian


Have you tried Google?


postfix.org is a good place too. You don't even need to search for them. 
http://www.postfix.org/lists.html shows these list archives:


   http://archives.neohapsis.com/archives/postfix/
   http://news.gmane.org/index.php?prefix=gmane.mail.postfix
   http://groups.yahoo.com/group/postfix-users/
   http://groups.google.com/group/list.postfix.users
   http://marc.theaimsgroup.com/?l=postfix-users
   http://archive.netbsd.se/

Re: Sender = Receiver?

[Christian Desrochers]

Nice, thank you. That is a nice answer! :)

Chris



On Thu, Dec 4, 2008 at 3:49 PM, Duane Hill <[EMAIL PROTECTED]> wrote:

> On Thu, 4 Dec 2008, Sturgis, Grant wrote:
>
>  On Thu, 2008-12-04 at 12:05 -0700, Christian Desrochers wrote:
>>
>>> Hi,
>>>
>>> Thanks for you reply. Where can I read the archives, please?
>>>
>>> Christian
>>>
>>
>> Have you tried Google?
>>
>
> postfix.org is a good place too. You don't even need to search for them.
> http://www.postfix.org/lists.html shows these list archives:
>
>   http://archives.neohapsis.com/archives/postfix/
>   http://news.gmane.org/index.php?prefix=gmane.mail.postfix
>   http://groups.yahoo.com/group/postfix-users/
>   http://groups.google.com/group/list.postfix.users
>   http://marc.theaimsgroup.com/?l=postfix-users
>   http://archive.netbsd.se/
>

Re: Testing SASL HOWTO using telnet/Postfix/dovecot?

[Roderick A. Anderson]

Magnus Bäck wrote:

On Wednesday, December 03, 2008 at 23:06 CET,
 "Roderick A. Anderson" <[EMAIL PROTECTED]> wrote:


Magnus Bäck wrote:


[...]


You can choose any username you like as long as it matches whatever
is in your credential database. So far we don't know anything about
that. MySQL, sasldb, LDAP, what?

smtpd_sasl_type = dovecot


Yes, but how does Dovecot store the credentials? But never mind, let's
see some logs from the failed authentication attempt.


Thanks for the help.  I'm going to have to back-burner this for a bit.
Until I get the server set up the way it should be instead of my kludged
setup.


Rod



Why do you insist on testing this with telnet? You will introduce
another possible error source (incorrect encoding of the credentials)
and it's a use case that you're supposedly not really interested in.

Because I can do it one step at a time and see the results that
Postfix sends back.  I hadn't thought of telnet possibly munging
base64 encoded values.  They looked like ASCII-only to me.


Telnet won't munge your encoded credentials (they are indeed pure ASCII),
but you may do the encoding incorrectly or mess up in some other way.
We've seen that on the list quite a few times, so I'd recommend using a
real MUA for this testing.  Postfix will log everything that's relevant
anyway.

But it's a good instinct you've got -- generally it's of course good to
introduce complexity gradually and module test things separately
before you put them together.


Useless since local_transport != local.

Thanks.  This was built by looking at _many_ HOWTOs and documentation
pages and based on a working non-virtual main.cf file.


Sadly many how to documents are written by people who aren't that
very knowledgable.

[...]

Re: Spam Help Forged headers

[Chris Funk]

On Thu, Dec 4, 2008 at 11:20 AM, Sahil Tandon <[EMAIL PROTECTED]> wrote:

> Chris Funk <[EMAIL PROTECTED]> wrote:
>
> <..snip>
> > Obviously not a good thing to do as then no one internally could send
> mail.
> >
> > Is there anything I can do that would say,  If the From: address is *@
> > us-reports.com and it is not from mynetworks then REJECT it?
>
> Place the check after permitting your networks, SASL auth'd clients, and
> reject_unauth_destination.
>
> > The check_sender_access option is working great for the MAIL FROM:
> header,
> > but that isn't catching these other ones.
>
> check_sender_access works on the ENVELOPE, not the HEADER.
>
> --
> Sahil Tandon <[EMAIL PROTECTED]>
>
Thanks for all the information Sahil.

How would I

<

Re: Spam Help Forged headers

[Sahil Tandon]

Chris Funk <[EMAIL PROTECTED]> wrote:

> On Thu, Dec 4, 2008 at 11:20 AM, Sahil Tandon <[EMAIL PROTECTED]> wrote:
> 
> > Chris Funk <[EMAIL PROTECTED]> wrote:
> >
> > <..snip>
> > > Obviously not a good thing to do as then no one internally could send
> > mail.
> > >
> > > Is there anything I can do that would say,  If the From: address is *@
> > > us-reports.com and it is not from mynetworks then REJECT it?
> >
> > Place the check after permitting your networks, SASL auth'd clients, and
> > reject_unauth_destination.
> >
> > > The check_sender_access option is working great for the MAIL FROM:
> > header,
> > > but that isn't catching these other ones.
> >
> > check_sender_access works on the ENVELOPE, not the HEADER.
> >
> > --
> > Sahil Tandon <[EMAIL PROTECTED]>
> >
> Thanks for all the information Sahil.
> 
> How would I
> 
> < reject_unauth_destination.

Search this mailing list's archives for examples; this and related
topics have been discussed several times over the last few days.

> Will the smtpd_*_restrictions  work on headers?

I don't think so.

-- 
Sahil Tandon <[EMAIL PROTECTED]>

Re: Spam Help Forged headers

[mouss]

Chris Funk a écrit :
> 
> How would I  
> 
> < reject_unauth_destination.
> 
> Will the smtpd_*_restrictions  work on headers?
> 

no.