Re: postfix+dspam+content_filter

[mouss]

Marcin Rzepecki a écrit :
> Hello, 
> 
> I have configured DSPAM to act as a deamon and bind it to Postfix via
> LMTP:
> # forward to dspam
> smtp  inet   n  -   n   -   -   smtpd
>-o content_filter=lmtp:unix:/var/run/dspam/sock
> # back route from dspam
> 127.0.0.1:10026 inet  n -   n   -   -smtpd
>   -o content_filter= -o smtpd_authorized_xforward_hosts=127.0.0.0/8
>   -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
> 
> It works fine, but such configuration makes Postfix to filter all messages 
> that 
> are relayed to other domains too. That produces unneeded load and makes
> dspam to create new databases depend on message recipient, so it's very
> bad behavior :)
> How to make to filter only incoming mail for specific domains (e.g. from
> $my_destination) and let the other to be relayed without any checks?
> 


[methdo 1]
configure dspam... for example, if using mysql as a backend, don't set
AUTO_INCREMENT in the "virtual users" table, or don't give dspam write
access to this table. dspam may complain in logs, but it's ok.

[method 2]
if you want skip filtering when mail comes from mynetworks when the user
was authenticated:

smtpd_sender_access =
check_client_access pcre:/etc/postfix/filter_msa
permit_mynetworks
permit_sasl_authenticated
check_client_access pcre:/etc/postfix/filter_default

== filter_msa:
/./ FILTER relay:[127.0.0.1]:10026

== filter_default
/./ FILTER lmtp:unix:/var/run/dspam/sock


[method 3]
if you want per recipient filtering, setup multiple instances and use
transport_maps to pass mail to the filter (no content_filter setting).

The reason this won't work with a single instance using content_filter
(or FITER) is because if mail has multiple recipients, only one filter
is selected.

Re: outbound spam filtering

[mouss]

David Koski a écrit :
> An ISP that I do work for recently had an acocunt on their CommuniGatePro 
> server hijacked by a spammer.  Of course this got them on the blacklist of 
> AOL, Yahoo and others.  There are three inbound Postfix relay servers for 
> blacklisting that are in front of three Barracuda spam filters.  I am trying 
> to come up with a way to use the inbound Postfix relay servers for 
> controlling outbound email.  Is there a way to limit email from a single 
> sender per day or per hour with Postfix used as a relay?  

you can use the throttle functionality of policyd (v1):
http://www.policyd.org
(there's a V2, rewritten in perl, but I never tried it, so I can't tell
much).

alternatively, you can have a script that parses logs and populates an
access map. This requires work but will be more flexible as you can mix
multiple heuristics to detect abuse. It also doesn't interfere with the
mail flow.


> How effective would 
> Postfix/Amavis/Clam/Spamassassin be for stopping abuse?
> 

- clamav would be good if you have enough resources. you can use it from
amavisd-new or from clamsmtpd (less flexible, but it's less expensive).
you can add non official signatures (sanesecurity, msrbl) to detect more
junk.

- spamassassin, besides being expensive, is developped for inbound mail
(this is actually true for most content filters). if you use it, you'll
need to disable such checks. for example:
- Bayes (this is hard to use in an ISP environment, be that for inbound
or outbound). Bayes is unusable without correct training.
- AWL
- most DNSBL checks
- ...


- You can use URIBL/SURBL via a milter:
http://www.snertsoft.com/sendmail/milter-link/

Re: A little OT: SPF

[mouss]

Tolga a écrit :
> Hello,
> 
> For an e-mail not to fall into spam category, the sourcing server has to
> have SPF record I think, or so I've been told. 

No.

$ host -t txt postfix.org
postfix.org has no TXT record
$ host -t txt yahoo.com
yahoo.com has no TXT record
$ host -t txt mail.com
mail.com has no TXT record

and so on.

hotmail "recommend" that you set SPF (even sender-id) but that doesn't
really guarantee that your mail won't disappear...

> How do I check whether it has a SPF record or not?

$ host -t txt ozses.net
ozses.net has no TXT record

so this domain does not have an SPF record.

$ host -t txt ietf.org
ietf.org descriptive text "v=spf1 ip4:64.170.98.0/26 ip4:64.170.98.64/28
ip4:64.170.98.80/28 ip4:64.170.98.96/29 ip4:208.66.40.224/27
ip6:2001:1890:1112:1::0/64 -all"

you can try gmail.com, hotmail.com, ... etc.

Please check
http://www.openspf.org/
or other SPF related sites.

Re: Problem with alias Lists

[mouss]

Helmut Weigel a écrit :
> Hi all,
> 
> I have a wiered problem with alias lists in Postfix
> 
> We use aliases for our internal mailing lists (departmnents for instance).
> We use an OpenLDAP for the Userbase. Normally everything is ok.
> 
> But if one recipient out of this list is over Quota Postfix
> keeps the message in the mailq not only for the one recipient
> but for the original used alias.
> 
> So the mail gets deliverd twice or more times to all other
> recipients until the one box over quota is emtied or the mail
> is deletet from mailq.
> 
> Do you have any ideas? Where schould I have a closer look to?
> 

how do you deliver mail? unless you use lmtp, you should deliver one
recipient at a time. if you use lmtp, your lmtp delivery agent should
handle the situation correctly.

Re: Postfix and DNSSEC

[mouss]

Bernhard Fischer a écrit :
> I'd like to use DNSSEC with Postfix.
> I did some research on the web but although DNSSEC is there nobody really 
> cares about it.
> The most recent patch for Postfix is for release 2.3 and is based on libs 
> (libval, libsres) I didn't find any download page for.
> 
> Is there any recent development going on?
> 


given that DNSSEC was proposed a long time ago, but has not been
adopted, I don't see any reason why this would change.

My opinion is that dnssec was proposed at "that time" means that it is
"obsolete" (at that time, most people wanted "pki", spoke "perimeter
security", ...).

and anyway, dnssec is about dns. the place to implement it is in dns
servers and resolvers. not in MTAs or web servers...

Re: AW: Problem with alias Lists

[mouss]

Helmut Weigel a écrit :
> we use lmtp with cyrus imapd
> 


- how are the aliases implemented? are they implemented in postfix or in
another program?
- how are quota checks implemented?
- show some logs?
- ...

Re: Can content_filter take a map as an argument?

[mouss]

jeff_homeip a écrit :
> --- In postfix-us...@yahoogroups.com, Sahil Tandon  wrote:
>> jweinbergerhj wrote:
>>
>>> I know it's a simple question...but doea any know if this:
>>>
>>> content_filter=hash:/path/to/table (or mysql:/path/to/filters.cf)
>>>
>>> will work? 
>> No.  From postconf(5):
>>
>>  content_filter (default: empty)
>>
>>   The name of a mail delivery transport that filters mail after it is
>>   queued.
>>
>>   This parameter uses the same syntax as the right-hand side of a
>>   Postfix transport(5) table. This setting has a lower precedence 
>>   than a content filter that is specified with an access(5) table or 
>>   in a header_checks(5) or body_checks(5) table.
>>
>>> I'm trying to test some new content filters and want to be able to
> apply them per
>>> domain or per address (recipient) for my test and personal domains
> before I make them
>>> standard.
>> You could use check_recipient_access; example:
>>
>> /etc/postfix/main.cf:
>> smtpd_recipient_restrictions =
>>  ..
>>  check_recipient_access hash:/etc/postfix/filters
>>  ..
>>
>> /etc/postfix/filters
>> recipi...@...FILTER foo:bar
>>
>> There are some caveats and limitations; for more information see:
>> http://www.postfix.org/access.5.html
>> http://www.postfix.org/FILTER_README.html
>>
>> -- 
>> Sahil Tandon 
>>
> Sahil
> 
> Thanks!!
> 
> I read "This parameter uses the same syntax as the right-hand side of
> a Postfix transport(5) table" as meaning it can take the same syntax
> as transport_maps, i.e. a table. Maybe not.

no. the syntax is that of the RIGHT-HAND SIDE of transport_maps.
content_filter isn't a map.

> 
> check_recipient_access works fine, 


I hope you are aware that per-recipient FILTER is "fragile": if the
message is sent to multiple recipients, the last FILTER is used (a
message is passed to a single filter. it is not split).

> but it is problematic for me, as
> the messages get passed to the content filter before alias
> translation, which causes problems with aliases that map to virtual
> mailboxes.
> 

you can expand aliases before or after the filter. it's your choice. but
make sure to only enable rewrite once in a mail path (otherwise, you may
get duplicates if a virtual alias is expanded twice)

> Also I would need check_recipient_access to be a mysql: table (which
> it can be), but I don't know how to control the matching order in a
> mysql table lookup - any ideas?
> 

postfix lookup order is independent of the map type.

> Do you (or anyone) have any ideas on how to overcome this?
> 
> I also came up with another way to do this...does anyone have any
> thoughts on how this will work?
> 
> Make the content filter into the transport using transport_maps. Then
> when the content filter injects the messages back into postfix, use
> master.cf -o transport_maps to override and make the actual transport
> maps effective.
> 
> Will that work?
> 

not with a single instance. transport_maps are global in an instance. so
you would create a loop.

but if you want per recipient filtering, then your best choice is to use
 different postfix instances (run postfix twice. not add smtpd listeners
to a single master.cf). then you don't need content_filter at all. you
can use transport_maps instead. the advantage is that this works "as
intended" in the case of multiple recipients.

> Thanks for your help!
> 
> --Jeff
> 

Re: postfig confiuration advice/info

[mouss]

KLaM Postmaster a écrit :
> First of all let me apologize if you have seen this "request/query"
> before.  I originally posted this to Google Groups
> "mailing.postfix.users", but felt that that it was probably the wrong
> place to ask for advice. I  then tried the Postfix oriented groups on my
> news service, only to realize that the latest post other than mine was 3
> weeks ago (time to get a new news service or am I seeing the end of NNTP).
> 
> I am very new to postfix and am looking for advice on my my postfix
> configuration (see below), the configuration is aimed at a small group
> of people (less than 25 users) who are all volunteers at a local not for
> profit organization. The server is setup with no local users, and all
> mail is delivered to virtual mailboxes.
> 
> 1) I am using RBL + RBHL + amavis-new + spamassassin + clamv + 
> greylisting as anti-spam defenses.
> Question: are the header and body checks still worthwhile as anti-spam
> defenses?  I can see the use of header checks for removing unwanted
> stuff, like the various headers that get inserted during spam processing
> are there any other worth while uses, if so what and where can I find
> more information.

some uses of header and body checks:
- reject "banned attachments"
- detect forged Received headers
- detect some backscatter (see the BACKSCATTER README)

but they are not a "general" content filter. see the limitations in the
docs.

> 
> On the subject of RBL servers does anybody have any suggestions as the
> RBL lists to use or avoid. I am currently using bl.spamcop.net,
> zen.spamhaus.org, list.dsbl.org all of which seem to work well.
> 

remove list.dsbl.org. it's no more active. use zen before spamcop. you
will then probably realize that spamcop doesn't catch enough spam thatis
not caught by zen.


> 2) a lot of the configuration advice/tutorials/how-to's that I have
> looked at put all the checks into the smtpd_recipient_restrictions.
> Why defer killing spam, why not kill it ASAP and save spending anymore
> resources processing it?
> I know that smtpd_delay_reject parameter defaults to yes, therefore all
> checks are deferred until recipient. But that just leads me to the same
> question.
> 
> 2a) have set the smtp_delay_reject = no, should I, am I giving myself a
> problem by doing this?
> 

yes.

- some smtp implementations are "too strict" about error codes. they
will generally retry if you reject them before RCPT stage.

- when rejecting at RCPT stage, you have more infos. so you can assess
your FPs...

- how much do you gain in rejecting at connection time instead of RCPT
time. exceptionally if the client retries.

- most people use the default setup. so this is the setup that has been
widely tested and validated. if you use a less common setup, you run the
risks to find problems that were undetected. for example, there is a
known problem with sender check in smtpd_recipient_restrictions if you
set smtpd_delay_reject to no. (search the archives if interested).


> 2b) based on some things I read here, it would seem that I should add
> permit_sasl_authenticated to each of the smtp_*_restriction sections is
> this correct?
> 

if you want to whitelist (be that sasl authenticated users or mynetworks
or other), you need to do that before any reject in any restriction.
This is why putting your checks under smtpd_recipient_restrictions is
good (you don't need to repeat the permit_*).

> 2c) I was originally advised to have unknown_local_recipient_reject_code
> = 554 but in a couple of places I have seen it set to 550, which is better?

550 "means": Requested action not taken: mailbox unavailable.
so is better.


> Supplementary, is there a list of codes, if so where?

the codes are defined in the RFCs ;-p

#postconf -d | grep unknown_
...
unknown_local_recipient_reject_code = 550
unknown_relay_recipient_reject_code = 550
unknown_virtual_alias_reject_code = 550
unknown_virtual_mailbox_reject_code = 550
...

> 
> 3) Is it possible to replace the virtual_mailbox_maps =
> hash:/etc/postfix/vmailbox with something like proxy maps such as 
> virtual_mailbox_maps =  proxy:unix:passwd.byname and if so how would 
> implement this using Dovecot as the LDA/ MDA?
> 

virtual_mailbox_maps is for addresses in virtual_mailbox_domains.
passwd.byname is for unix users. do not mix these.

> 4) Are there any gotcha's in the config below.

The "tradition" here is to show output of 'postconf -n' instead of
main.cf. but I'm skipping it anyway...

Re: postfig confiuration advice/info

[mouss]

KLaM Postmaster a écrit :
> mouss wrote:
>> some uses of header and body checks:
>> - reject "banned attachments"
>> - detect forged Received headers
>> - detect some backscatter (see the BACKSCATTER README)
> I gather that all of these are well described in the BACKSCATTER README, are 
> there any other sources that might be worth a look?
> 
>> your FPs...
>>   
> Sorry for being dumb, but what are FPs?

False Positive. in spam filtering context, an FP is when your filter
mis-classifies a legitimate message as spam.

>> - most people use the default setup. so this is the setup that has been
>> widely tested and validated. 
>>   
> My trouble here was that I haven't found a consistent default setup.

I was referring to smtpd_delay_reject=yes.

> The setup that came with my Linux distribution was designed for the
> local desktop machine and did not seem to be suitable for a server.
>> the codes are defined in the RFCs ;-p
>>   
> OK, I should have known that.  :-!
>>> 3) Is it possible to replace the virtual_mailbox_maps =
>>> hash:/etc/postfix/vmailbox with something like proxy maps such as 
>>> virtual_mailbox_maps =  proxy:unix:passwd.byname and if so how would 
>>> implement this using Dovecot as the LDA/ MDA
>> virtual_mailbox_maps is for addresses in virtual_mailbox_domains.
>> passwd.byname is for unix users. do not mix these.
>>   
> Sorry, I asked my question poorly and provided an even poorer exemplar.
> My objective here was to see if there was some way of avoiding having
> two lists of addresses/mail boxes, the vmailbox table and the Dovecot
> user_db file.

Use a db type that is supported by both postfix and dovecot.

> What I was trying to get at is that Dovecot has a look up function for
> addresses using its auth_master function. Is that accessible from
> Postfix, and if so how?

'postconf -n' will tell you which map types your postfix supports. but
dovecot-auth is not one of them.

> I am trying to make this easy to administer for a total non-techie, as I
> may not be around.

you could try mysql.

>>   
>> The "tradition" here is to show output of 'postconf -n' instead of
>> main.cf. but I'm skipping it anyway...
>>   
> I did that, but the output seemed bigger than the stuff I appended, but
> if the convention is "postconf -n" then I will do that in future, thanks
> for the heads up.
> Etiquette question, should I post to the mailing list alone or to both
> the list and the respondent (in this case mouss).

depends on people. I personally don't care.

Re: DNSWL

[mouss]

Adrian Overbury a écrit :
> Does anyone here make use of the DNS Whitelist?  If so, what's your
> experience with it?  Do you find it helpful in speeding up the delivery
> of legitimate mail, 

I use it to avoid FPs, not to speed up delivery.

> or does it just increase the amount of spam you
> receive? 

Not that I noticed. but if you see spam from a listed IP, you can report
it to dnswl.

> Also, do you find it more useful to use it as part of a
> spamassassin check, or as part of the SMTP transaction?  I'm interested
> in any info you can provide.
> 

I use it in postfix, before spamhaus zen and other checks (but after
local client ACLs, so if I don't like an IP, I can still block it).

I also use it in SA, where it is on by default.

and I recommend that people with IPs that may be blocked submit these
IPs to dnswl. In particular, those having a "dynamic-like" reverse dns.

Re: Problems running multiple instances of postfix on same host

[mouss]

Darren Pilgrim a écrit :
> Rob Tanner wrote:
>> Hi,
>>
>> I need to run a separate instance of postfix in order to accommodate a
>> FAX server.  I created the directory /etc/postfix/fax and copied and
>> customized the main.cf and master.cf files from the default directory
>> to this new directory.  I also copied post-install, postfix-files and
>> postfix-script.  I also crated the directory
>> /var/spool/postfix/pid/fax for the pid files and explicitly declared
>> it in main.cf (process_id_directory = /var/spool/postfix/pid/fax). 
>> When I do an initial attempt to start the postfix instance, I get a
>> message that postfix is already running.  Note, also, that the message
>> says postfix/postfix-script rather than postfix/fax/postfix-script.
>>
>> [r...@neskowin ~]# postfix -c /etc/postfix/fax start
>> postfix/postfix-script: fatal: the Postfix mail system is already running
>> [r...@neskowin ~]#
>>
>> I'm running Postfix 2.2.10.  Is there something more I need to do in
>> the setup to get this second instance running?
> 
> You need separate queue_directory and data_directory locations for each
> instance.  process_id_directory is defined relative to queue_directory.
> 
> On a side note, are you sure you really need a second instance?  Extra
> services can be enabled in master.cf and you can override with the -o
> flag pretty much anything you can specify in main.cf.

you can't "override" transport_maps...

Re: Backup MX for multiple domains

[mouss]

DJ Lucas a écrit :
> Hi guys, I believe that I already have the answer to this pretty basic
> setup, but I just wanted to do a quick sanity check.
> 
> I'm setting up a backup MX, and for one of the domains that it will
> relay to, it should do no filtering whatsoever as there is a Symantec
> device in front of the primary.  The device is configured with a
> catch-all, and I have verified that no backscatter is generated when
> sending to an invalid address, and the admin of that server wants to
> review everything coming at him.
> 

the question is: does the symantec device reject spam or does it "tag
and deliver" or "quarantine". it should not reject mail since you have
accepted it.

> The other three domains are very small, servicing less than 80 users
> total.  I had planned to validate the recipient addresses via hash
> tables...I can automatically generate these..in fact probably only one
> table need be present for (I think) only something like 74 users.
> 
> Anyway, in addition to the default configuration, I plan to add the
> following:
> 
> /etc/postfix/transport:
> example.com   relay:[primary.example.com]
> example1.com   relay:[primary.example1.com]
> example2.com   relay:[primary.example2.com]
> example3.com   relay:[primary.example3.com]
> 
> /etc/postfix/example.com:
> example.com   OK
> 
> /etc/postfix/otherdomains:
> us...@example1.com   OK
> us...@example3.com   OK
> us...@example2.com   OK
> us...@example1.com   OK
> ...
> use...@example2.com   OK
> 
> 
> main.cf:
> # Begin /etc/postfix/main.cf
> ...
> # Domains to accept mail for.
> relay_domains = example.com, example1.com, example2.com, example3.com
> 
> # IP address is currently unknown (will be replaced with real when
> determined)
> proxy_interfaces = 0.0.0.0
> 
> # Map recipient addresses to the primary MX
> transport_maps = hash:/etc/postfix/transport
> 
> # Validate recipients (except for example.com) and do normal checks
> smtpd_recipient_restrictions =
>check_recipient_access hash:/etc/postfix/example.com,
>reject_non_fqdn_sender,
>reject_unauth_pipelining,

this is useless.

>reject_non_fqdn_recipient,

put reject_unauth_destination here.

>reject_rbl_client b.barracudacentral.org,
>reject_rbl_client zen.spamhaus.org,
>check_policy_service unix:postgrey/socket,
>check_recipient_access hash:/etc/postfix/otherdomains,
>reject_unauth_destination,
>reject_unknown_recipient_domain

This is useless.

> ...
> # End /etc/postfix/main.cf
> 
> It just seems entirely too simple.  Does that config work like I think
> it will, or am I off in La La land?  Also, this server will handle no
> mail locally.  I explicitly ignored 'permit_mynetworks'.  I simply use
> the internal domain name of the site that it is at, since it is not
> resolvable from the outside world (backupmx.mailhost.local). 
> Additionally, I did not use relay_recipient_maps, is it still required
> with the suggested configuration?
> 


without relay_recipient_maps, anyth...@example1.com will be accepted.
you can use:

relay_recipient_maps = hash:/etc/postfix/otherdomains

after adding:

@example.com   OK

to that file. (this entry won't match a check_recipient_access. so it
changes nothing to your checks).

Re: postfix + procmail autoresponder

[mouss]

Christian Desrochers a écrit :
> Hi all,
> 
> My office will be closed for the Christmas holidays and I would like to
> set up an mail autoresponder that will send back a notice to the sender
> for every mail sent at @our_domain.com .
> 
> What I really want is to reply to sender saying we are closed and will
> be back on Jan 5th. More, I want the received email to be delivered to
> the final recipient, so this one can follow up when he or she is back.
> 
> I found a website giving a procmail receipe that sounds good. I am just
> wondering if I have to add anything else to it, so the mail is delivered
> to the final user? Do you guys know an other way to set up a mail
> autoresponder, using postfix? Here is the website:
> http://www.knowplace.org/pages/howtos/autoresponder_with_procmail_howto.php


This is a broken responder. it will reply to mailing-lists... etc.

find a better one. to get help, provide infos on what kind of delivery
you use (local or virtual), whether you use dovecot, maildrop, ... etc.

Re: postfix + procmail autoresponder

[mouss]

Christian Desrochers a écrit :
> Allright, you guys are right. I talked with the management, and we will
> use the 'vacation' program for those who really need an auto-reply,
> a.k.a. people dealing with customers. Since 'vacation' only send one
> email per sender, it'll do the trick.
> 

vacation is a better solution.

if you have a spam filter, you should not auto-respond to spam.

Re: Backup MX for multiple domains

[mouss]

DJ Lucas a écrit :
> mouss wrote:
>> the question is: does the symantec device reject spam or does it "tag
>> and deliver" or "quarantine". it should not reject mail since you have
>> accepted it.
> Honestly, I'm not even sure what device he has, in fact, I'm not
> familiar with any Symantec hardware products.  :-/  That said, for the
> site in question, I've manually thrown a few obvious (or rather self
> written to what I believe to be obvious) spam messages at it, and have
> not been able to get a 4xx or 5xx response from it.  I've even went so
> far as to test simulated backscatter messages, and nil.  It seems that
> as long as the @example.com part matches, it accepts everything.  In
> early testing, those probing messages were followed by the admin's
> response of "Should I have received this?" indicating that the catchall
> is doing it's job.
> While I think that I am capable of being fairly creative, and just a bit
> OT, is there any type of pre-made tool out there to test the
> effectiveness of a spam filter?  If so, then I could throw that at it
> and see what I get.
> 

you can test with EICAR and GTUBE:

http://en.wikipedia.org/wiki/Eicar
http://en.wikipedia.org/wiki/GTUBE


but testing is not enough: the admin could change his setup. so you must
have an agreement that is documented (so that if the admin is
replaced..., a new admin knows what not to do).

> 
>>>reject_unauth_pipelining,
>>> 
>>
>> this is useless.
>>
>>   
> It will be removed. Thanks.
>>>reject_non_fqdn_recipient,
>>> 
>>
>> put reject_unauth_destination here.
>>
>>   
> before the RBLs..save both processing and bandwidth. Good catch.  

it's also safer. you don't risk becoming an open relay in case of a bad
entry in a map...

>>>reject_unknown_recipient_domain
>>> 
>>
>> This is useless.
>>
>>   
> OK
>>> ...
>>> # End /etc/postfix/main.cf
>>>
>>>
>>> 
> 
>> without relay_recipient_maps, anyth...@example1.com will be accepted.
>> you can use:
>>
>> relay_recipient_maps = hash:/etc/postfix/otherdomains
>>
>> after adding:
>>
>> @example.com   OK
>>
>> to that file. (this entry won't match a check_recipient_access. so it
>> changes nothing to your checks).
>>   
> Taking on from advice I've heard before (do not reuse maps) I'd prefer
> to let others' experiences lend to mine and avoid doing that.  It's not
> a big deal to copy it and add the extra line when the original is
> updated (it'll be automated anyway), but taking Noel's example of
> explicit rejects (next message), is it required? 

no, if you do explicit reject as Noel suggested, then you don't need that.

> If not, then I'd just
> as soon have one less directive in the case that, or rather when, this
> server is no longer mine.  I try to make the configuration as
> transparent as possible for the next guy.
> 
> Thanks again for the detailed answers.
> 
> -- DJ Lucas
> 
> 

Re: Additional smtpd_*_restrictions safe?

[mouss]

Darren Pilgrim a écrit :
> King Spook wrote:
>> I'm getting hit pretty hard with spam, and was hoping to reduce it a
>> bit by adding the following smtpd restrictions:
>>
>> smtpd_helo_restrictions = reject_invalid_helo_hostname,
>> reject_non_fqdn_helo_hostname
>> smtpd_sender_restrictions = reject_non_fdqn_sender
>>
>> Is that safe to do?
> 
> Yes!  Depending on the day, anywhere from a third to half of messages
> rejected in-session by my servers are due to those two restrictions
> alone.  In two years, I've yet to see a false positive.  Just don't use
> reject_unknown_helo_hostname (way too many false positives).
> 
> Caveat: Many MUAs use non-FQDN hostnames or worse.  You get around this
> problem by putting them in smtpd_recipient_restrictions, after
> permit_mynetworks and permit_sasl_authenticated:
> 
> smtpd_recipient_restrictions =
> permit_mynetworks,
> permit_sasl_authenticated,
> reject_unauth_destination,
> reject_invalid_helo_hostname,
> reject_non_fqdn_helo_hostname,
> reject_non_fdqn_sender
> reject_unlisted_sender,
> reject_unlisted_recipient,
> 

also consider adding
reject_rbl_client zen.spamhaus.org
check spamhaus site for more infos (policy, usage, ...).

> You should almost always keep all your restrictions in
> smtpd_recipient_restrictions.  It avoids evaluation-order headaches.

Re: how to send mail to gmail account

[mouss]

Jose Ildefonso Camargo Tolosa a écrit :
> On Fri, Dec 19, 2008 at 7:19 AM, Jorey Bump  wrote:
>> Jose Ildefonso Camargo Tolosa wrote, at 12/18/2008 06:28 AM:
>>
>>> I think you should send more info on your config, for example:
>>>
>>> MX record for your domain.
>>> myhostname entry from main.cf
>>>
>>> these two should match.
>> There is no requirement that these match. They are completely unrelated.
> 
> I said: should. 

No, they are unrelated, so there is no need for them to match. Sites with

> There are some spam filters which uses the hostname
> provided by the server and make several verifications like:
> 
> + Is the hostname listed as a MX for the domain?

They may use this for whitelisiting, not blacklisting. similar to SPF.
but they should not consider a mismatch as an anomaly.

> + Does the hostname *forward* resolve to the IP I'm being contacted from?

I guess you use the term "hostname" for the HELO argument.
Some people do this, but:
- it will cause FPs
- The RFC recommends against it

> + Does the IP *reverse* resolve to the hostname?

if the hostname is the HELO argument, then no. there were some borked
filters that do this, but this is borked...

what is done is:
- resolve the client IP. get the first returned PTR
- resolve this PTR and check that the original IP is returned by this
resolution.

note that the PTR and the hostname are two different terms (even if they
may be set to the same value in many cases).

> 
>> The OP needs to describe the problem more accurately. In general, no
>> special configuration is required to send mail to any domain.
> 
> Correct, as long as there are no spam filters around.
> 

OP problem has nothing to do with filters. he is trying to submit mail
to gmail. for that, he needs smtp TLS (without a certificate) and smtp
SASL and submit to [smtp.gmail.com]:587.

of course, if he has an firewall/proxy/anti-virus/... that interferes
with the communication (some don't allow TLS because they can't filter
the content. some don't support ESMTP, ... etc), he needs to disable this.

Re: how to send mail to gmail account

[mouss]

mouss a écrit :
> Jose Ildefonso Camargo Tolosa a écrit :
>> On Fri, Dec 19, 2008 at 7:19 AM, Jorey Bump  wrote:
>>> Jose Ildefonso Camargo Tolosa wrote, at 12/18/2008 06:28 AM:
>>>
>>>> I think you should send more info on your config, for example:
>>>>
>>>> MX record for your domain.
>>>> myhostname entry from main.cf
>>>>
>>>> these two should match.
>>> There is no requirement that these match. They are completely unrelated.
>> I said: should. 
> 
> No, they are unrelated, so there is no need for them to match. Sites with
> 

my mouse likes eating some lines ;-p

I was saying: sites with multiple servers, ones for MX and others for
outbound relay will have mismatching inbound and outbound names.

>> There are some spam filters which uses the hostname
>> provided by the server and make several verifications like:
>>
>> + Is the hostname listed as a MX for the domain?
> 
> They may use this for whitelisiting, not blacklisting. similar to SPF.
> but they should not consider a mismatch as an anomaly.
> 
>> + Does the hostname *forward* resolve to the IP I'm being contacted from?
> 
> I guess you use the term "hostname" for the HELO argument.
> Some people do this, but:
> - it will cause FPs
> - The RFC recommends against it
> 
>> + Does the IP *reverse* resolve to the hostname?
> 
> if the hostname is the HELO argument, then no. there were some borked
> filters that do this, but this is borked...
> 
> what is done is:
> - resolve the client IP. get the first returned PTR
> - resolve this PTR and check that the original IP is returned by this
> resolution.
> 
> note that the PTR and the hostname are two different terms (even if they
> may be set to the same value in many cases).
> 
>>> The OP needs to describe the problem more accurately. In general, no
>>> special configuration is required to send mail to any domain.
>> Correct, as long as there are no spam filters around.
>>
> 
> OP problem has nothing to do with filters. he is trying to submit mail
> to gmail. for that, he needs smtp TLS (without a certificate) and smtp
> SASL and submit to [smtp.gmail.com]:587.
> 
> of course, if he has an firewall/proxy/anti-virus/... that interferes
> with the communication (some don't allow TLS because they can't filter
> the content. some don't support ESMTP, ... etc), he needs to disable this.

Re: Does a policy server exist to filter on domain age/creation?

[mouss]

Justin Piszcz a écrit :
> $ whois linendim.com
> 
> Record created on:2008-12-15 11:45:30.0
> Database last updated on: 2008-12-15 11:42:09.153
> Domain Expires on:2009-12-15 11:45:31.0
> 
> A 1-second life domain name.
> 
> First, is there an existing policy server out there that checks how many
> days old a domain is?
> 

if you mean querying whois in real time, this is not possible. you will
be blocked (by whois servers) if you do too many queries.

if you mean using an RHSBL such as DOB, then check postfwd.

However:

- judging by the scores in spamassassin, this doesn't look very useful
(I personally disable DOB in SA).

- spammers have learned this and register domains ahead of time, so the
"whois age" is less useful than it was. one needs to detect when a
domain is first used in email, but there's no registry for this.



> I know there is an RHSBL for it but this seems rather odd, if the domain
> has expired/etc it would be nice to filter on these statistics..

Re: Does a policy server exist to filter on domain age/creation?

[mouss]

Jorey Bump a écrit :
> Justin Piszcz wrote, at 12/20/2008 05:43 AM:
>> $ whois linendim.com
>>
>> Record created on:2008-12-15 11:45:30.0
>> Domain Expires on:2009-12-15 11:45:31.0
>>
>> A 1-second life domain name.
> 
> What do you mean? The domain expires in one year and a second from its
> creation date.

he meant that the domain has been created a few days ago, and so "should
not start sending too much mail". Such argument must be used with
caution. Few years ago, I have worked on a (social net style) project
and marketing decided to chose a new name. The new domain thus started
sending a lot of mail few days after it was registered.

The same caution is needed when trying to detect domains that only
started sending mail recently.

Trying to use the age (be it "whois age" of "date of first mail") is not
very "practical". it may be used while investigating on a suspicious
domain.

> 
>> First, is there an existing policy server out there that checks how many
>> days old a domain is?
> 
> If so, it would probably end up working a lot like greylisting. You'd
> get a similar effect scoring with the SpamCop dnsbl, since it penalizes
> fresh domains.
> 
>> I know there is an RHSBL for it but this seems rather odd, if the domain
>> has expired/etc it would be nice to filter on these statistics..
> 
> True. There's no reason to accept mail from a long-expired domain (but
> your example hasn't expired).
> 
> 
> [BTW, there appears to be a problem with the DNS for your domain,
> lucidpixels.com. Your nameservers are not responding.]
> 

he has only one name server (75.144.35.66) and it is not responding. he
should setup a secondary NS, as recommended by the RFCs...

Re: Problems with user's mail file

[mouss]

Pedro Augusto a écrit :
> If the problem is Mailscanner mangling the files, would an upgrade solve
> the problem?
> 

I think it's as Viktor said. I've already seen corrupted mbox files like
that.

consider using maildir instead.

> How can I test if the problem is concurrent access? Just to be sure
> which of these are the problems...
> 

this is hard to test since such things happen at random times!

Re: how hash table in transport_maps has '*' support

[mouss]

Reinaldo de Carvalho a écrit :
> Hi,
> 
> How hash table in transport_maps has '*' support and it in others
> options (e.g. check_client_access) dont work? Postfix always query for
> '*'?
> 
> Why it is necessary if relayhost exist?
> 

compatibility with old versions.

Re: Local delivery mail distribution

[mouss]

varad gupta a écrit :
> Hi all
> 
> Regrets for the previous mail.
> 
> My Scenario -> Mail to a aingle id should be distributed to a list, BUT
> one id at a time.
> 
> e.g. if I have a mail id -> t...@company.com 
> 
> and team members are jack,phil and bill -
> the first mail to t...@company.com  should be
> delivered to j...@company.com  ONLY
> the second incoming mail to t...@company.com 
> should be deliverd to p...@company.com  ONLY
> the third mail (intended for t...@company.com )
> should be delivered to b...@compamny.com 
> 
> The fourth mail should be delivered to jack
> fifth to phil
> sixth to bill
> so on and so forth...
> 
> How can this be implemented, pls quide
> 

you need to run a script at delivery time (from maildrop for example) or
write a content filter. the script needs to do some locking in case two
messages arrive at the same time.

What problem are you trying to solve?

> Merry Christmas and a very happy new year to all
> 

happy $(customize_as_you_want) to all.


> Thanx in anticipation of a quick reply,
> 

Re: DIGEST-MD5 user/realm mismatch with Dovecot auth

[mouss]

Charles Marcus a écrit :
> On 12/25/2008, Darren Pilgrim (post...@bitfreak.org) wrote:
>> Cyrus-SASL 2.1.22 (on B and C for SMTP client SASL) 
> 
> You might try just using dovecot-sasl - one less package to
> install/maintain, and it works as well or better than cyrus-sasl, and is
> much easier to configure...
> 
> http://wiki.dovecot.org/HowTo/PostfixAndDovecotSASL
> 

he uses cyrus-sasl for client-sasl (smtp_*, not smtpD_*). dovecot only
support server-sasl.


but I don't see why he uses client-sasl between his internal and
external servers.

Re: DIGEST-MD5 user/realm mismatch with Dovecot auth

[mouss]

Darren Pilgrim a écrit :
> mouss wrote:
>> Charles Marcus a écrit :
>>> On 12/25/2008, Darren Pilgrim (post...@bitfreak.org) wrote:
>>>> Cyrus-SASL 2.1.22 (on B and C for SMTP client SASL) 
>>> You might try just using dovecot-sasl - one less package to
>>> install/maintain, and it works as well or better than cyrus-sasl, and is
>>> much easier to configure...
>>>
>>> http://wiki.dovecot.org/HowTo/PostfixAndDovecotSASL
>>>
>>
>> he uses cyrus-sasl for client-sasl (smtp_*, not smtpD_*). dovecot only
>> support server-sasl.
>>
>>
>> but I don't see why he uses client-sasl between his internal and
>> external servers.
> 
> The internet is between the servers.  I use SASL rather than
> address-based access lists since only the prior is reliable.

why not use TLS instead?
With TLS, you can use certificate fingerprints for access control, or
you can use PLAIN SASL (since the communication is protected by TLS).

if the server is in an untrusted data center, this has the benefit of
preventing other (owned) servers from sniffing data.

Re: howto setup outgoing port to 587 ?

[mouss]

Sahil Tandon a écrit :
> Victor Duchovni wrote:
> 
>> On Fri, Dec 26, 2008 at 08:25:12AM -0500, Sahil Tandon wrote:
>>
>>> sean darcy wrote:
>>>
 Victor Duchovni wrote:
> On Mon, Dec 22, 2008 at 12:08:20PM -0500, Asif Iqbal wrote:
>
>> smtp_use_tls = yes
>>
> This is obsolete. Set:
>
>   smtp_tls_security_level = encrypt
>
> or better (given suitable CAfile or CApath):
>
>   smtp_tls_security_level = secure
>
 So where would you get the certificate to authenticate to google or
 1and1.
>>> The smtp (client), as opposed to the smtpd (server), does not need a
>>> certificate to authenticate to google. 
>> Irrelevant, an SMTP client that wants to verify Google's augthenticity
>> needs the root CA certificate of the CA that signed Google's cert.
> 
> Agreed.  My point is that a cert is *not* needed to authenticate to 
> Google's submission service.  If, and only if, the client wants to 
> verify authenticity is the signing root's cert required.
> 

it's not required. but if you don't verify the cert, then you trust DNS.
so a DNS attack (poisoning, ...) would make him send passwords to the
wrong server.


>> Yes the client does not need its own private keys and associated certs,
>> but that is not the point.
>  
> It is not the point and thus was not alleged.
> 
> [...]
> 

Re: howto setup outgoing port to 587 ?

[mouss]

Jan P. Kessler a écrit :
> mouss schrieb:
>> it's not required. but if you don't verify the cert, then you trust DNS.
>> so a DNS attack (poisoning, ...) would make him send passwords to the
>> wrong server.
>>   
> 
> 
> If you use encryption you implicitly assume that there might be someone
> between you and the target system. Unfortunately that 'someone' may also
> perform MITM attacks in that position. The only possibility to get
> around this is to verify the identity of the target.
> 
> So keep in mind that you should
> 
> 1. always try to verify your target's identity
>   or
> 2. not use encryption because it wastes cpucycles for nothing
> 
> 

you may still want to encrypt a channel to avoid sniffing by "local"
machines. sniffing traffic is a lot easier than (active) MITM attacks.
so no, encryption without verification is not a waste.

(I'm not saying verification is useless. I'm saying there may be cases
where verification may be problematic while encryption is still
desirable).

Re: howto setup outgoing port to 587 ?

[mouss]

Vidar Salberg Normann a écrit :
>>> My ISP, ATT blocks port 25. I think if I just send the email to port 587
>>> ( which is how I've configured Thunderbird ) this should work.
>> On 587, you will also need SASL authentication. This is a "submission"
>> service.
> 
> Does this mean you can't make postfix treat traffic on port 587 exactly like
> normal SMTP traffic on port 25, while also accepting SASL and/or AUTH
> LOGIN if used?
> 

you can do what you want _your_ postfix. 587 is just a number. it just
happens to be the recommended submission port and the recommendation is
to use SASL for submission.

enforcing sender domain in outbound mail [Was: ]

[mouss]

D. Karapiperis a écrit :
> Hi All
> 
> I have a question regarding postfix restrictions.
> 
> Is there a way for Postfix to enforce some kind of policy so that all
> the outgoing (allowed) mails be " @business.com" and all the others be
> rejected.
> Of course this policy should be enforced only to the outgoing emails
> not in the incoming.
> 

you can do the following: if the sender is not *...@example.com, then do
not allow relay.

smtpd_sender_restrictions =
check_sender_access hash:/etc/postfix/outbound_sender
reject_unauth_destination


== outbound_sender
example.com OK


users will still be able to use any sender adress if they send to one of
your domains (mydestination, virtual mailbox domains, relay domains,
virtual alias domains).


> I think that smtpd_*_restricions regard all the e-mails
> (outgoing,incoming) and simply check the RCPT TO and MAIL FROM
> statements. Correct?

all mail is incoming when received and outgoing when forwarded!

if the above isn't enough, you could do one or more of the following things:

- if mail comes from mynetworks, require that the sender address is
*...@example.com. you can do this with a restriction class based on
check_client_access.

- for authenticated mail, require that the sender matches the login
(look for reject_sender_login_mismatch and friends).

... etc.

Re: Action during SMTPD* checks

[mouss]

KLaM Postmaster a écrit :
> I have just finished reading a bunch of stuff on UCE and the "effects"
> of the various parameters associated with the smtpd_*_restrictions, and
> I am now somewhat confused as two of the authors I have been reading
> state that if a message receives an "OK" from any check then all further
> checks are abandoned. This does not make any sense and I am fairly sure
> that they got it backward but both of them are adamant!
> 
> This is/was my understanding, from reading the documentation and
> elsewhere.If a restriction check was successful (i.e., OK/DUNNO) then
> postfix moves on to the next check, if on the other hand the check was
> unsuccessful then the message is dropped and no further checks are done.
> 

if a check returns OK, then postfix will skip all other checks in the
same smtpd_*_restrictions. if you want to continue to the following
checks, return DUNNO, not OK.

> e.g., if the following is the sequence in main.cf :
> 
> smtpd_xxx_restrictions = reject_non_fdqn_hostname,
> reject_unknown_recipient_domain, reject_non_fdqn_recipient, (permit)
> 
> then if the hostname is a fdqn, then postfix continues on to
> unknown_recipient, and if that is OK moves on to the non-fdqn_recipient
> ... until it runs out of check at which point he default (usually
> permit) is exercised.

reject_* never returns OK. so let's chose a better example:

smtpd_client_restrictions =
check_sender_access hash:/etc/postfix/access_sender
reject_non_fqdn_helo_hostname

if the check_sender_access returns OK, then postfix will move to
smtpd_helo_restrictions. it will skip the reject_non_fqdn_helo_hostname
check.

if the check_sender_access returns REJECT, postfix rejects the
connection and n more checks are performed.

if the check returns DUNNO, postfix continues to
"reject_non_fqnd_helo_hostname".

> if on the other hand the hostname is _not_ a fdqn the message is dropped
> and no further checks are performed under the xxx restrictions.
> Furthermore, if a message is dropped at say the client phase then checks
> in helo and subsequent phases are not performed.
> 

yes.

Re: Enforcing sending domain from the inside network

[mouss]

D. Karapiperis a écrit :
> 
> 
> Hi All
>>
>> I have a question regarding postfix restrictions.
>>
>> Is there a way for Postfix to enforce some kind of policy so that all
>> the outgoing (allowed) mails be " @business.com" and all the others be
>> rejected.
>> Of course this policy should be enforced only to the outgoing emails
>> not in the incoming.
>>
> 
> 
> - if mail comes from mynetworks, require that the sender address is
> *...@example.com. you can do this with a restriction class based on
> check_client_access.
> 
> 
> Thanks for the reply
> 
> I did this
> 
> mynetworks = cidr:/etc/postfix/inside_network
> 
> smtpd_restriction_classes=
>from_inside_network
> 
>  from_inside_network =
>   check_client_access cidr:/etc/postfix/inside_network
> 
> 
> smtpd_recipient_restrictions =
> check_sender_access hash:/etc/postfix/sending-domains,
> reject_unauth_destination
> 
> 
> 
> /etc/postfix/inside_network
> 192.168.2.0/24 OK
> 127.0.0.0/8   OK
> 
> 
> /etc/postfix/sending-domains
> business.gr  from_inside_network
> 
> So I did a logical AND -> all clients form my network have the relay
> privilege and moreover they can send e-mails only from business.gr
> (hopefully)

This configuration is:

- ugly because you mix unrelated tasks. blocking relay and enforcing
outbound sender domain are two different tasks. The keywords here are:
clarity, self-documenation, maintenance, etc. some day, you may want to
allow your boss to post with his jackinthebox address, and you will edit
the "sending-domains" table. some day, you may want to allow some other
sender domains. That day, you will lose your hair trying to put ORs
inside your ANDs. De Morgan laws are hard to put in simple key-value maps.

- unsafe because if you or someone else edits sending-domains, you could
become an open relay. oh yes, bad things do happen.

- pointless. it brings nothing compared to what I suggested.


Unless you really know what you are doing and why (and even then, you
should think 3.1415... times [yeah, you'll have to do it until the last
digit of PI ;-p]),
- avoid using check_*_access before reject_unauth_destination
- use smtpd_recipient_restrictions for relay control and spam fighting
- use other restrictions to implement local policy (enforce outbound
sender domain as you want to do, make some addresses "local only", ...
etc).


PS. There is no point to reinvent built-in functionality (your
from_inside_network is exactly permit_mynetworks).


> I need to test it on a production server.
> 
> 
> 

Re: VERP uses the recipient name after virtual_regexp rewriting

[mouss]

Jesper Dybdal a écrit :
> I have just installed a mailing list manager (Mailman) for use with my
> Postfix installation (which has just been upgraded to 2.5.5).  I have
> patched Mailman to use the XVERP option on MAIL FROM.
> 
> This works, but I was surprised to see that when the recipient address
> provided by Mailman is rewritten by Postfix' virtual_regexp, then the
> recipient address that Postfix encodes in the envelope return path is
> the rewritten address, rather than the original subscriber address that
> Mailman knows.
> 
> Since mailing list software using XVERP needs to recognize the address
> from the envelope return path as being equal to the subscribed address,

Really? AFAIK, most list managers use the From: header.

> would it not be better to always use the raw address from RCPT TO,
> rather than the rewritten one, when creating the VERP'ed return path?
> 
> I have not tested this with the 2.6 experimental release, but the
> release notes say nothing about VERP, so I assume the behaviour is the
> same in 2.6.
> 
> (This is not a serious problem for me: the addresses that are rewritten
> in my installation are in practice local addresses and it is extremely
> unlikely that they will bounce.  But it surprised me.)

Re: Trying to use uppercase names in Postfix.

[mouss]

Xn Nooby a écrit :
> Hi Sahil,
> 
> I am looking in to how to create the duplicate passwd file entries, I
> am assuming I cannot just edit the file without corrupting it.



you forgot to tell us which OS you run. let's assume your "sudo ..." as
a hint ;-p

- save the following as doit.sh

#!/bin/sh
IFS=:
cat /etc/passwd | while read user _x uid gid gecos home shell; do
user=`echo $user | tr [A-Z] [a-z]`
grep -q "^${user}:" /etc/passwd
if [ $? -ne 0 ]; then
echo "adduser --disabled-password --uid $uid --gid $gid --gecos $gecos
--home $home --shell $shell $user";
fi
done

- run it: sh doit.sh > lowerpass.sh

- edit lowerpass.sh and remove all lines but the ones that create the
users you want to create.




> Below
> is my main.cf and aliases file.  Also, should I post my replies to
> emails at the top or the bottom? (a few years ago some people got
> really mad at me, but now I can't remember which was correct)
> 

put your replies at the bottom. if you don't know why, search for "top
posting".

> I noticed the main.cf referred to /etc/aliases while I had edited
> /etc/postfix/aliases, so I also put my JIM123 entry in to /etc/aliases
> and ran "sudo newaliases", but still isn't working. 

what is not working? As you have already been told, postfix "local" will
lowercase the address, so alias_maps don't help.

> Should I be using
> /etc/aliases instead of /etc/postfix/aliases? A few hours ago I got
> "The Book of Postfix" from No Starch Press, and they said
> /etc/postfix/aliases (but I suspect that is wrong).


This is system dependent. for postfix, the only thing that really
matters is that the path be the one specified in alias_maps and
alias_database.

Re: VERP uses the recipient name after virtual_regexp rewriting

[mouss]

Jesper Dybdal a écrit :
> On Mon, 29 Dec 2008 22:30:53 +0100, mouss  wrote:
> 
>> Jesper Dybdal a écrit :
>>> Since mailing list software using XVERP needs to recognize the address
>>> from the envelope return path as being equal to the subscribed address,
>> Really? AFAIK, most list managers use the From: header.
> 
> The point in VERP is that the list subscriber that bounces can be
> recognized by the address that the bounce is sent to.  This is a much
> safer way to identify the subscriber than any attempt to parse the
> bounce message to determine which address actually bounced.

I misunderstood. I thought you were talking about checking that a post
is from a member (before resending).

Re: Enforcing sending domain from the inside network

[mouss]

D. Karapiperis a écrit :
> I did the from_inside_network thing to do the logical AND regarding the
> sending domain.

A "logical AND" can be replaced by a sequence. and a sequence is easier
to manage (in the mind, on paper, ...).

> Is there any way to do this woth permit_mynetworks?
> 

to do what? I already posted a config that answers your need. here it is
again:

smtpd_sender_restrictions =
check_sender_access hash:/etc/postfix/outbound_sender
reject_unauth_destination


== outbound_sender
example.com OK



> Is there any way to permit local users (from the inside network) to send
> emails using the business domain in a clear and nice way in postfix?
> 

I guess you mean implement something like:

if (client is in mynetworks) then sender must be in *...@example.com

this can be written as:

if ((client is in mynetworks) and (sender is not in *...@example.com)) then
reject

which in turn can be restated as a sequence:

1- if sender is *...@example.com, then pass
2- if client is in mynetworks, then reject

and this is easily implemented with:

smtpd_client_restrictions =
check_sender_access hash:/etc/postfix/allow_our_domain
check_client_access hash:/etc/postfix/reject_mynetworks


== allow_our_domain
example.com OK

== reject_mynetworks
10.1.2.0/24 REJECT you must use an address in @example.com

if you already have checks under smtpd_client_restrictions, then use
smtpd_helo_restrictions or smtpd_sender_restrictions (whichever is
empty). but don't use smtpd_recipient_restrictions (it is possible, but
an error there makes you an open relay). if no restriction is empty,
you'll need restriction classes. if it's the case, show your full config
(all restrictions and restriction classes).


while you could use a single map for both "reject_mynetworks" and
mynetworks, it is not wise (as I said before, one day, you will edit
something and the world will break all of a sudden). better use a script
to generate both files from a single source file (you can use a Makefile
 that you could use for other map mgmt tasks).

Re: Enforcing sending domain from the inside network

[mouss]

Wietse Venema a écrit :
> D. Karapiperis:
>> I did the from_inside_network thing to do the logical AND regarding the 
>> sending domain. Is there any way to do this woth permit_mynetworks?
>>
>> Is there any way to permit local users (from the inside network) to send 
>> emails using the business domain in a clear and nice way in postfix?
> 
> For this you would need
> 
> smtpd_sender_restrictions =
>   check_sender_access [table that maps your domain -> permit]
>   reject_mynetworks
> 
> But, since reject_mynetworks is not implemented, you end up
> implementing it yourself:
> 
> smtpd_sender_restrictions =
>   check_sender_access [table that maps your domain -> permit]
>   check_client_access [table that maps your networks -> reject]
> 
> For example
> 
> /etc/postfix/main.cf:
> smtpd_sender_restrictions =
>   check_sender_access hash:/etc/postfix/sender_access
>   check_client_access pcre:/etc/postfix/client_access.pcre
> 
> hash:/etc/postfix/sender_access
> example.com   permit
> 
> /etc/postfix/client_access.pcre
> 192.168.0.0/24 reject must send mail as u...@example.com
> 

I guess you meant cidr, not pcre.

and in my post, I meant cidr, not hash.

Re: Enforcing sending domain from the inside network

[mouss]

D. Karapiperis a écrit :
> O/H Wietse Venema έγραψε:
>> Since he asked for a "nice" way to specify this in Postfix, a "nice"
>> implementation of this would look like this:
>>
>> /etc/postfix/main.cf:
>> smtpd_sender_restrictions = permit_mydomain, reject_mynetworks
>> 
>> Where the details are hidden by restriction classes:
>>
>> /etc/postfix/main.cf:
>> restriction_classes = permit_mydomain, reject_mynetworks
>> permit_mydomain = check_sender_access hash:/etc/postfix/sender_access
>> reject_mynetworks = check_client_access
>> cidr:/etc/postfix/client_access.cidr
>>
>> hash:/etc/postfix/sender_access
>> example.compermit
>>
>> /etc/postfix/client_access.cidr
>> 192.168.0.0/24 reject must send mail as u...@example.com
>>
>> Note that moving this into smtpd_recipient_restrictions would
>> make this an open relay, as anyone can claim to have a sender
>> address in your domain.
>>
>> Wietse
>>   
> 
> Many thanks for your replies, u really help a lot.
> 
> I cannot understand why if we move the statement on the
> smtpd_recipient_restricitons will end up on open relay.
> Again check_sender_access will examine the MAIL FROM right?
> and the client access the IP, right?
> 

permit_mydomain returns a "permit", so the message is accepted and no
further checks are done. in particular, reject_unauth_destination is
skipped.

in short, if a spammer forges sends as j...@example.com, the message is
accepted even if it goes to an external domain. and this is open relay

Re: Alias piping + mysql in virtual domains

[mouss]

Joselito a écrit :
> Hi,
> 
> I'm moving an existing domain to virtual mailboxes.  All the info is
> stored in a mysql database.  Currently all devlivery and alias mapping
> is working correctly; I'm using virtual_mailbox_maps,
> virtual_alias_maps and virtual_mailbox_domains stored in the sql
> backend.
> 
> Problem is that aliases that pipe to a command and aren't delivered
> anywhere
> - this is most common for mailing list software like mailman and
> smartlist.  Dropping the piped command into the destination side of an
> alias map results in a bounce mail, and the logs show an unknown user
> error.  The current workaround that I'm using is to alias to another
> alias in /etc/aliases (obviously a flat file, not an sql backend) which
> is aliased to the pipe.
> 
> This seems wrong and doubles the admin work, as you have to add the
> alias into the virtual_alias_maps sql db, and then make another alias
> that points to the actual pipe.  Am I doing this incorrectly?  Should
> virtual_alias_maps be able to handle a pipe and I've got something
> misconfigured?  Using postmap -q to query the db gives the correct pipe
> command.  It doesn't work with double quotes or without on the pipe
> command.
> 

virtual does not execute commands. an alternative to using /etc/aliases
is to create a transport in master.cf. if all your lists have addresses
of the form *...@lists.example.com, then you can create a transport for
lists.example.com to pass mail to your list manager.

Otherwise, you can use an external MDA (such as maildrop for example).

Re: Enforcing sending domain from the inside network

[mouss]

D. Karapiperis a écrit :
> 
> Open relay will not take place if the checks are included on
> smtpd_sender_restrictions?



an OK in smtpd_sender_restrictions does not skip
smtpd_recipient_restrictions, and relay check is done in the latter
(reject_unauth_destination).

Re: rewrite recipients after /etc/aliases is processed

[mouss]

Hanspeter Kunz a écrit :
> Hi all,
> 
> I'm trying to figure out how I can deliver mail
> 
> usern...@examplehost.example.com
> 
> to a central mail server (smtp.example.com) without setting
> 
> myorigin = $mydomain
> 
> on the example host, because I would like to see where the mail
> originiated or was originally sent to in the sender address.
> 
> I tried to use recipient canonical maps
> 
> @examplehost.example.com @example.com

don't do that.

> 
> but then /etc/aliases is not used e.g. to forward email.
> 

why use /etc/aliases to forward mail? use transport_maps:

examplehost.example.com relay:[192.168.1.2]


> I there a way, to rewrite recipient adresses *after* /etc/aliases has
> been processed?
> 

Re: Finding the envelope-sender after always_bcc?

[mouss]

Jeff Weinberger a écrit :
> Hi:
> 
> After reading http://www.irbs.net/internet/postfix/0703/1471.html and
> http://www.irbs.net/internet/postfix/0703/1519.html to help with my
> autoreply capability (and making sure i get it as close to "right" as
> possible!), I am trying to ensure that I can take all reasonable
> measures to get the autoreplies right (when they are sent). to this end,
> it's important that I capture the envelope-sender of each message in
> addition to the "From:" header, but I am having difficulty doing so.
> 

yes, don't reply to From: addresses. if you can't get the envelope
sender, don't autoreply.

> I have tried to send the message to my autoreply script via bcc: (via
> always_bcc or recipient_bcc_maps) to a local autoreply address which
> then has the transport autoreply: which calls the autoreply script via
> pipe or is a local alias that resolves to '|/path/to/autoreply/script'.
> The transport mechanism has the ability to pass information from
> postfix, but doesn't seem to capture the envelope-sender correctly.
> 

The envelope sender should be found in the Retrun-Path header. when
using a pipe, make sure to put the 'R' flag in the "flags=..." options.

you can also use -f ${sender} in your pipe and have your scrpit parse
command line args.

> I have tried using every single one of the macros listed in
> http://www.postfix.com/pipe.8.html to no avail. I have even used some
> macros that are not listed, but I've found in other examples as I've
> searched for solutions.
> 
> This happens with mail sent to alias addresses as well as virtual
> mailboxes.
> 
> Some e-mails from lists to which I subscribe include a "Sender: " header
> which looks like it contains the envelope-sender. Mail that shows up in
> my standard ISP account (not ever touching my postfix installation)
> seems to include the "Return-Path: " header which includes the
> envelope-sender.
> 
> Leading me to two questions:
> 
> 1) on-topic: How can I be sure I can find the envelope-sender for every
> message and pass that to my script? Or maybe I should ask it this way:
> How do I get postfix to keep the correct envelope-sender?
> 

always_bcc does not change the envelope sender (it changes the envelope
recipient). so you get the "correct" envelope sender.


> 2) broader: Is the list of macros that can be used as arguments to a
> pipe command (as listed in http://www.postfix.com/pipe.8.html) complete?
> or are there others (like the ones I've found)? and where can I find a
> complete list?
> 
> I would appreciate any help, direction or pointers that anyone can offer.
> 
> It might help to know that messages entering my postfix server are then
> passed to a content_filter (Dspam, specifically, using
> content_filter=dspam:dspam), which then re-injects them back into
> postfix which then handles them and sends them to a delivery agent
> (mostly maildrop, sometimes virtual). If the order of this (and the
> passing through dpsam is affecting the envelope-sender, is there way to
> either get the message to the autoreply script before it goes to dspam
> (I don't want that, since I don't autoreply to spam messages) or a way
> to pass the envelope-sender through dpsam, or something else I haven't
> considered?
> 

check your logs to see if the envelope sender is present at delivery
time. if your content filters and other stuff reinjects mail using the
sendmail command, make sure to use -f to passe the (original)
envelope-sender.

Re: Rejecting emails with invalid/unlikely dates?

[mouss]

Darren Pilgrim a écrit :
> IBBoard wrote:
>> I've been looking around but so far haven't been able to find anything
>> (partly because it's difficult to phrase a search query!). If someone
>> has a solution/config for this then that'd be great.
>>
>> Before anyone points out issues with GMail and lack of control, this
>> is all being done on a domain on a VPS. I'm just using my Gmail
>> address for the mailing list :)
>>
>> Basically, 99% of the spam I get (which is only a small amount
>> compared to some people) is either a) purporting to be from me, to me
>> or b) has a date that Thunderbird reports as 1976 or 2038 (but is
>> really 3609 or just "38"). I've resolved the first part with SPF
>> records and checking them in Postfix, but I can't work out how to get
>> Postfix to reject mail that is outside a 14 day window from today (or
>> silently dispose of it if it's not possible because it has to get too
>> far in to the system to fail it).
> 
> You need a content filter for this. 

and to reject, he needs to run it in pre-queue mode (proxy_filter). or
he could use a milter such as milter-regex.

> Header checks can do this; however,
> they're static, so you have the problem of updating them constantly to
> keep the validity window moving. 

He can use a cron to update the header_checks daily. This is "simpler"
than milter/proxy_filter.

> Plus there's the issue of date
> formats. 

This is not a problem here, since he wants to block "known" spam. so he
can write expressions for that spam. and if he only wants to block on
the year, then it's even easier.

> The best way, IMO, is a policy service that can grok a wide
> variety of date formats and check if the date is within 14 days of the
> current time.
> 

a policy service doesn't see headers. a milter or a proxy_filter does.

> There are spamassassin rules for future dates in message headers, so you
> might try that route instead of rolling your own.

this is indeed easier and maybe safer (well, if OP uses spamassassin).

Re: Finding the envelope-sender after always_bcc?

[mouss]

Jeff Weinberger a écrit :
> 
> I've verified that the "R" flag is there and I use -f ${sender} on the
> command line (the script does parse the arguments)
> 
> I think the envelope-sender is missing before it enters the content
> filter. This from my mail.log:
> 
> Dec 31 19:50:07 s postfix/qmgr[3345]: A4C5E2943D74: from=,
> size=1505, nrcpt=1 (queue active)
> Dec 31 19:50:07 s postfix/smtpd[3340]: disconnect from
> smtp120.isp.mail.sp1.myisp.tld[69.147.64.93]
> Dec 31 19:50:07 s dspam[3356]: query error: VERBOSE DEBUG (INFO ONLY -
> NOT AN ERROR): see sql.errors for more details
> Dec 31 19:50:09 s postfix/smtpd[3348]: connect from localhost[127.0.0.1]
> Dec 31 19:50:09 s postfix/smtpd[3348]: 646A62943D79:
> client=localhost[127.0.0.1]
> Dec 31 19:50:09 s postfix/cleanup[3344]: 646A62943D79:
> message-id=
> Dec 31 19:50:09 s postfix/qmgr[3345]: 646A62943D79: from=<>, size=2936,
> nrcpt=1 (queue active)
> Dec 31 19:50:09 s postfix/smtpd[3348]: disconnect from localhost[127.0.0.1]
> Dec 31 19:50:09 s postfix/pipe[3346]: A4C5E2943D74:
> to=, relay=dspam, delay=5.1,
> delays=3.4/0/0/1.7, dsn=2.0.0, status=sent (delivered via dspam service)
> 
> (identifying information removed)
> 
> The "from=<>" in the third-to-last line I assume should be the
> envelope-sender?
> 

yes. when mail is passed back to postfix, something loses the
envelope-sender. how do you pass mail from dspam to postfix?

> This happens whether I send from my ISP mail address, another
> locally-hosted virtual mailbox or anywhere else.
> 
> Is this part of the problem?
> 
> If so, where can I start to look for a solution? or what information
> would be helpful?
> 
> Thank you!
> 
> 

Re: Looping in new production machine!

[mouss]

Rich Winkel a écrit :
> I'm not sure, I may have an unusual dns setup on this mail server.
> The primary host name is math.missouri.edu, but it has an alias of
> math.math.missouri.edu.  In any case, I'm getting the dreaded:
> 
> status=SOFTBOUNCE (mail for math.math.missouri.edu loops back to myself)
> 
> Even though incoming messages are addressed to x...@math.missouri.edu.
> Yet it doesn't happen to all incoming messages.  Has anyone seen this
> behavior?
> 
> Here are the relevant variables from main.cf:
> mydomain = math.missouri.edu
> myhostname = math.missouri.edu
> mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
> inet_interfaces = $myhostname, localhost
> 

either add math.math.missouri.edu to mydestination or set
myhostname = math.math.missouri.edu

Re: Finding the envelope-sender after always_bcc?

[mouss]

jeff_homeip a écrit :
> --- In post...@yahoogroups.com, mouss  wrote:
>> Jeff Weinberger a écrit :
>>> I've verified that the "R" flag is there and I use -f ${sender} on the
>>> command line (the script does parse the arguments)
>>>
>>> I think the envelope-sender is missing before it enters the content
>>> filter. This from my mail.log:
>>>
>>> Dec 31 19:50:07 s postfix/qmgr[3345]: A4C5E2943D74: from=,
>>> size=1505, nrcpt=1 (queue active)

look at the queue-id: A4C5E2943D74

>>> Dec 31 19:50:07 s postfix/smtpd[3340]: disconnect from
>>> smtp120.isp.mail.sp1.myisp.tld[69.147.64.93]

postfix disconnects from 69.147.64.93.

>>> Dec 31 19:50:07 s dspam[3356]: query error: VERBOSE DEBUG (INFO ONLY -
>>> NOT AN ERROR): see sql.errors for more details

dspam barks. so dspam got the message.

>>> Dec 31 19:50:09 s postfix/smtpd[3348]: connect from localhost[127.0.0.1]

dspam connects to postfix (after the filter smtpd).

>>> Dec 31 19:50:09 s postfix/smtpd[3348]: 646A62943D79:
>>> client=localhost[127.0.0.1]

this dspam connection has a queue-id of 646A62943D79

>>> Dec 31 19:50:09 s postfix/cleanup[3344]: 646A62943D79:
>>> message-id=
>>> Dec 31 19:50:09 s postfix/qmgr[3345]: 646A62943D79: from=<>, size=2936,
>>> nrcpt=1 (queue active)

the envelope sender is empty for queue-id 646A62943D79, which
corresponds to dspam re-injection. so dspam has reinjected the message
with an empty sender.

>>> Dec 31 19:50:09 s postfix/smtpd[3348]: disconnect from localhost[127.0.0.1]
>>> Dec 31 19:50:09 s postfix/pipe[3346]: A4C5E2943D74:
>>> to=, relay=dspam, delay=5.1,
>>> delays=3.4/0/0/1.7, dsn=2.0.0, status=sent (delivered via dspam service)

once dspam has delivered the message, postfix tells you that the
original transaction was delivered. this comes late because dspam does
not queue mail, so postfix can't know that delivery _will_ succeed.

>>> [snip]
> 


> From this log entry it looks like the envelope sender is empty before the 
> mail is send to 
> dspam - the "from=<>" three lines before the mail is delivered to dspam makes 
> me think 
> this.
> 

don't rely on the order of log lines. Instead, look at the queue-id:

A4C5E2943D74 is the queue-id when postfix received the message from the
network. 646A62943D79 is the queue-id when postfix received the message
from localhost, which should be dspam re-injection.


> When I look at the log entries for the message when it comes back into 
> postfix from 
> dspam the envelope sender is also empty (again "from=<>"
> 

see above. the log doesn't tell you "I am about to pass mail to dspam".
it tells you "mail was delivered, and it was done via dspam". This means
that dspam took the message and said "OK" to postfix, and since dspam
doesn't have a queue manager, this means that the message was already
filtered and passed to postfix/smtpd (the "after the filter" one).

> So isn't there something losing the envelope sender before it ever gets to 
> dspam?
> 
> but to answer your question directly, dspam re-injects the mail into postfix 
> using SMTP on  
> an alternate port, the same way as is illustrated in the 
> CONTENT_FILTER_README for an 
> after-queue content filter.
> 

so the problem is in dspam.

> Does that help?
> 

I asked just to make sure it was not passing the message to something
else that does the re-injection.

Re: Finding the envelope-sender after always_bcc?

[mouss]

Jeff Weinberger a écrit :
> 
> Thank you! That helps clarify what I was missing in this - so clearly
> dspam is not passing the envelope sender back to postfix.
> 
> I suspect it doesn't know how via SMTP, but it can also use the
> sendmail  command to do this. I will experiment with this.
> 

no, keep using smtp. just check your setup (and see why dspam barks
about sql errors). ask on the dspam list.

If you wnat to keep using dspam, you should follow the (recent) fork:
http://www.dspam-community.org

> would the correct command be "/usr/sbin/sendmail -f" ?
> 

yes, but smtp is better.

Re: RCPT TO problem using relay host

[mouss]

Dennis Putnam a écrit :
> I have a machine running postfix that is required to relay mail through
> my ISP's mail server. When I try to send mail, I get this error:
> 
> 550 [PERMFAIL] destination not valid within DNS (in reply to RCPT TO
> command)
> 
> Can someone explain what this error means? If I use 'telnet' to send the
> RCTP TO command manually it accepts it.
> 

please show full log lines.

Re: Finding the envelope-sender after always_bcc?

[mouss]

Jeff Weinberger a écrit :
> 
> I've been reading the dspam docs this morning and the project owner
> states fairly strongly that sendmail is far preferable to SMTP
> re-injection (in the postfix setup docs), but doesn't say why.

if he doesn't say why, then we don't know whether there was a problem at
the time or if there is another reason. People have been using smtp mode
without problems.

> I don't
> know enough about the workings of dspam (yet) to know, but I'd tend to
> agree with you on the use of SMTP as more desirable.
> 
> dspam has always had this mysql issue, which is related to its database
> of spam tokens, and I'll look into whether it might be related.
> 

I don't think it is related, but check it though...

Re: issue connecting to mysql after upgrade

[mouss]

Jeff Weinberger a écrit :
> Hello again:
> 
> One more issue on which I would appreciate any help anyone can offer:
> 
> Yesterday I upgraded my postfix installation from 2.5.2 to 2.5.5 and my
> MySQL installation from 5.0.51b to 5.0.75. Immediately after restarting
> everything (the whole computer), I started seeing these messages in my
> mail log:
> 
>  Jan  1 09:48:35 s postfix/smtpd[13199]: warning: connect to mysql
> server localhost: Can't connect to local MySQL server through socket
> '/tmp' (38)
>  Jan  1 09:48:35 s postfix/cleanup[13201]: warning: connect to mysql
> server localhost: Can't connect to local MySQL server through socket
> '/tmp' (38)
>  Jan  1 09:48:42 s postfix/trivial-rewrite[13205]: warning: connect
> to mysql server localhost: Can't connect to local MySQL server through
> socket '/tmp' (38)
> 
> As far as I can tell this has been consistent with smtpd, cleanup and
> trivial-rewrite, but nothing else. (there have been pre-existing issues,
> per my prior conversation with mouss, with dspam, but these have not
> changed at all - they existed before the upgrade and still exist)
> 
> I use mysql for nearly all my tables in postfix. All of my aliases are
> working and forwarding fine, which means that postfix can access my
> mysql database (and yes, postconf -m shows mysql). virtual is finding
> the maildirs correctly for my virtual mailboxes.
> 
> However, my sender_canonical_maps are no longer working after the
> upgrade (outbound addresses are not being rewritten at all as they were
> before the upgrade)
> 
> As an example, my main.cf contains:
>sender_canonical_maps=mysql:/etc/postfix/mysql_canonical_maps.cf
> 
> and mysql_canonical_maps.cf contains:
> 
> user = postfixuser
> password = postfixpassword
> hosts = localhost, 127.0.0.1
> dbname = postfixdatabase
> query = SELECT result FROM canonical WHERE address='%s' AND active='Y'
> 
> (obvious information changed). This is unchanged before and after the
> upgrade.
> 
> The query works on all the addresses (I tested it at the mysql command
> prompt).
> 
> I also tested a local telnet to 127.0.0.1 on port 3306 which worked as
> expected and mysql responds perfectly. I also tested connection through
> the localhost socket with works as expected. Also several other parts of
> my mail system (e.g. courier_auth) connect through the socket and report
> success. And as noted, postfix is able to connect most of the time
> (aliases, virtual maildirs, etc.). Other software on my system, e.g.
> PHP, is also able to connect to mysql successfully.
> 
> I tried all the steps in the MySQL documentation on dev.mysql.com
> suggested to diagnose this error, and all confirmed that the MySQL
> server is working correctly.
> 
> So I find myself not knowing where to look next, and I hope someone here
> knows what might be happening or at least be able to point me in the
> right direction.
> 
> One additional piece of information: I am running on Mac OS/X and as
> part of this upgrade, I installed the 10.5.5 to 10.5.6 upgrade (thus
> needing to restart my computer). This upgrade is known to break postfix.
> So I reinstalled postfix and my main.cf and master.cf files after the
> upgrade and stopped and restarted postfix to be sure. (and mysql)
> 
> What other information might be helpful in diagnosing this?
> 


- check whether any services are chrooted in master.cf (the 5th field
must be set to 'n' and not to 'y' or '-')?

- try using proxymap (foo_maps=proxy:mysql:/etc/).

- make sure the mysql socket is accessible by postfix (and not just by
root).

- try with "hosts = 127.0.0.1" (without "localhost")

why do use sender_canonical instead of canonical? rewrite should be
consistent, and "your sender is the recipient's recipient"...

Re: issue connecting to mysql after upgrade

[mouss]

Jeff Weinberger a écrit :
>> [snip]
>>
>> - try with "hosts = 127.0.0.1" (without "localhost")
> 
> Tried this - no change. :(
> 

ahem. if you do this, you should not hear about a socket. it should use
a TCP connection. can you show the errors?

> [snip]
>>
>> why do use sender_canonical instead of canonical? rewrite should be
>> consistent, and "your sender is the recipient's recipient"...
>>
>>
>>
> 
> This is mostly because I use maildrop as the virtual delivery agent for
> many of the virtual mailboxes. I'm really just testing this, and may end
> up using canonical instead. But here's my thinking:
> 
> I have one user who wants a minor change - sounds silly, but gives me a
> good chance to experiment/learn. I'm rewriting the one address to a
> specific capitalization. I know I'll be doing more with more users soon.
> 
> I want to rewrite when mail goes to someone outside my postfix install.
> canonical_maps would also rewrite inbound mail to that address, which is
> not bad, but not the desired behavior.
> 
> So I am trying sender_canonical_maps to get the behavior I want.
> 

Then you may want to use smtp_generic_maps instead of canonical.

Re: Finding the envelope-sender after always_bcc? (SOLVED)

[mouss]

Jeff Weinberger a écrit :
> 
> I used a pcre: table for smtpd_sender_restrictions and the PREPEND
> action as follows:
> 
> main.cf:
>  smtpd_sender_restrictions = check_sender_access
> pcre:/etc/postfix/smtpd_sender_restrictions.pcre
> 
> smtpd_sender_restrictions.pcre
> /^(.*)/  PREPEND X-Envelope-Sender: ${1}
> 
> this will insert into every message a header "X-Envelope-Sender: "
> followed  by the envelope sender value. It won't pass the
> envelope-sender as SMTP MAIL FROM (dspam wasn't designed to do that,

dspam gets it via LMTP MAIL FROM, and it will pass it back to postfix
with SMT MAIL FROM. I have used this in the past and I'm sure others are
using it now (ping steve?). something in your setup prevents this from
working but I don' think it is a dspam limitation.

> and
> until I take the step to a better before-queue filter or something that
> does, this will work, since all I needed was to capture the
> envelope-sender).
> 
> Limited testing shows this to work. There might be cases beyond what I
> tested that will behave differently than I expect or very oddly.
> 
> Thanks again!

Re: reject_rbl_client after check_policy_service

[mouss]

Rajkumar S a écrit :
> Hi,
> 
> I have a smtpd_recipient_restrictions section as follows:
> 
> smtpd_recipient_restrictions =
> reject_unknown_sender_domain,
> permit_mynetworks,
> reject_non_fqdn_sender,
> reject_non_fqdn_hostname,
> reject_invalid_hostname,
> reject_unauth_destination
> reject_rbl_client sip.invaluement.local
> reject_rbl_client sip24.invaluement.local
> check_policy_service inet:127.0.0.1:9997,
> reject_rbl_client zen.spamhaus.org
> 
> Greylisting server returns  defer_if_permit to defer a mail.  My
> objective is to lookup only those domains in zen whcih has passed
> greylisting test. But in my configuration above mails which are
> greylisted also gets blocked by zen. I guess this is the way
> defer_if_permit works. But is there any way to get the behavior I
> want?
> 

you need to change your policy service to return "defer" instead of
"defer_if_permit".

Re: reject_rbl_client after check_policy_service

[mouss]

Rajkumar S a écrit :
> On Fri, Jan 2, 2009 at 6:19 PM, mouss  wrote:
>> just use:
>> 450 4.7.1 Greylisted Come back after 30 seconds
> 
> Ooops I still get  postfix/smtpd[27954]: warning: restriction
> `450' after `defer' is ignored

Remove the "defer" keyword. Return
"450 4.7.1 Greylisted Come back after 30 seconds"
with no "defer" before it.

> 
> btw, I am using postfix debian package version  2.5.5-1.1 in Debian Lenny
> 
> :(

Re: Finding the envelope-sender after always_bcc? (SOLVED)

[mouss]

Jeff Weinberger a écrit :
> 
> It's definitely my set up. I don't use LMTP to pass the message to
> dspam, I use a transport called "dspam" that uses pipe. That means
> there's no S/LMTP dialog, just the message itself passed as STDIN.
> 

so _you_ are not passing the envelope sender to dspam.

Consider running dspam in "relay mode":
postfix --(LMTP)--> dspam --(SMTP)--> postfix

> I have to move dspam to use LMTP and then move it to a before-queue

why do you want to run it in pre-queue mode? This is not needed and is
not simple to setup.

> content filter so that this workaround becomes unnecessary, but until I
> go to make those changes, this will suffice.
> 
> I'm not completely convinced that dspam will work seamlessly as a
> before-queue content filter, so I'll have to do some testing to see how
> well that works and whether it can do what I need and hand fully formed
> messages with SMTP dialog information back to postfix.
> 

Re: Finding the envelope-sender after always_bcc? (SOLVED)

[mouss]

Jeff Weinberger a écrit :
> On Jan 2, 2009, at 9:20 AM, mouss wrote:
> 
>> Jeff Weinberger a écrit :
>>>
>>> It's definitely my set up. I don't use LMTP to pass the message to
>>> dspam, I use a transport called "dspam" that uses pipe. That means
>>> there's no S/LMTP dialog, just the message itself passed as STDIN.
>>>
>>
>> so _you_ are not passing the envelope sender to dspam.
>>
>> Consider running dspam in "relay mode":
>> postfix --(LMTP)--> dspam --(SMTP)--> postfix
>>
>>> I have to move dspam to use LMTP and then move it to a before-queue
>>
>> why do you want to run it in pre-queue mode? This is not needed and is
>> not simple to setup.
> 

Is there a reason why you keep adding yahoo groups after I remove them
fro CC? This is starting to annoy me...

and by the way, disable the X-DSPAM-Factors header. dspam doesn't encode
it, which results in things like:

X-DSPAM-Factors: 27,
...
a+écrit, 0.01000,

and this is not a valid header.

> If I understand your diagram, then the content_filter would look like:
> 
> content_filter=lmtp:unix:/path/to/dspam args

No.
content_filter=lmtp:inet:127.0.0.1:10024

where the 10024 is the same port used in dspam.conf:
ServerPort10024

of course, dspam must be running in daemon mode.

> 
> and that might pass through the envelope information (I'm not convinced,
> but if dspam can do it, that would be how).

LMTP is similar to SMTP, and dspam can run as an LMTP server (this is
configured in dspam.conf).

> 
> But since dspam can speak LMTP and SMTP 

dspam has a server and a client. so which speaks what?

if we are talking about the server part:

$ cd dspam-3.8.0/src
$ cat daemon.c
...
input = daemon_expect(TTX, "LHLO");
if (input == NULL)
goto CLOSE;
...

it wants LHLO (which is for LMTP), not HELO or EHLO. so no smtp there.


> why would an smtpd proxy be hard
> to set up? It would certainly avoid the bcc issues, etc.

I don't understand why you mix pre-queue and bcc. maybe you confuse
pre-queue with a "not simple content filter"?

> that I"
> experiences by having the message run through postfix twice. After
> reading through SMTPD_PROXY_README, it seems like a bit of a challenge
> to  make it work, but not that hard...what do you think might be difficult?
> 



> Thanks for all your help - over the course of thi dialog I've learned a
> lot about postfix and have become more aware of and proficient with
> parts I knew little about. This has been very helpful.
> 
>>
>>
>>> content filter so that this workaround becomes unnecessary, but until I
>>> go to make those changes, this will suffice.
>>>
>>> I'm not completely convinced that dspam will work seamlessly as a
>>> before-queue content filter, so I'll have to do some testing to see how
>>> well that works and whether it can do what I need and hand fully formed
>>> messages with SMTP dialog information back to postfix.
>>>
>>
> 
> 

Re: Finding the envelope-sender after always_bcc? (SOLVED)

[mouss]

Jeff Weinberger a écrit :

>>> content_filter=lmtp:unix:/path/to/dspam args
>>
>> No.
>> content_filter=lmtp:inet:127.0.0.1:10024
>>
>> where the 10024 is the same port used in dspam.conf:
>> ServerPort10024
>>
>> of course, dspam must be running in daemon mode.
> 
> dspam is running in daemon mode. This makes sense as a setup.
> 
> The example in the dspam docs for postfix shows
> 
> content_filter=lmtp:unix:/path/to/dspam.sock
> 
> which is why I thought unix: instead of inet:
> 

it's ok to use a unix socket, but it's a socket, not the dspam binary
with args.

> is there any difference, other than performance?
> 

I wouldn't put performances into the equation without measurements (one
should tune where the bottleneck is, not in every small piece).

if you use a unix socket, you'll have to make sure it is accessible. In
particular, if someday you decide to chroot postfix, you'll need to put
the unix socket in the chroot jail.

> On a related question (if more broad): some content_filter examples I
> see use content_filter in main.cf and some as "-o content_filter=..." in
> master.cf.
> 
> I understand from prior conversations here that you can't override
> content filters, they are global. (yes?)
> 

no, they are not global. each smtpd may have its own content_filter.
(don't confuse with: "one message, one filter". The latter simply means
that postfix won't split a single message into one message per recipient
before passing it to the content filter).

> So is there an advantage/disadvantage to specifying the content filter
> in main.cf vs. master.cf?
> 

I guess an example is better than literature, no?

here is a "not uncommon setup":
- port 25 is used for "MX" mail (aka inbound mail). it uses the
content_filter defined in main.cf

- port 587 is used for "submission" (authenticated, ...). such mail is
scanned for viruses but not for spam (there's not much things a bayesian
filter could do here, except in simple setups with a site-wide bayes).
so -o is used to set the filter for this service

- sendmail mail is not filtered, because we "trust" the box (there's no
user, ... etc) and we don't want anything blocking such mail. or we use
sendmail to reinject mail after filtering, so we don't want to create a
loop. for this, we set "-o content_filter=".


> 
> I am new to pre-queue filtering and am clearly still confused :)
> 

- content_filter refers to after-the-queue filtering. This means postfix
saves the mail on disk, says "ok" to the client, and sometimes after
that, postfix passes the message to the filter

- proxy_filter refers to pre-queue: postfix keeps the client connected,
passed the message to the filter and waits for the filter response
before responding to the client. This assumes SMTP, because the message
was received via SMTP, so the client wants a single response for the
whole message, and not one response per recipient.

the pipe method that you were using is an example of a content_filter,
and is referred to as a "simple filter" in postfix docs. but a
content_filter need not be a pipe.


> you had asked:
> 
 why do you want to run it in pre-queue mode? This is not needed and is
 not simple to setu
> 
> so I thought it might be hard.
> 

and it is. reread what I said about dspam and lmtp...

> It's not important for now...getting dspam working as LMTP will be fine
> (assuming it passes along all the right information once it works)
> 

Re: Finding the envelope-sender after always_bcc? (SOLVED)

[mouss]

Jeff Weinberger a écrit :
> 
> OK, thanks. I will set up dspam to listen on port 10024 - seems to make
> the most sense. I don't need a localhost:10024 entry in master.cf then?
> right?
> 

no, 10024 will be used by dspam. your postfix should have a
127.0.0.1:10025 to get mail back.


>>
>>> So is there an advantage/disadvantage to specifying the content filter
>>> in main.cf vs. master.cf?
>>>
>>
>> I guess an example is better than literature, no?
>>
>> here is a "not uncommon setup":
>> - port 25 is used for "MX" mail (aka inbound mail). it uses the
>> content_filter defined in main.cf
> 
> right, as I do right now.
> 
>>
>>
>> - port 587 is used for "submission" (authenticated, ...). such mail is
>> scanned for viruses but not for spam (there's not much things a bayesian
>> filter could do here, except in simple setups with a site-wide bayes).
>> so -o is used to set the filter for this service
> 
> I need to set this up also - seems easy, but is there an example of the
> localhost:587 master.cf entry somewhere I could start with?
> 

your master.cf should already contain a "submission" service (it's
commented out by default). you can add -o conten_filter and other
parameters.


>>
>> - sendmail mail is not filtered, because we "trust" the box (there's no
>> user, ... etc) and we don't want anything blocking such mail. or we use
>> sendmail to reinject mail after filtering, so we don't want to create a
>> loop. for this, we set "-o content_filter=".
>>
> 
> do you mean the re-injection into postfix? I have "-o content_filter="
> there already. I'm re-injecting mail via SMTP, not sendmail...
> 

so you already had an example that overrides the content_filter in
master.cf ;-)

Re: Finding the envelope-sender after always_bcc? (SOLVED)

[mouss]

Jeff Weinberger a écrit :
> I'm guessing I should leave my port 25 (smtp) entry to allow submission
> on that port with authentication (leaving
> "smtpd_client_restrictions=permit_sasl_authenticated...") - is there any
> harm in that?
> 

no. but separating roles makes configuration easier. so encourage users
to use 587.

Re: syslog convert to lowercase

[mouss]

ram a écrit :
> Can all the logs be made in lowercase only atleast the sender and the
> recipient emailids
> 
> Since we have huge logs, searching for something in the logs is quite
> expensive.

why not write a script to parse the logs and store them in a format that
makes searching easier?


> And doing it case insensitive really sucks the resources

really?

> If postfix could log everything in lowercase then that would help a lot 
> 
> 

Re: Allowing return email

[mouss]

postfix@cmulcahy.com a écrit :
> Greetings:
> 
> I'm running several spam-filtering tools including Postgrey,
> SpamAssassin, etc.  I would like to make replying to mail I have sent
> easier.
> How can I automatically white-list addresses to whom I have sent email?

you can write a script that parses logs and updates an access map. you
can run this script on old logs.

or you can do it in a policy service.

WARNING. if you whitelist sender addresses, then spammers who forge
these addresses will have a free ride...

Re: running a second custom smtpd on second IP address

[mouss]

Drew Derbyshire a écrit :
> I've got a postfix server running which accepts several domains on it's
> primary smtpd (kew.com, *.wild.kew.com, thinfilmmfg.com,
> *.wild.thinfilmmfg.com, ...), all protected by the usual (and some
> unusual) SPAM filters.  Life is good.
> 
> I'd like to set up a secondary smtpd on a second IP address with it's
> own MX record which accepts mail for an additional domain
> (*.bff.kew.com) with fewer checks, but does NOT accept mail for the
> other domains listed above.  I did a master.cf like this, but it accepts
> the wrong (original) domains defined in main.cf and the virtual domains
> configuration:
> 
> primary.kew.com:smtp
>   inet  n   -   n   -   -   smtpd
>   -o content_filter=huntress:
>   -o cleanup_service_name=scrubber
>   -o smtpd_tls_cert_file=/usr/local/certs/fantasy-factory.kew.com.pem
>   -o smtpd_tls_key_file=/usr/local/certs/fantasy-factory.kew.com.pem
>   -o smtpd_tls_security_level=may
>   -o smtpd_tls_auth_only=yes
> primary.kew.com:10025
>   inet  n   -   n   -   -   smtpd
>   -o smtpd_tls_cert_file=/usr/local/certs/fantasy-factory.kew.com.pem
>   -o smtpd_tls_key_file=/usr/local/certs/fantasy-factory.kew.com.pem
>   -o smtpd_tls_security_level=encrypt
>   -o smtpd_tls_auth_only=yes
>   -o smtpd_sasl_auth_enable=yes
>   -o smtpd_sasl_security_options=noanonymous
> secondary.kew.com:smtp
>   inet  n   -   n   -   -   smtpd
>   -o content_filter=huntress:
>   -o relay_domains=mail.kew.com,.mail.kew.com
>   -o virtual_alias_domains=mail.kew.com,.mail.kew.com
>   -o smtpd_tls_cert_file=/usr/local/certs/ffactory.kew.com.pem
>   -o smtpd_tls_key_file=/usr/local/certs/ffactory.kew.com.pem
>   -o smtpd_tls_security_level=may
>   -o smtpd_tls_auth_only=yes
>   -o smtpd_recipient_restrictions=
> 
> Where did I blow it, and more importantly, how do I fix it?
> 

you can't have an empty smtpd_recipient_restrictions, as this would mean
all mail is accepted, making you a universal open relay.



Instead of changing the list of domains (See Wietse mail), you can list
all domains (primary and secondary), then use check_recipient_access to
reject on the "wrong MX". For example:

secondary:smtp ...
  -o mynetworks=127.0.0.1
  -o smtpd_sender_restrictions=${smtpd2_sender_restrictions}
  -o smtpd_recipient_restrictions=${smtpd2_recipient_restrictions}


== main.cf:

smtpd2_sender_restrictions =
check_recipient_access hash:/etc/postfix/secondary_domains
reject

smtpd2_recipient_restrictions =
permit_mynetworks
reject_unauth_destination

== secondary_domains
secondary.kew.com   OK


and do the opposite on the primary (reject mail to *...@secondary).

Re: Postix relay gateway - "Recipient address rejected" notification verbosity ...

[mouss]

Antony a écrit :
> Happy new year to all of you ! ;o)
> 

Bonne année!

>  [snip]
> 
> smtpd_recipient_restrictions =
> 
> reject_invalid_hostname,
> 
> reject_non_fqdn_helo_hostname,
> 
> reject_non_fqdn_hostname,
> 

this is the same as reject_non_fqdn_helo_hostname



> reject_non_fqdn_sender,
> 
> reject_non_fqdn_recipient,
> 
> reject_unknown_sender_domain,
> 
> reject_unknown_recipient_domain,
> 



put reject_unlisted_recipient here.


> reject_unverified_recipient,
> 
> reject_invalid_helo_hostname,

this is the same as reject_invalid_hostname above.

> reject_unlisted_recipient,
see above.

> 
> check_recipient_maps,

what's this?

> 
> reject_unlisted_sender,
> 
> permit_mynetworks,
> 
> permit_sasl_authenticated,
> 
> reject_unauth_destination,
> 
> reject_rbl_client bl.spamcop.net,
> 
> reject_rbl_client list.dsbl.org,

dsbl is dead.

> 
> reject_rbl_client zen.spamhaus.org,
> 
> reject_rbl_client cbl.abuseat.org,

cbl is included in zen, so remove it.

> 
> check_policy_service inet:127.0.0.1:6,
> 

Re: Allowing return email

[mouss]

Ralf Hildebrandt a écrit :
> * postfix@cmulcahy.com :
>> Greetings:
>>
>> I'm running several spam-filtering tools including Postgrey,  
>> SpamAssassin, etc.  I would like to make replying to mail I have sent  
>> easier. 
>>
>> How can I automatically white-list addresses to whom I have sent email? 
> 
> SpamAssassin has "PenPals" for exactly that
> 

you mean amavisd-new?

Re: Header/body checks question, problem.

[mouss]

KLaM Postmaster a écrit :
> I am having a problem with some legitimate emails being rejected by
> header and/or body checks. Both the header and body checks are from
> Jeffrey Posluns' write up,without any mods.
> Among the stuff being rejected is the output of pflogsumm, I run a daily
> a report and email it to postmaster. I was not getting the reports so I
> checked the maillog and found that these messages, among others, were
> being rejected with "Your email is not using a proper character set.
> ...". 


if header/body checks reject legitimate mail, then something is wrong.

> In the case of pflogsumm, and some of the other automatic email, I
> really don't have much say in its internal format.
> 
> 1) As I try to control spam by using amavisd, spamassassin, clamv,
> postgrey and so far seem doing OK (touch wood), are header and/or body
> check worthwhile as an anti-spam measures. Could they be dropped.
> 

header and body checks can be used to reject some spam (forged received
headers, "banned" attachment types, ...), but not as a general content
filter.

> 2) If they are worthwhile, is there a way of not applying them to all 
> mail except that destined for postmaster.

you can't. but they can be skipped for mail submitted via the sendmail
command. for that, define a specific cleanup and use it in pickup (in
master.cf).

but this is not a good idea. The fact that these checks are catching
your legitimate mail is an indication that they could reject legitimate
mail from others and to other users.

> If I understood the
> documentation it would seem that  these checks are applied by "cleanup"
> after the other checks have been completed and are not susceptible to
> access checks. If this is the case, is there some other way of making
> them conditional on recipient, something like an access list to these
> checks.
> 
> =
> 
> As I administer a very small number of virtual users I put the attached
> script together to help me. Any thoughts, ways of doing the same thing
> only better etc.
> 
> TIA
> JLA
> 
> 

Re: localhost and smarthost

[mouss]

Asif Iqbal a écrit :
> Hi All
> 
> All my email gets relayed thru gmail as it should. But how do I tell
> it to send all localemails to local spool and not send it to gmail?
> 

what kind of "localemails"? if these use a local domain, add the domain
to mydestination. if they use an external domain, use
virtual_alias_maps. for example:

vad...@gmail.comiq...@localhost


> My laptop does not have any valid domain
> 

You could get a free one at dyndns.

> My postfix configured like this
> 
> iqb...@ghar-iqbala:~$ postconf -n
> alias_database = hash:/etc/aliases
> alias_maps = hash:/etc/aliases
> append_dot_mydomain = no
> biff = no
> config_directory = /etc/postfix
> inet_interfaces = all
> mailbox_size_limit = 0
> mydestination = ghar, ghar-iqbala, localhost.localdomain, localhost
> myhostname = ghar-iqbala

myhostname should be fqdn.

> mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
> readme_directory = no
> recipient_delimiter = +
> relayhost = [smtp.gmail.com]:submission
> smtp_sasl_auth_enable = yes
> smtp_sasl_password_maps = hash:/etc/postfix/sasl/passwd
> smtp_sasl_security_options = noanonymous
> smtp_sasl_type = cyrus
> smtp_tls_security_level = encrypt
> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
> smtp_use_tls = yes
> smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
> smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
> smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
> smtpd_use_tls = yes
> 
> 
> 

Re: localhost and smarthost

[mouss]

Asif Iqbal a écrit :
> On Sun, Jan 4, 2009 at 6:11 AM, mouss  wrote:
>> Asif Iqbal a écrit :
>>> Hi All
>>>
>>> All my email gets relayed thru gmail as it should. But how do I tell
>>> it to send all localemails to local spool and not send it to gmail?
> 
> I see qmgr sends the mail to smtp and local like in this flowchart
> 
> http://www.postfix.org/OVERVIEW.html#delivering
> 
> How do I tell qmgr which one should be delivered to local and which one to 
> smtp?
> 

maybe by reading what I said? or should I repeat? if so, let's go:

- what do you mean by "localemails"? which mail do you want to deliver
locally?

- if it's for specific addresses, use virtual_alias_maps as I already said.

Re: How to relay AND store all emails on a gateway ?

[mouss]

Antony a écrit :
> I slept some hours, my mind is relaxed and less confused than those
> last days, let's go ! ;o)
> 
> Thanks to Wietse and mouss, my gateway is now fully functional, and relays
> emails to my server :
>Internet --> mx1.mydomain.com[my gateway with postfix] -->
> mx2.mydomain.com (only MX1 acts as a DNS MX for all emails sent to
> mydomain.com)
> First goal is achieved.
> 
> Next step (in a few month) will be to migrate our mx2 email server from
> Lotus Notes to mx1, which will be in a few month our final email sever.
> 
> Then I'm searching for the right solution not only to forward emails to mx2,
> but to store all of them (dovecot) on mx1 in Maildir format.
> Actually, I did not find any answer on the subject. Either emails are
> relayed, either they are stored ...
> Is it possible, and what is the nicest native solution according to such a
> configuration please ?
> 

you need to "duplicate" mail.


recipient_bcc_maps = pcre:/etc/postfix/recipient_bcc.pcre

== recipient_bcc.pcre
/^(.*)@example\.com$/   $...@dovecot.example.com


an alternative is virtual_alias_maps but you must not break recipient
validation with wildcard enrties.


> -
> #cat main.cf |grep -v "#"


1. some variables may contain a '#'. so your grep -v is not "adequate".
but this is not important...

2. you don't need to wake up the cat. most unix commands accept files:
grep -v "^#" main.cf

3. but more importantly, we rarely read main.cf snippets. you should
send the output of 'postconf -n' instead.

Re: Relaying/forwarding query

[mouss]

Nigel Gilbert a écrit :
> 
> 
> On 04/01/2009 19:33, "Sahil Tandon"  wrote:
> 
>> Nigel Gilbert wrote:
>>
>>> I have Postfix running on dusty.soc.surrey.ac.uk.  I would like mail from
>>> the internet addressed to unknown local users on this server (e.g. to
>>> x...@soc.surrey.ac.uk) to be re-addressed and forwarded
>> Before continuing, please clarify: are the unknown local users known
>> relay recipients?  Or are you trying to devise some sort of 'catch-all'
>> that forwards *all* mail to unknown users (local or otherwise) to this
>> other mail server?  The latter is a bad idea.
>>
>> [...]
> 
> The latter, but although it may in general be a bad idea, (1) the other
> server (surrey.ac.uk) is well set up for catching and dealing with spam etc.
> (e.g. all mail sent to it is processed through messagelabs span filtering),
> and (2) there is no easily accessible list of users that are known on
> surrey.ac.uk, but unknown to soc.surrey.ac.uk.
> 

the question is whether some users may be rejected by the second server.
if so, they must also be rejected by the first one.

if this is ok, then simply declare the domain as a relay domain and use
virtual_alias_maps to deliver some users locally.

Re: How to relay AND store all emails on a gateway ?

[mouss]

Antony a écrit :
> Indeed it should work. But, I was not clear, my mistaken. 
> I do not wish to use dovecot as a mail server, but only as an alternative
> LDA for Postfix (+ for SMTP SASL purposes).
> Possible ?
> 


hmmm. sorry. I'm not sure to understand...

my understanding was that you wanted mail for f...@example.com to be
devlivered "twice": once to a relay MTA and once to dovecot.


> And if not, are virtual_alias_maps or recipient_bcc_maps forward via smtp
> the solution ? It seems for me a "heavy" solution for what I have to do.
> Isn't there a "local delivery way" to proceed ?
> 

you need to tell us exactly what you want to do with which mail.

abruti, va (je plaisante:)

per recipient transport [Was: Evaluation of maps in local or virtual address classes]

[mouss]

Victor Duchovni a écrit :
> [snip]
> Why per-recipient transport lookups? Often better to rewrite to a domain
> where the entire domain is handled by lmtp(8).
> 

is there a benefit in avoiding per recipient transports? or said
otherwise: is there a way to tell postfix to only lookup domains?


>> But what do I do to tell Postfix recipi...@example.com is a valid recipient?
> 
> Use virtual_mailbox_maps.
> 
>> Can I reuse my transport map and add it to local_recipient_maps,
>> virtual_alias_maps or virtual_mailbox_maps as required?
> 
> Don't add $transport_maps to virtual_mailbox_maps, but if per-recipient
> transport entries are the right solution, use a common table that you
> add to both:
> 
>   lmtp_user_transport_maps = :
>   transport_maps = ... $lmtp_user_transport_maps
>   virtual_mailbox_maps = ... $lmtp_user_transport_maps
> 
> Provided the same users will never reach virtual(8), the fact that
> the RHS is transport-valued rather than mailbox-path-valued is not
> a problem.
> 

Re: Different Postfix master.cf entry depending on outgoing domain.

[mouss]

Adam a écrit :
> What I'd like to do :
> 
> Append different altermime disclaimers depending on outbound domain.
> 
> 
> What I have :
> 
> I've setup a 'middle-man' box which is only going to run postfix and
> altermime.  It will then fwd via relayhost to my outbound servers
> (also postfix).
> 
> 
> I understand that amavisd-new has begun adding this capability, but
> until it is finalized I didn't want to 'bank on it'.
> 
> Is there a way I can have mail sent through different "smtpd's"
> depending on the outgoing domain?

if you mean the recipient domain, then no, unless you want to run
multiple postfix instances.

do whatever you want in the filter.

>  If so I could throw a different
> disclaimer depending.
> 
> 
> (I understand the argument against this crap, I only have so much input...)
> 
> 
> My postfix config is very vanilla (distro provided, Mandriva 2009),
> but I can post my master.cf (and postconf -n) if necessary.
> 
> 
> Thank you.
> ADAM

Re: per recipient transport [Was: Evaluation of maps in local or virtual address classes]

[mouss]

Victor Duchovni a écrit :
> On Mon, Jan 05, 2009 at 03:31:52AM +0100, mouss wrote:
> 
>> Victor Duchovni a ?crit :
>>> [snip]
>>> Why per-recipient transport lookups? Often better to rewrite to a domain
>>> where the entire domain is handled by lmtp(8).
>>>
>> is there a benefit in avoiding per recipient transports?
> 
> Simplicity, also reduces temptation to do LDAP or SQL transport lookups,

unfortunately, this is exactly what I want to do: put everything in *sql
to ease mgmt. of course, it is possible to dump the sql data, but I am
talking about a web UI where I'd prefer the web app no have any
privileges. I guess a cron (to dump data) is the best I can do if I
don't want to write an "update" daemon?

> which are problemactic under load, because qmgr latency cannot be
> ammortized via concurrency (there is only one queue manager).
> 
>> or said otherwise: is there a way to tell postfix to only lookup domains?
> 
> No.
> 

Re: How to relay AND store all emails on a gateway ?

[mouss]

Antony Simonneau a écrit :
> Forget dovecot.
> For each incoming email, basically I want both to store it in Maildir format
> and relay it via SMTP.
> 


it's the same whether you deliver with dovecot or directly with postfix.

to deliver both to a relay and to a "local" mailbox, you need to
"duplicate" the message, which can be done with bcc options or virtual
aliases.

Re: Catchall Domains

[mouss]

Corey Chandler a écrit :
> [snip]
>>>
>> While I've got my postconf output up here, I'm also attempting to have
>> this gateway rewrite all addresses of the form u...@server.example.com
>> to u...@example.com before looking for a match in the transport /
>> relay recipient table.  Is there a way to achieve this within Postfix?
>>
>> -- CJC
> Whoops, sorted it out.  The problem came from my using relay_recpients
> as a transport map as well; I had to declare my wildcarded domain both
> with and without the @ in it...


instead oh gross hacks, use a script to generate two maps. don't reuse
maps like that. if one day you decide to add a transport entry for some
domain (to select different options for smpt for instance), it will
"accidentally" become a relay domain...

Re: escape characters when inserting into a table

[mouss]

Evan Platt a écrit :
> Am I missing what this has to do with postfix, or is it just me?
> 

the classical "MUA address completion" problem. he typed "post" by his
MUA completed to postfix... and he didn't notice.


> At 09:56 AM 1/7/2009, you wrote:
>> Hi All,
>>
>> My apologies if I sent the wrong question but I need your help.
>>
>> I am using perl + postgres in an app am writing. However I am failing
>> to find a function to escape characters just like you use addslashes
>> in php.
>>
>> Do I have to use a regex expression to do that or there is a function
>> to use.
>>
>> Thanks in advance.
> 

Re: Blocking Spam

[mouss]

bijayant kumar a écrit :
> My question is, spammers forges the from address and sends the spam where 
> from address and to address are same. Like in my case I am getting the spam 
> mails from bijay...@kavach.com to bijay...@kavach.com. So, I googled and 
> found that after reject_unauth_destination I have to add one 
> check_sender_access in which I have to write kavach.com REJECT. It means that 
> reject all the mails which are not doing smtp-authetication and the domains 
> are local, right? 
> To test the above settings I telnetted to 192.168.99.22 (another postfix 
> installed machine) and tried to send "mail from and rcpt to" as 
> bijay...@kavach.com. As expected it got rejected. But I have also received 
> the bounce message also from the sender "<>".  I am wondering if this is by 
> default then my users will get lots of bounce notification mails which they 
> have never sent. So, the total idea behind implementing this feature will 
> fail. There has to be some way that I am not able to find. Please suggest how 
> should I proceed. Am I testing in the wrong way or missing any thing?
> 

and the test succeeds. the postfix that you configured _rejected_ the
transaction. it did not send a bounce. The bounce was sent by
192.168.99.22 and this is the right behaviour for a "real" MTA.

if the spam is sent by ratware (and not a "real" MTA), the ratware will
generally ignore the rejection and no bounce will be created. so far so
good.

if the spammer sends using a real MTA, you will get a bounce. The
BACKSCATTER README contains ideas to help fight backscatter. This won't
block all backscatter, but it's a good start.


> 
> Thats not a case, we are receiving the Bounce messages for local users.

if the above is not enough, use a policy server (or a real time log
parser) to temporarily block the offending IP.

Re: Reject_unlisted_recipient and "wide" aliasing

[mouss]

Roman Medina-Heigl Hernandez a écrit :
> Noel Jones escribió:
>> [snip]
>> Use 1-1 mappings.  Use a little script and a Makefile to let the
>> computer build the aliased domain from the real domain list you already
>> maintain.  Size of the table is not an issue.
>>
>> Your postconf output looks OK.
> 
> Yes, all tasks can usually be automatized but sometimes it's good to
> simplify things. 
> [snip]


Here's an (I hope, illustrative) example of a mysql setup where this is
not a problem:

- table User contains "user" and "domain" columns.
- table DomainAlias contains "alias" and "destination" columns.


query = select User.domain from User, DomainAlias where
alias = '%s' and destination = domain
(the user column must never be empty).

The limitation is that you can't use "recursive" domain aliases, so you
can't implement this:

@example.com@example.org
@example.org@example.net

but such recursive aliases would be expensive anyway, and one can
resolve them ahead of time (in the UI that adds them, for instance).

Of course, you can also use a policy service to "fix" the problem.

Re: "forcing" authenticated users to use port 587?

[mouss]

Jeff Weinberger a écrit :
> Hi:
> 
> Based on good practice and the help and urging of some of the gurus on this
> list, I am moving my users to using the submission service (port 587)
> instead of port 25 to send mail from their mail clients.
> 
> Once most of them move, I'd like to start warning the ones who don't that
> they should (ok, maybe just bugging them). But then I was thinking I might
> eventually want to require that they use port 587.
> 
> My question is really two-fold:
> 
> 1) using the controls in postfix, is it possible to prevent authenticated
> users from using port 25 to submit mail? Is there a construct that would do
> that without interfering with incoming mail from anywhere?
> 

You are certainly using permit_sasl_authenticated. so to prevent auth on
port 25, simply remove this check from smtpd_recipient_restrictions.

> 2) even if it's possible, it is advisable (I know no one is shy about
> offering opinions here, and I hope if you have one, you'll voice it :) )?
> 

There are benefits in separating MX and submission functions, either by
using different ports (recommended) or by using a different IP. for
example, you can use different header_checks and body_checks. you can
block some IPs/networks on 25 but still allow your users to come from
these IPs... you avoid having to implement "exceptions" in your smtpd
restrictions... etc.

It is also hoped that future versions of MUAs will be "support" port 587
(they could try to see if it is available and propose it as the default
port, ... etc).

All that said, you don't need to go that road too quickly. Many users
have no idea what you tell them (I've seen that with software developpers).

Re: multiple e-mails on from:

[mouss]

Noel Jones a écrit :
> Cameron Camp wrote:
>> I have a Postfix setup which runs several mailman lists. I'm getting in
>> the headers:
>>
>> From: nore...@domain.com, r...@www.domain.com
> 
> The From: header is text added by the mail client or your list
> processor.  This isn't a postfix issue.
> 

or his client uses

From: noreply r...@www.domain.com

and postfix adds @myorigin to "the non fqdn component".

In either case, he should fix his client. maybe he wants

From: noreply 

safe wildcard aliasing with mysql [Was: Reject_unlisted_recipient and "wide" aliasing]

[mouss]

Roman Medina-Heigl Hernandez a écrit :
> [snip]
> Any ideas to improve this? I think this could be solved with more mysql
> magic...
> 

let's use these "simplistic" tables (no id/keys... for simplicity):

- a User table, with the following columns
 * user: the user-part of an email address
 * domain: the domain part.


- a DomainAlias table, with the following columns
 * alias: This is a domain name
 * destination: This too is a domain name


now, we set

virtual_alias_maps =
# user aliases
proxy:mysql:/etc/postfix/maps/mysql/user_alias
# domain aliases
proxy:mysql:/etc/postfix/maps/mysql/domain_alias


user_alias is used for "user" aliases (no wildcard alias). You already
know how to do this so I'll skip it.

domain_alias is used for domain aliasing. The query is

query =
  SELECT
user
  FROM
DomainAlias, User
  SELECT
alias = '%d'
  AND
User.user = '%u'
  AND
User.domain = destination

so there are two things:
- we use two maps in virtual_alias_maps. one for users and one for
domains. the latter implements wildcard aliases
- but we only return a result if the "destination" user exists (in the
User table).

is it clear now?

Re: "forcing" authenticated users to use port 587?

[mouss]

jeff_homeip a écrit :
> 
> Thanks for pointing it out - I've read it several times already.
> 
> "ORIGINATING" is not mentioned at all in MILTER_README.
> 
> And while I'm sure the postconf(5) brief explanation is meaningful to you, it 
> means 
> nothing to me. 
> 
> As I noted, I am completely unfamiliar with milters, and don't know what a 
> milter daemon 
> is.
> 
> I don't expect a tutorial, but I am hoping that the very knowledgeable people 
> on this list 
> can suggest somewhere where I can learn enough to understand what this:
> 
> milter_macro_daemon_name=ORIGINATING
> 
> does and what it means.
> 
> Any explanation of why it is suggested in the default set up in the 
> distribution is helpful 
> as well.
> 

let's say you use a milter to DKIM sign mail. you generally only want to
sign "submitted" mail. the milter will check if ORIGINATING is set and
will decide to sign or not.

>|snip]

Re: getting dns error

[mouss]

James D. Parra a écrit :
> 
>> -Original Message-
>> From: James D. Parra 
>> Sent: Thursday, January 08, 2009 6:51 PM
>> To: Postfix users (E-mail)
>> Subject: getting dns error 
>>
>>
>> Hello,
>>
>> I am getting the following error when sending to the below 
>> mail server.  I added the name of our internal relay server 
>> to our public dns and a ptr record, but I am still getting 
>> the error below.
>>
>> 
>> host mxi4p.craigslist.org[208.82.236.164]
>> said: 554 5.7.1 : Client host 
>> rejected: rDNS/DNS
>> validation failed. Please setup matching DNS and rDNS 
>> records:(in reply to RCPT TO command)
>> 
>>
>> Is there something else I need to add the postfix server? 
>> This is an internal mail relay server, behind a firewall and 
>> not accessible to the public. It only sends mail for our 
>> internal users and does not receive mail.
>>
>> Many thanks,
>>
>> James 
>>
> 
> Hello,
> 
> Well, I fixed my DNS after the changes I made were wrong. If anyone
> responded to my message could you kindly resend. I'd like to fix the above
> problem and have my postfix setup compliant.
> 


The mail you posted contains:

Received: from smtp-relay.musicreports.com (unknown [207.47.100.34])

if you asked for a custom rdns that fixes the problem, then you'll need
to wait for DNS propagation.

Re: Need help with postfix migration

[mouss]

carconni a écrit :
> HI,
> 
> Two days ago my company mail server died. I was able to set up a
> temporary server until I could get the data off the old drive.  Tonite I
> moved mailman and /var/spool/ over and reconstructed the mail boxes.
> 
> Everything looked great until I tried to send mail. Everyone can get
> mail, but no one can send.
> 
> My log is filled with:
> : fatal: connect #11 to subsystem private/proxymap: Connection
> refused

are there errors before this one?

make sure proxymap is not commented out in your master.cf.

> Jan  9 02:50:27 apps26 postfix/master[9875] : warning: process
> /usr/libexec/postfix/smtpd pid 14380 exit status 1
> Jan  9 02:51:37 apps26 postfix/smtpd[14617] : warning: connect
> #2 to subsystem private/proxymap: Connection refused
> mail:/var/log root# postfix/smtpd[14617] : warning: connect #1
> to subsystem private/proxymap: Connection refused
> 
> I tried postfix upgrade-configuration and set-permissions but neither
> worked.  I'm not sure what happened here, I followed these set of
> instructions to move the user data:
> 
> cp /var/spool/imap and then su root
> mv /var/imap /var/imap.old
> mkdir /var/imap
> /usr/bin/cyrus/tools/mkimap
> chown -R cyrusimap:mail /var/imap
> sudo -u cyrusimap /usr/bin/cyrus/bin/reconstruct -i
> 
> Is there anything I can do to rescue Postfix?
> 
> 
> 
> 

Re: Problem with http://www.postfix.org/postconf.5.html

[mouss]

Luigi Rosa a écrit :
> Markus Schönhaber said the following on 10/01/09 13:35:
> 
>> Is there something wrong with the server / anyone else seeing this?
> 
> Confirmed here (ADSL connection in Italy with British Telecom).
> 
> Same problem with Firefox on Linux, Firefox on Windows and MSIE7, latest 
> version
> of the browsers.
> 

same with konqueror (ADSL as well).

however, curl gets the full page. and the headers show a different
content-length in firefox vs curl...

with firefox, I see
X-Pad: avoid browser bug
but I don't think this is related.



> The only difference I noticed is that telnettig port 80 e GETting the page the
> last bytes I receive are:
> 
> 
> 
> Note 2: for security reasons, the virtual(8)
> delivery agent will
> silently ignore requests to use the proxymap(8)
> server. Instead
> it will open the table directly. Before Postfix version 2.2, the
> virtual(8) delivery agent will terminate with a
> fatal error.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Ciao,
> luigi
> 

Re: Question on allowing a specific server to send mail

[mouss]

David Cottle a écrit :
> I have hardened by main.cf file:
> 
> smtpd_sender_restrictions = check_sender_access
> hash:/var/spool/postfix/plesk/blacklists, 

don't put your maps inside the queue directory. There are a lot of
better places.

> reject_non_fqdn_sender,
> reject_unauthenticated_sender_login_mismatch, reject_unknown_sender_domain
> 
> and
> 
> smtpd_recipient_restrictions = permit_mynetworks,
> permit_sasl_authenticated, reject_unauth_destination,
> reject_non_fqdn_recipient, reject_unknown_recipient_domain,
> reject_unlisted_recipient, reject_unverified_recipient
> 
> 
> I have a local server here that sends denyhost reports to my mail
> server across the LAN directly.  Since I did this its not getting
> reports anymore.  I think most likely to 'reject_non_fqdn_sender',
> 'reject_unknown_sender_domain'.  Is there a way I can specify my own
> internal name (I have my own internal DNS) I gave the server to
> 'force' it to accept emails from this server.
> 

put permit_mynetworks at the beginning of your smtpd_sender_restrictions.

alternatively, put your smtpd_sender_restrictions checks in
smtpd_recipient_restrictions, after reject_unauth_destinaion.

> Any ideas?
> 
> Thanks!

Re: Adding a table to proxy_read_maps...

[mouss]

Charles Marcus a écrit :
> On 1/11/2009, Victor Duchovni (victor.ducho...@morganstanley.com) wrote:
>>> First question... is there a reason that none of the *_limit_maps are
>>> included in proxy_read_maps by default? I.e., maybe doing this is not
>>> recommended?
> 
>> Ask the maintainers of the unofficial VDA quota patch.
> 
> I didn't know I was using that patch, but considering your reply,
> apparently the *_limit_maps are a sure sign of it? I'm on gentoo, and
> have the vda USE flag explicitly DISABLED...
> 
> Hmmm... closer examination shows that I am not actually using this patch
> OR table, since it (the Table) doesn't show up in postconf -n output,
> even though it is specified in main.cf. 

so you probably don't use the patch. you can convince yourself using:

# postconf -d|grep limit_maps

(it should return nothing).

More generally,
to see whether a parameter foo_bar_mumble is a postfix parameter, run
# postconf foo_bar_mumble

if it's not a postfix parameter, you get:
postconf: warning: foo_bar_mumble: unknown parameter


> This system was originally set
> up by someone else, so they must have set this, and I just never noticed
> it, since I have not actually implemented quotas yet - although I've
> been toying with the idea, which is why I had not commented out those
> lines in main.cf...
> 

better remove them.


> I've been planning on switching this installation over to dovecot soon
> anyway for POP/IMAP access, so will just use the dovecot LDA and quota
> plug-in if/when I decide to implement quotas...
> 
>> There is as-yet no support for "+=" in main.cf parameter settings.
> 
> Ok, thanks for the confirmation...
> 

Re: smtp_helo_name ignored

[mouss]

David Cottle a écrit :
> 
> 
> Sent from my iPhone
> 
> On 12/01/2009, at 15:36, Sahil Tandon  wrote:
> 
>> On Mon, 12 Jan 2009, David Cottle wrote:
>>
>>> smtpd_banner = gateway.aus-city.com
>>>
>>> I want the helo to say that name. I assume I drop the hostname and what
>>> about the ESMTP?
>>
>> I think you may be confused about the HELO; the smtpd_banner is simply
>> what
>> follows the 220 when a client connects to your smtpd.  It is common
>> practice
>> for servers that support ESMTP to indicate this in their banner; no
>> harm in
>> leaving it there.  Although Postfix by default sends EHLO even if
>> ESMTP does
>> not appear in the banner, some other MTAs might need to see ESMTP to know
>> your server supports it.
>>
>> -- 
>> Sahil Tandon 
> 
> The top posting is what the iPhone does I tried manually forcing it to
> the bottom.
> 
> Okay I set myhostname = gateway.aus-city.com
> 
> Now it replies properly, bit it still fails RFC, I get this now (it's
> better as atleast now the name exists not a unknown server)
> 
> mail.aus-city.com claims to be host gateway.aus-city.com but that host
> is at 202.129.79.106 (may be cached) not 203.206.129.129
> 


smtp_helo_name = mail.aus-city.com

assuming, 203.206.129.129 is the "outgoing" IP.

if you have multiple "outgoing" IPs, just live with that. most people
won't check this (unless you server has a "bad" reputation that causes
additionnal/aggressive checks).


> There are 28 domains on the server all on individual IPs.
> 

when it comes to email, all domains can be served with one IP. so if
203.206.129.129 is the "outgoing" IP, use it for all these domains (for
smtp I mean).

the alternative is to run one postfix instance per IP/domain, but that's
a lot of work (and may be tricky).


> Any solution or live with it? I assume it's much better having a real
> name rather than a non existent one?
> 

Re: bad command startup --throttling

[mouss]

Nathan Huesken a écrit :
> Hello,
> 
> I am trying to configure my postfix mail server using this guide:
> http://wiki.dovecot.org/HowTo/DovecotLDAPostfixAdminMySQL
> 
> So it is a mysql, dovecot, postfix, postfixadmin setup.
> 
> In my mail.warn, I get lots of messages like this:
> postfix/master[9506]: warning: /usr/lib/postfix/smtpd: bad command startup -- 
> throttling
>  

the "real" error is in other log lines. probably few lines before the
throttling line.

> (often with pipe or trivial-rewrite instead of smtpd).
> 
> At the same time, I get "Cannot allocate memory" in all types of contextes.
> The server has 256MB of ram and ~40MB free most of time. Should that be 
> enough?
> 

Re: Can't stop UNDELIVERED MAIL RETURNED TO SENDER emails

[mouss]

David Cottle a écrit :
> Magnus Bäck wrote:
>> On Monday, January 12, 2009 at 22:19 CET,
>>  David Cottle  wrote:
> 
>>> The messages are all faked spam supposedly sent from mail addresses
>>> that are valid off the server domains. So therefore non valid
>>> addresses are being rejected.  So how can these be dealt with they all
>>> look genuine in the headers.  My domains all run strict SPF policy
>>> with reject mail when SPF does not resolve to pass, but as these are
>>> bounce emails the servers of course have no SPF records therefore
>>> don't get skimmed off.
>> Please follow the instructions and post logs showing how these messages
>> enter your system. Had the messages been rejected they would not have
>> ended up in your queue. They are instead bounced, and you haven't
>> provided us with any details about why this happens. Therefore we cannot
>> suggest any course of action without resorting to guessing.
> 
> Thanks all, I just can't figure out why they get bounced, so I attach
> here..  I will only attach two:
> 

Please take the time to understand what others have tried to tell you.
the answer to your problem is in postfix logs, not in the bounces, nor
in the mailq.


1- find out where are postfix logs. they may be in /var/log/maillog or
/var/log/mail.log or another file (the location is specified in
/etc/syslog.conf if you use the "standard" syslog)

2- search for a message that arrived _for_ webmas...@aus-city.com (not a
bounce).

3- show the logs for this message from the time it gets into postfix
until it causes an error. the first log line here should contain
"postfix/smtpd" or "postfix/pickup".

if webmas...@aus-city.com is not a valid user, then remove it from your
address lists and from alias (and virtual_aliases). BTW, don't put
$virtual_* in local_recipient_maps.


> [snip]

Re: Having problem with SMTP AUTH

[mouss]

postmas...@klam.ca a écrit :
> This may be a duplicate request, if so sorry but its been a bad day so 
> far!
> I don't seem to be able to get SMTP Auth to work. I have read the Postfix how 
> toes, and several other peoples how toes and nothing I do seems to work.
> 
> If I telnet into may mail server I get the following output:
> 220 mail.mumble.ca ESMTP
> EHLO example.com
> 250-mail.klam.ca
> 250-PIPELINING
> 250-SIZE 32768000
> 250-ETRN
> 250-STARTTLS
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 DSN
> 
> I believe that I should see 250-AUTH/250-AUTH=, but as you can see nothing! 

http://www.postfix.org/postconf.5.html#smtpd_tls_auth_only

you can use openssl client to see the EHLO response after a starttls.

> [snip]

Re: Question about particular Relay configuration

[mouss]

Giovanni Mancuso a écrit :
> Hi to all,
> i have a question about a particular postfix configuration.
> In my test machine, i try to  create a particular enviroment. I have one
> postfix istance that bind in 0.0.0.0:25 and in this postfix istance i
> use a relay_domains and relay_transport to redirect all mail from one
> domain to another postfix instance that bind in localhost:2525.
> For example:
> 
> relay_domains = example.com
> relay_transport = smtp:localhost:2525
> 
> The second istance is use to manage the users and other particular
> condition, and in my configuration would that this istance is separate
> for my first instance.
> 
> Now it works very well, but there is a problem.
> If my second postfix istance (localhost:2525) return for example Error
> 554 or Error 551 after "rcpt to" command, my first postfix instance,
> send the notification for bounce. This isn't very well because i could
> be attacked form spammer.
> 
> My question specifically is: " Can i configure my fisrt istance to proxy
> all SMTP comunication only for one domain??"
> 
> Else, For you is there another mode to configure my enviroment?
> 

you can use reject_unverified_recipient, called from a
check_recipient_access.

but it's better to do recipient validation on the first instance,
without querying the second one.


> Thanks to all and sorry for my bad English ;-)

Re: Question about reject_unauthenticated_sender_login_mismatch

[mouss]

jeff_homeip a écrit :
> --- In post...@yahoogroups.com, Victor Duchovni  wrote:
>[snip]
>>> Am I then correct in concluding that with:
>>>
>>> smtpd_sender_restrictions =
>>> permit_sasl_authenticated,
>>> reject_authenticated_sender_login_mismatch,
>>> reject
>> Observe that the order of the first two elements is not entirely
>> correct.
>>

I hope you didn't miss this.


in your restrictions, reject_authenticated_* is useless, because
authenticated transactions have been permitted by permit_sasl_authenticated.

or did you mean reject_UNauthenticated_*?


> 
> thank you for confirming, and allowing my still-growing knowledge of postfix 
> to confirm 
> your answers. this will help quite a lot!
> 

to sum up:

- if f...@example.com can only be used by user 'foo', then use
reject_sender_login_mismatch.

- if f...@example.com must be authenticated (but you don't care who the
user is), then use reject_unauthenticated_*

- if f...@example.com can be used (without auth) OR (if auth'ed, the user
must be 'foo'), then use reject_authenticated_*.

 (skip if not confident...)
you can implement this on a per sender basis using a check_sender_access
with a map that returns one of the above depending on the sender.

for example:

smtpd_sender_restrictions =
check_sender_access hash:/etc/postfix/access_sender_login

== access_sender_login:
j...@example.comreject_sender_login_mismatch
j...@example.comreject_authenticated_sender_login_mismatch
j...@example.comreject_unauthenticated_sender_login_mismatch
f...@example.comDUNNO
example.com reject_sender_login_mismatch

Re: What do these logs mean?

[mouss]

Ralf Hildebrandt a écrit :
> * Rupert Reid :
>> My postfix log is being inundated.  What does it mean and how can I block 
>> this ip (do I need to)?
> 
> That is not postfix, but ipop3d
> People seem to be logging in and out. Seems normal for a mailserver,
> if you ask me.
> 

too many users with 'a' as first letter, and machine is in the US while
OP is in UK. so either OP munged things, or his server is under attack.

anyway, as you said, not a postfix issue.

Re: backscattering

[mouss]

Noel Jones a écrit :
> Bruno GRANDJEAN wrote:
>>
>> thks for replying to me so quickly, I will add a:
>> reject_rbl_client zen.spamhaus.org
>> in my /etc/postfix/main.cf
>> I already added :
>> reject_rbl_client ips.backscatterer.org
>>
>> how can I reject mail from outside claiming to be from my domain?
> 
> [plain-text only please]
> [please don't top post]
> 
> something like:
> smtpd_sender_restrictions =
>   permit_mynetworks
>   check_sender_access hash:/etc/postfix/not_my_domain
> 
> # not_my_domain
> example.com  REJECT
> 
> This is not without risk.  Some legit mail (mostly notification services
> and some mail lists) will arrive with your domain as sender, but this
> might help as a short-term solution to your problem.
> 
> Don't be tempted to reject your domain in the From: header, that would
> reject a great deal of legit mail - such as your postings to this list.
> 
> ips.backscatter.org won't help too much since this isn't backscatter,
> and is also likely to reject legit mail unless you use it like this:
> smtpd_data_restrictions =
>   permit_mynetworks
>   check_sender_access hash:/etc/postfix/no_backscatter
> 
> # no_backscatter
> <>  reject_rbl_client ips.backscatterer.org
> 
> Which will reject only bounces from them (including legit bounces).
> 

as well as SAV probes such as those of sourceforge lists. so if really
needed, better put this under data restrictions.

Re: Can't stop UNDELIVERED MAIL RETURNED TO SENDER emails

[mouss]

Victor Duchovni a écrit :
> On Mon, Jan 12, 2009 at 06:13:52PM -0500, Wietse Venema wrote:
> 
>> David Cottle:
>>> Content-Description: Undelivered Message
>>> Content-Type: message/rfc822
>>> Content-Transfer-Encoding: 8bit
>>>
>>> Received: from server.engineering.idb (unknown [127.0.0.1])
>>> by server.engineering.idb (Postfix) with ESMTP id C3F5B13C002D
>>> for ; Sun, 11 Jan 2009 23:43:36 + (UTC)
>>> Received-SPF: none (no valid SPF record)
>>> Received: from hosting.mgapi.edu (unknown [82.179.217.2])
>>> by server.engineering.idb (Postfix) with SMTP
>>> for ; Sun, 11 Jan 2009 23:43:35 + (UTC)
>>> Received: from dpkpyv (181.138.153.218)
>>> by hosting.mgapi.edu; Mon, 12 Jan 2009 02:43:44 +0300
> 
> Interestingly, the 181.0.0.0/8 Network is IANA reserved:
> 
> OrgName:Internet Assigned Numbers Authority
> OrgID:  IANA
> Address:4676 Admiralty Way, Suite 330
> City:   Marina del Rey
> StateProv:  CA
> PostalCode: 90292-6695
> Country:US
> 
> NetRange:   181.0.0.0 - 181.255.255.255
> CIDR:   181.0.0.0/8
> NetName:NET181
> NetHandle:  NET-181-0-0-0-0
> Parent:
> NetType:IANA Reserved
> Comment:
> RegDate:1993-05-01
> Updated:2003-04-06
> 
> I wonder how hosting.mgapi.edu managed to receive connections from the
> 181.138.153.218 address.
> 


maybe MGAPI are using these internally...
We've already seen people using the IPs found in "DNS and BIND" (I think
these were HP ranges, right?), so confusing "IANA reserved" with
"reserved for eternity" (thus "safe for private use") is less surprising ;-p

Re: Can't stop UNDELIVERED MAIL RETURNED TO SENDER emails

[mouss]

David Cottle a écrit :
> 
> I found the issue. It's backscatter mail to real recipient addresses. At
> first I was getting non existent as well but stopped those.
> 

Something (a spam filter?) after postfix returns says: "Invalid
destination status"

You MUST not reject mail after it was accepted by postfix, exceptionally
when the message is spam.

> I have to employ header and body checks.
> 
> Okay my question is I have multiple domains not just one like in the
> code example 'porcupine' given.
> 
> How do I code that?
> 

you are the source of backscatter, not the victim. so you can't block
these bounces with a single postfix.

- configure your spam filter to deliver or quarantine or discard... but
not to reject spam.

- reject inbound mail that helo's as "localhost". use check_helo_access
for that. google or read the Bok of Postfix for more infos.

... etc.


> Do I need to string a ton load of domain names or can you use a wildcard
> to match any domain?
> 
> If I could trouble for a snip of code I can apply it and let you know.
> It's a live server and I don't want to experiment code when I am not
> sure how to write it.
> 
> Thanks again!

Re: backscattering

[mouss]

Noel Jones a écrit :
> mouss wrote:
>> Noel Jones a écrit :
>>> smtpd_data_restrictions =
>>>   permit_mynetworks
>>>   check_sender_access hash:/etc/postfix/no_backscatter
>>>
>>> # no_backscatter
>>> <>  reject_rbl_client ips.backscatterer.org
>>>
>>> Which will reject only bounces from them (including legit bounces).
>>>
>>
>> as well as SAV probes such as those of sourceforge lists. so if really
>> needed, better put this under data restrictions.
> 
> The example shows correct usage already, but it's good to point out why
> it's used that way.
> 


I'm getting blind ;-p

Re: backscattering

[mouss]

Bruno GRANDJEAN a écrit :
> Relax Dr Wietse I am using another domain to post to your mailing list

This doesn't matter. it is a general principle. it was easy to guess
that orange.fr isn't your domain.

> Shame on me if I give the domain I have trouble with ;-)

well, there's nothing bad in showing the real domain. Is "rue de Sully"
a large street?

Re: What do these logs mean?

[mouss]

Ralf Hildebrandt a écrit :
> * mouss :
> 
>> too many users with 'a' as first letter, and machine is in the US while
>> OP is in UK. so either OP munged things, or his server is under attack.
>>
>> anyway, as you said, not a postfix issue.
> 
> One could fail2ban the attacker :) 
> 

and if the probes use multiple TCP connections (if the pop server
disconnects after a failure), then he can use rate limiting in his
packet filter if supported ("recent" in iptables, "overload" in pf).

Re: How to restrict ACCESS not RELAY to the SMTP daemon?

[mouss]

Thomas a écrit :
> Thomas wrote:
>> Hello,
>> i try to figure out how to restrict ACCESS to the SMTP daemon.
>>
>> With that, i mean something like the tcpwrapper for SMTP/SMTPS ...
> 
> I found that about a similar solution:
> 
> http://archives.neohapsis.com/archives/postfix/2007-05/0343.html
> 
> There, the following is written:
> 
> 
> 
> There's no real need to run a proxy in-between in this scenario.
> 
> If you really want to have some control over connections before they're
> handled
> to postfix, use "standalone smtp" mode. Like this (inetd.conf):
> 
>  smtp inet stream nowait postfix.postfix accept-conn -deny=/file/deny
> -run=/usr/lib/postfix/smtpd -S ..
> 
> There are two drawbacks:
> 
> 1) this your pre-accepting server has to run smtpd as postfix user.
> Which means either it is running as postfix itself, or (worse) as root.
> 
> 2) this approach requires fork+exec for each (non-blocked) connection.
> 
> And another approach, which eliminates both drawbacks, is to use
> (unfinished)
> passfd "port". Here's the patch for 2.3:
> http://www.corpit.ru/mjt/postfix-2.3.2-passfd.diff
> and for 2.4.0:
> http://www.corpit.ru/mjt/postfix-2.4.0-passfd.diff
> 
> And here's a tiny program - a client side:
> http://www.corpit.ru/mjt/sendfd.c
> 
> It works like this. In master.cf, instead of
>  smtp inet ... smtpd
> use
>  smtpd pass ... smtpd
> 
> This will create /var/spool/postfix/public/smtpd AF_UNIX socket.
> Now, continuing the above example:
> 
>  smtp inet stream nowait nobody.postdrop accept-conn -deny=/file/deny
> -run=sendfd /var/spool/postfix/public/smtpd
> 
> Which will just pass on the connection to postfix.
> 
> I wonder why this `pass' port type support is commented-out... ;)
> ###
> 
> That mail was from 2007 - maybe there is now a better way to handle such
> a situation?
> 
> BTW, i never figured out that inetd/xinetd may be such a bad way to
> start programs!
> At least, programs that do not run as root normally ...
> 

you don't need tcp wrappers. smtpd restrictions provide the same
functionaly (and more), and Wietse gave you an example.

an alternative, that is appropriate for virtual machines, is
firewalling. configure your packet filter (iptables, pf, ipfilter, ...)
to only allow traffic that should be allowed.