Re: Mail to non system account

[Sam Wootton]

2009/11/23 tobi 

> Sam Wootton schrieb:
> > 2009/11/22 Magnus Bäck 
> >
> >
> >> On Sunday, November 22, 2009 at 17:34 CET,
> >>  Sam Wootton  wrote:
> >>
> >>
> >>> I nearly have Postfix working on Opensuse 11.1.
> >>>
> >>> For a non system account user, it works.  For example:
> >>>
> >>> /var/mail/vhosts/samwootton.com/bruno
> >>>
> >>> gets populated with incoming mail.  However, when i try to do the same
> >>> for a system account user, it never reaches that message store.
> >>>
> >> Is it the same domain? Show logs.
> >>
> >>
> >>> It was going in to /var/spool/mail/useraccount but i commented out:
> >>>
> >>> mail_spool_directory
> >>>
> >>> in mail.cf.
> >>>
> >> Doing so was most likely useless.
> >>
> >>
> >>> Here are the rest of my settings:
> >>>
> >> Next time, post "postconf -n" output instead.
> >>
> >>
> >>> *inet_interfaces = $myhostname, localhost*
> >>>
>  *mydestination = $myhostname*
>  *virtual_mailbox_maps = hash:/etc/postfix/vmailmaps*
>  *local_recipient_maps = $virtual_mailbox_maps*
>  *local_transport = virtual*
>  *mynetworks_style = host*
>  *virtual_mailbox_domains = samwootton.com*
>  *virtual_mailbox_base = /var/mail/vhosts*
> 
> >> The cause of your problems may very well be that you're messing with
> >> local_recipient_maps and local_transport in this manner. There are very
> >> few occasions where such a configuration makes any sense, and this is
> >> most likely not one of them. You need to read up on address classes.
> >>
> >> List local domains in mydestination.
> >> List virtual mailbox domains in virtual_mailbox_domains.
> >> List virtual alias domains in virtual_alias_domains.
> >> List relay domains in relay_domains.
> >>
> >> Unless you have a single domain that contains users in two or more of
> >> these address classes, getting the above right is all it takes.
> >>
> >>
> >>> I have commented out 'mailbox_transport' completely.
> >>>
> >> That doesn't make any difference as you're not using local(8) at all.
> >>
> >>
> >>> Here is my vmailmaps:
> >>>
> >>> s...@samwootton.com samwootton.com/sam
> >>>
> >>> Could anyone help me fix this problem?  Just to clarify, i can get non
> >>> system account mail being delivered, but not a system account.
> >>>
> >>> I'm guessing it is still using the default delivery agent for that on
> >>> system account?  A delivery agent that looks inside /etc/passwd and
> >>> /etc/aliases files?
> >>>
> >> Until you show us logs we can only guess. Throw in full "postconf -n"
> >> output while you're at it.
> >>
> >> --
> >> Magnus Bäck
> >> mag...@dsek.lth.se
> >>
> >>
> >
> > Hi,
> >
> > Thank you for your quick response - apologies for my slow response.
> >
> > I have a single domain that has 2 categories of user (a unix holding
> account
> > user, and a non-unix account user).
> >
> > I didn't think my set-up was that odd.  After all, in main.cf, it
> states:
> >
> > "You need to update the local_recipient_maps setting if:
> >
> >>  - You define $mydestination domain recipients in files other than
> >>/etc/passwd, /etc/aliases, or the $virtual_alias_maps files.
> >>For example, you define $mydestination domain recipients in
> >>the $virtual_mailbox_maps files."
> >>
> >>
> >
> > So i assumed that:
> >
> > *local_recipient_maps = $virtual_mailbox_maps*
> >
> > was ok.  About address classes.  I don't think i need to alter the
> > transport.db, and therefore am unsure about where to define address
> classes
> > and what the vlaue should be.
> >
> > Here is my postconf output:
> >
> > biff = no
> > canonical_maps = hash:/etc/postfix/canonical
> > command_directory = /usr/sbin
> > config_directory = /etc/postfix
> > daemon_directory = /usr/lib/postfix
> > data_directory = /var/lib/postfix
> > debug_peer_level = 2
> > defer_transports =
> > delay_warning_time = 1h
> > disable_dns_lookups = no
> > disable_mime_output_conversion = no
> > html_directory = /usr/share/doc/packages/postfix-doc/html
> > inet_interfaces = $myhostname, localhost
> > inet_protocols = all
> > local_recipient_maps = $virtual_mailbox_maps
> > local_transport = virtual
> > mail_owner = postfix
> > mailbox_command =
> > mailbox_size_limit = 0
> > mailbox_transport =
> > mailq_path = /usr/bin/mailq
> > manpage_directory = /usr/share/man
> > masquerade_classes = envelope_sender, header_sender, header_recipient
> > masquerade_domains =
> > masquerade_exceptions = root
> > message_size_limit = 1024
> > message_strip_characters = \0
> > mydestination = $myhostname
> > myhostname = samwootton.com
> > mynetworks_style = host
> > newaliases_path = /usr/bin/newaliases
> > queue_directory = /var/spool/postfix
> > readme_directory = /usr/share/doc/packages/postfix-doc/README_FILES
> > relay_domains = $mydestination
> > relayhost =
> > relocated_maps = hash:/etc/postfix/relocated
> > sample_directory = /usr/share/doc/packages/postfix-doc/samples
> > sender_canonical_maps = hash:/etc/postfix/sender_canonical
> > sendmail_path =

RE: Milter's not working on Postfix 2.6.5

[Sharma, Ashish]

Solved the problem using setting:

milter_protocol = 2

as mentioned in:

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

in 'main.cf'

--Ashish Sharma

From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
On Behalf Of Sharma, Ashish
Sent: Tuesday, November 24, 2009 12:36 PM
To: postfix users list
Subject: Milter's not working on Postfix 2.6.5

Hello,

I have installed a Postfix (version 2.6.5 ) mail receiving server.

I use the DKIM and SenderID+SPF milter referred from here:

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

My 'main.cf' settings for above mentioned milters is as:

#Milter support for smtpd mail
smtpd_milters =
  inet:localhost:10026,
  inet:localhost:10027

# Milters for non-SMTP mail.
non_smtpd_milters =
  inet:localhost:10026,
  inet:localhost:10027


milter_default_action = tempfail




But I receive the following mailog messages whenever a mail is sent on this 
postfix mail server and the mail is rejected:

Nov 24 01:52:16 ip-10-244-19-127 postfix/smtpd[3953]: warning: milter 
inet:localhost:10026: can't read SMFIC_DATA reply packet header: Success
Nov 24 01:52:16 ip-10-244-19-127 postfix/smtpd[3953]: warning: milter 
inet:localhost:10027: can't read SMFIC_DATA reply packet header: Success


As a result milter results are not appended into the mail headers.

But the same milters work without a problem on Postfix (version 2.3.3) and 
milter headers are appended in the e-mail received.

Please help so that I can use the above mentioned milters for Postfix (version 
2.6.5).

With regards
Ashish Sharma

Re: Mail to non system account

[Ansgar Wiechers]

On 2009-11-24 Sam Wootton wrote:
> 2009/11/23 tobi 
>> You should not set your domainname in mydestination if you plan to
>> receive emails for virtual users on that domain.
> 
> Thanks for that.  Is there any reason why?  Seems logical to me.  It
> *is* my destination, why does the type of account make a difference?
> I have O'Reilly postfix book - and i didnt see any mention of that.

See: http://www.postfix.org/VIRTUAL_README.html

Particularly: http://www.postfix.org/ADDRESS_CLASS_README.html

Regards
Ansgar Wiechers
-- 
"Abstractions save us time working, but they don't save us time learning."
--Joel Spolsky

Re: Same address delivering to multiple mailboxes

[Sean Holdsworth]

On 24 Nov 2009, at 00:03, mouss wrote:

> Sean Holdsworth a écrit :
>> On 21 Nov 2009, at 10:58, mouss wrote:
>> 
>>> Sean Holdsworth a écrit :
 [snip]
 
 If I allow that address rewite then mail for p...@domain or p...@domain 
 will
 get
 sent on to the MTA with an envelope recipient address of catch...@domain
 rather than their original recipient address.
 
 I've tried various work arounds without success. The one that seems most
 natural, but which DOES NOT WORK, is the following:
 
 virtual_aliases:
 p...@domain @domain p...@domain
 p...@domain @domain p...@domain
 
 This results in mail for either address only arriving in their own mailbox.
 
 Is there another approach to this that I'm missing?
 
>>> you want smtp_generic_maps.
>> 
>> Sorry but having reread the address rewrite documentation several times, I 
>> don't understand how smtp_generic maps would help in this case. To restate 
>> the problem, I'm trying to figure out a way of doing the following 
>> deliveries:
>> 
> 
> 
> use virtual aliases like this:
> 
> j...@example.com f...@example.net, bar+...@example.com
> 
> 
> where "bar+joe" keeps the "joe" information.
> 
> at the time of delivery, rewrite
> bar+...@example.com j...@example.com
> 
> 
> if this doesn't do what you want, please explain your problem without
> citing any postfix methods/solutions/parameters. in short, explain your
> problem in "the problem domain", not in the solution domain.
> 

Thanks for the additional suggestion but I'm still not able to do what I'm 
attempting without an address rewrite causing problems, so I'll do as you 
suggest and try and explain the problem without trying to solve it.

I have two mail servers. The first mail server acts as MX for a domain. That 
domain has a catchall delivery rule and a few specific addresses. Mail that 
doesn't match a specific address is  forwarded on to the second mail server 
(via SMTP). Mail to any of the specific addresses is delivered into a local, 
per address mailbox on the first mail server, but a copy is also sent on to the 
second  mail server so that this second mail server receives a copy of any mail 
sent to an address in the domain. The second mail server must see mail being 
delivered to the same address to which it was sent on the first mail server. Is 
this possible without a custom delivery agent, which is how I'm currently 
solving this problem?

Re: Milter's not working on Postfix 2.6.5

[Wietse Venema]

Sharma, Ashish:
> Solved the problem using setting:
> 
> milter_protocol = 2
> 
> as mentioned in:
> 
> http://www.postfix.org/MILTER_README.html
> 
> in 'main.cf'

When in doubt, read the release notes file.

  [Incompat 20090428] The default milter_protocol setting is increased
  from 2 to 6; this enables all available features up to and including
  Sendmail 8.14.0.  The new milter_protocol setting may break
  compatibility with older Milter libraries or applications, and may
  cause Postfix to log warning messages such as:

warning: milter inet:host:port: can't read packet header: Unknown error : 0

warning: milter inet:host:port: can't read packet header: Success

warning: milter inet:host:port: can't read SMFIC_DATA reply
packet header: No such file or directory

  To restore compatibility, specify "milter_protocol = 2" in main.cf.

Wietse

Bounce a particular recipient address with specified reject message

[techlist06]

Greetings:

I have what I expect is a simple question for you guys.  Thanks to Ralphs
book and the help here I have a many-year stable postfix configuration, love
it, don't mess with it.

I have a very small hobby-based mailing list I maintain manually in Outlook.
Although all maillist messages I send out include a footer asking the
recipients to not reply to that maillist messages, the users will reply to
the maillist messages occasionally and I would prefer they only reply to my
other addresses.  I can change the reply to address in Outlook to an invalid
one, and it will reject it back to the sender with "not in virtual user
table" but I don't wan that bounce message for this particular case.

Instead, I would like to setup postfix so it has a more friendly reject for
mail sent to (via replys to my messages) "maill...@mydomain.com" with a
particular reject message that instructs the user on what address(es) to use
to better contact me.  Something similar to :

550 reject The email address maill...@mydomain.com does not accept inbound
mail.  Please use one of these addresses for contacting us: maillist
unsubsubscribe: rem...@mydomain.com, support issues: supp...@mydomain.com,
other i...@mydomain.com, etc.

I thought maybe adding the address maill...@mydomain.com to the
recipient_checks.pcre?  But I don't know how to write the re if that's the
right place to do this.

Can someone help and tell me where is the best place to set this up?

Thanks as always,
Scott


postconf -n:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
disable_vrfy_command = yes
html_directory = no
inet_interfaces = $myhostname, localhost
local_recipient_maps = hash:/etc/postfix/local_recipient
mail_owner = postfix
mail_spool_directory = /var/spool/mail
mailbox_size_limit = 483886080
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 10485760
mydestination = $myhostname,  localhost.$mydomain,  localhost,  $mydomain
mydomain = companypostoffice.com
myhostname = tn1.companypostoffice.com
mynetworks = localhost,$localdomain, xx.xx.xx.xx/32, xx.xx.xx.xx/32
myorigin = $myhostname
newaliases_path = /usr/bin/newaliases.postfix
parent_domain_matches_subdomains = smtpd_access_maps
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.2.10/README_FILES
recipient_bcc_maps = hash:/etc/postfix/recipient_bcc
relay_domains = differentdomain.com
relay_recipient_maps = hash:/etc/postfix/relay_recipients
sample_directory = /usr/share/doc/postfix-2.2.10/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtpd_data_restrictions = reject_unauth_pipelining,  permit
smtpd_helo_required = yes
smtpd_recipient_limit = 1500
smtpd_recipient_restrictions = reject_invalid_hostname,
reject_non_fqdn_hostname,  reject_non_fqdn_sender,
reject_non_fqdn_recipient,  permit_mynetworks,  reject_unauth_destination,
check_recipient_mx_access hash:/etc/postfix/mx_access,
check_sender_mx_access hash:/etc/postfix/mx_access,
reject_unknown_sender_domain,  check_recipient_access
pcre:/etc/postfix/recipient_checks.pcre,  check_helo_access
hash:/etc/postfix/helo_checks,  check_sender_access
hash:/etc/postfix/sender_checks,  check_client_access
hash:/etc/postfix/client_checks,  check_client_access
pcre:/etc/postfix/client_checks.pcre,  reject_rbl_client list.dsbl.org,
reject_rbl_client zen.spamhaus.org,  reject_rbl_client dnsbl.sorbs.net,
reject_rbl_client psbl.surriel.com,  reject_rbl_client bl.spamcop.net,
check_policy_service unix:postgrey/socket,  permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_security_options = noanonymous
smtpd_tls_CAfile = /etc/postfix/certs/cacert.pem
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/postfix/certs/postfix_public_cert.pem
smtpd_tls_key_file = /etc/postfix/certs/postfix_private_key.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
soft_bounce = no
tls_random_source = dev:/dev/urandom
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 550
virtual_alias_domains = hash:/etc/postfix/virtual_domains
virtual_alias_maps = hash:/etc/postfix/virtual_users

Re: backscatter

[K bharathan]

On Tue, Nov 24, 2009 at 12:14 AM, Michael Orlitzky wrote:

> Noel Jones wrote:
>
>> On 11/23/2009 3:25 PM, K bharathan wrote:
>>
>>>
>>>
>>> On Mon, Nov 23, 2009 at 8:02 PM, /dev/rob0 >> > wrote:
>>>
>>>On Mon, Nov 23, 2009 at 03:51:33PM +0100, Robert Schetterer wrote:
>>> > > the server got a list of  domains (those domains mail servers
>>>use this
>>> > > server as relayhost)to relay out and does only smtp out; what
>>>could be
>>> > > wrong in the above config; appreciate ur assistance upon this
>>> >
>>> > thats the reason, guess your relay clients get lots of i.e
>>> spam/virus
>>> > mail,perhaps they bounce after allready got the mail for
>>> nonexistent
>>> > domains/mailaccounts etc ( do they have catch alls, buggy virus
>>>
>>>Indeed, if you relay backscatter, you can expect to be listed as a
>>>backscatterer! That's pretty simple. Don't do it. Get the clients to
>>>fix their problems. In the meantime a check_sender_access lookup
>>>will stop the abuse:
>>><>HOLD
>>>and you can check mailq(1) periodically; release any that look like
>>>legitimate bounces, and deal with the others as may be appropriate.
>>>"man postsuper" for information.
>>>--
>>>Offlist mail to this address is discarded unless
>>>"/dev/rob0" or "not-spam" is in Subject: header
>>>
>>> i tried putting <>   HOLD in allowed domains (mydomain map) but it
>>> doesn't work and result in 'relay access denied'; how can i put this and
>>> check ?
>>>
>>>
>> That needs to go in a check_sender_access map.  Something like:
>> # main.cf
>> smtpd_sender_restrictions =
>>  check_sender_access hash:/etc/postfix/hold_bounce
>>
>> # /etc/postfix/hold_bounce
>> <> HOLD
>>
>> I expect there will be thousands of these.  You don't (usually) get on a
>> backscatter blacklist for sending just a few bounces.
>>
>> The real solution is to get the incoming gateways to stop accepting stuff
>> that will be bounced.  If the incoming gateways are not under your control,
>> stop accepting mail from them.
>>
>>  -- Noel Jones
>>
>
>
> That's where his 'mydomains' maps are, but I'm still very confused.
>
> > smtpd_sender_restrictions =
>
> >   check_sender_access hash:/etc/postfix/mydomains
> >   check_recipient_access hash:/etc/postfix/allowed_forwards
> >   reject_unauth_destination
>
> Did you include both,
>
>  example.com OK
>  <>  HOLD
>
> in the access map? The first is necessary to avoid that
> reject_unauth_destination.
>

yes i put this into the map and i'm getting the log for <> like this:

Nov 24 17:59:32 smtp postfix/smtpd[22914]: NOQUEUE: hold: RCPT from
example.com[192.168.20.1]: <>: Sender address trigger
s HOLD action; from=<> to= proto=ESMTP helo=<
example.com>
Nov 24 17:59:32 smtp postfix/smtpd[22914]: NOQUEUE: reject: RCPT from
example.com[192.168.20.1]: 554 5.7.1 : Relay access denied; from=<> to=
proto=ESMTP helo=

it's not queuing in HOLD; how can see the hold queue
i tried postqueue -p but no avail

-bharathan

Sender ID Milter

[Roman Gelfand]

Please, correct where I am wrong.

Looking at  man sid-filter, with -d flag, you can supply domains to be
ignored by the filter.

I am assuming by domain, it means to the right of @.

Does sid-filter ignore entries in the header where reference to the
domain is mentioned or the whole email is not filtered by sid-filter?

When reject flag is not specified, the default is accept.  If it means
accept all email, what is the purpose of running the sid-filter?

Thanks in advance

Don't filter the users

[Jordi Espasa Clofent]

Hi all,

I've a Postfix  working with Perl-based filter. All works fine, but I 
don't want filter the legitimate users (who are authenticated using 
SASL) when they want to do massive mailing using their e-mail client 
(ThunderBird, Outlook... and so on).


I can do it easily hacking the actual Perl filers code, but I wonder if 
it is possible at Postfix level. Imagine that:


* if the smtpd connection is not SASL auth match, pass through the filter
* if the smtpd connection _is_ SASL auth match (so, I consider it a 
legitimate user connection), not pass through the filter


¿Can I do it? ¿How?

--
I must not fear. Fear is the mind-killer. Fear is the little-death that 
brings total obliteration. I will face my fear. I will permit it to pass 
over me and through me. And when it has gone past I will turn the inner 
eye to see its path. Where the fear has gone there will be nothing. Only 
I will remain.


Bene Gesserit Litany Against Fear.

Re: backscatter

[/dev/rob0]

On Tue, Nov 24, 2009 at 06:10:53PM +0200, K bharathan wrote:
> On Tue, Nov 24, 2009 at 12:14 AM, Michael Orlitzky
> wrote:
> > Noel Jones wrote:
> >> On 11/23/2009 3:25 PM, K bharathan wrote:
> >>> On Mon, Nov 23, 2009 at 8:02 PM, /dev/rob0  >>> > wrote:

> >>>Indeed, if you relay backscatter, you can expect to be listed as a
> >>>backscatterer! That's pretty simple. Don't do it. Get the clients to
> >>>fix their problems. In the meantime a check_sender_access lookup
> >>>will stop the abuse:
> >>><>HOLD
> >>>and you can check mailq(1) periodically; release any that look like
> >>>legitimate bounces, and deal with the others as may be appropriate.
> >>>"man postsuper" for information.

> >>> i tried putting <>   HOLD in allowed domains (mydomain map) but it
> >>> doesn't work and result in 'relay access denied'; how can i put this and
> >>> check ?
> >>>
> >>>
> >> That needs to go in a check_sender_access map.  Something like:
> >> # main.cf
> >> smtpd_sender_restrictions =
> >>  check_sender_access hash:/etc/postfix/hold_bounce
> >>
> >> # /etc/postfix/hold_bounce
> >> <> HOLD
> >>
> >> I expect there will be thousands of these.  You don't (usually) get on a
> >> backscatter blacklist for sending just a few bounces.
> >>
> >> The real solution is to get the incoming gateways to stop accepting stuff
> >> that will be bounced.  If the incoming gateways are not under your control,
> >> stop accepting mail from them.

> > That's where his 'mydomains' maps are, but I'm still very confused.
> >
> > > smtpd_sender_restrictions =
> >
> > >   check_sender_access hash:/etc/postfix/mydomains
> > >   check_recipient_access hash:/etc/postfix/allowed_forwards
> > >   reject_unauth_destination
> >
> > Did you include both,
> >
> >  example.com OK
> >  <>  HOLD
> >
> > in the access map? The first is necessary to avoid that
> > reject_unauth_destination.

This part is not true, and check_sender_access should never be used
for whitelisting of any kind anyway, unless you have taken steps to
ensure the address is valid (enforced AUTH, sender in a domain you
control.)

Note, if sender is "<>", a sender lookup of "example.com" wouldn't
match.

What *is* true is that the reject_unauth_destination is blocking
this. It could be bypassed, preceded by "permit_sasl_authenticated,
permit_mynetworks", or just as well, it could be omitted altogether.
The reject_unauth_destination that counts is already included in
smtpd_recipient_restrictions.

Offer void where taxed or prohibited by law, or if some other
restriction has been added without our knowledge.

> yes i put this into the map and i'm getting the log for <> like this:
> 
> Nov 24 17:59:32 smtp postfix/smtpd[22914]: NOQUEUE: hold: RCPT from
> example.com[192.168.20.1]: <>: Sender address trigger
> s HOLD action; from=<> to= proto=ESMTP helo=<
> example.com>
> Nov 24 17:59:32 smtp postfix/smtpd[22914]: NOQUEUE: reject: RCPT from
> example.com[192.168.20.1]: 554 5.7.1  vanssa.com>: Relay access denied; from=<> to=
> proto=ESMTP helo=
> 
> it's not queuing in HOLD; how can see the hold queue
> i tried postqueue -p but no avail

NOQUEUE means what it says: it is not assigned a queue ID. This one
being a "reject:" means there will not be a queue ID. It has gone
back to the backscatterer, possibly handled as a double bounce at
that MTA (example.com[192.168.20.1]).
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: Sender ID Milter

[Sahil Tandon]

On Nov 24, 2009, at 12:02 PM, Roman Gelfand  wrote:


Please, correct where I am wrong.

Looking at  man sid-filter, with -d flag, you can supply domains to be
ignored by the filter.

I am assuming by domain, it means to the right of @.

Does sid-filter ignore entries in the header where reference to the
domain is mentioned or the whole email is not filtered by sid-filter?

When reject flag is not specified, the default is accept.  If it means
accept all email, what is the purpose of running the sid-filter?


Not a Postfix question.

Re: Don't filter the users\

[Wietse Venema]

Jordi Espasa Clofent:
> Hi all,
> 
> I've a Postfix  working with Perl-based filter. All works fine, but I 
> don't want filter the legitimate users (who are authenticated using 
> SASL) when they want to do massive mailing using their e-mail client 
> (ThunderBird, Outlook... and so on).

That is easy.

Have your users connect to the submission port, and let everyone
else connnect to the smtp port. Then, specify "=o content_filter=whatever"
for the smtp port and not for the submission port.

If you are taking in all mail on port 25 then you are making mail
handling more complicated than it needs to be.

Wietse

Re: Don't filter the users\

[Jordi Espasa Clofent]

That is easy.

Have your users connect to the submission port, and let everyone
else connnect to the smtp port. Then, specify "=o content_filter=whatever"
for the smtp port and not for the submission port.


Yes Wietse, I've considered this simple and clean option,  but we're a 
hosting company and the costumers are to lazy to understand and accept 
an approach like this.



If you are taking in all mail on port 25 then you are making mail
handling more complicated than it needs to be.


I agree... but ¿is there no more alternatives?

Maybe if I want all mail on port 25, I have to hack the Perl filter code 
and working on this level, not in Postfix level.


--
I must not fear. Fear is the mind-killer. Fear is the little-death that 
brings total obliteration. I will face my fear. I will permit it to pass 
over me and through me. And when it has gone past I will turn the inner 
eye to see its path. Where the fear has gone there will be nothing. Only 
I will remain.


Bene Gesserit Litany Against Fear.

Relay + selective dual authenticity check

[Kārlis Repsons]

Hi to all the list members!

I've been thinkering around postfix for some not very long time, but still 
haven't found an answer to this problem: 

1) let there be host "server" and host "client";
2) server must be able to receive any incoming mail (as usually for its own 
domain);
3) server only sends relayed mail to not-on-server address if its from 
authenticated client (with the expected certificate);
4) when user U on client sends any mail, it must be first relayed to server, 
which remains responsible for further delivery - it can be to Internet (use 
DNS) or to LAN (don't use DNS, use /etc/hosts!);
5) before client actually sends anything to server, it has to check servers 
certificate and make sure, its the same as expected;
6) before accepting message, server checks clients authenticity in similar 
way, if user U is the source.

Well, is that too complicated to tell briefly in here? Can it be done with 
postfix without too much of postfix-fu or C? Or I want too much?


signature.asc
Description: This is a digitally signed message part.

Re: Don't filter the users\

[Sahil Tandon]

On Nov 24, 2009, at 12:39 PM, Jordi Espasa Clofent > wrote:



That is easy.
Have your users connect to the submission port, and let everyone
else connnect to the smtp port. Then, specify "=o  
content_filter=whatever"

for the smtp port and not for the submission port.


Yes Wietse, I've considered this simple and clean option,  but we're  
a hosting company and the costumers are to lazy to understand and  
accept an approach like this.



If you are taking in all mail on port 25 then you are making mail
handling more complicated than it needs to be.


I agree... but ¿is there no more alternatives?


An untested idea: try not specfying a content_filter anywhere in  
main.cf or master.cf.  Then place a policy service (like postfwd) that  
checks whether clients connecting on port 25 authenticate (determined  
by whether Postfix passes a non-empty sasl_* attribute to the policy  
service).  Make the policy service respond with a suitable FILTER  
action only for clients that do NOT authenticate.

Re: Relay + selective dual authenticity check

[Victor Duchovni]

On Tue, Nov 24, 2009 at 05:53:50PM +, K??rlis Repsons wrote:

> Hi to all the list members!
> 
> I've been thinkering around postfix for some not very long time, but still 
> haven't found an answer to this problem: 
> 
> 1) let there be host "server" and host "client";
> 2) server must be able to receive any incoming mail (as usually for its own 
> domain);

Default Postfix behaviour.

> 3) server only sends relayed mail to not-on-server address if its from 
> authenticated client (with the expected certificate);

mynetworks = 127.0.0.1
relay_domains =
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination
... UCE checks ...

> 4) when user U on client sends any mail, it must be first relayed to server, 
> which remains responsible for further delivery - it can be to Internet (use 
> DNS) or to LAN (don't use DNS, use /etc/hosts!);

If you want Postfix to deliver email to non-DNS nexthops:

smtp_host_lookup = dns, native

> 5) before client actually sends anything to server, it has to check servers 
> certificate and make sure, its the same as expected;

This is an MUA, not a Postfix issue. 

> 6) before accepting message, server checks clients authenticity in similar 
> way, if user U is the source.

You are trying to impose an end-to-end security model (end-user entitlements
to send email, ...) onto a hop-by-hop infrastructure (Internet email).

Generally, you can't impose a naive user authentication policy onto a
hop-by-hop store-and-forward infrastructure, because the party forwarding
a message is often not the original user who injected into the mail system.
This is not a "Postfix" limitation, is it a fundamental part of Internet
email architecure.

If your MTA is in fact an "MSA" and only accepts mail (typically on
port 587), *directly* from an MUA operated by the end-user, with no
local submission by authorized users via the command-line on authorized
null client systems that forward to your server, or other indirect
submission mechanisms, ... Then and only then, can you impose strong
user authentication, unless you want to force S/MIME onto all the MUAs,
and check end-to-end message signatures, ...

Postfix does support obtaining client certificates, but has no support
for directly associating these with a particular sender. We don't have
an analogue of reject_sender_login_mismatch (sender <-> SASL identity
mapping) for TLS client certs. Such a mapping can be implemented in a
"policy service" or milter.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: Postfix DKIM

[Michael Saldivar]

On Wed, Sep 9, 2009 at 8:08 PM, KLaM Postmaster  wrote:

> I found the easiest way by far, was to use the DKIM feature of amavisd-new
>  simple to setup
> and work like a charm.
>
> JLA
>


I couldn't tell from the docs:
http://www.ijs.si/software/amavisd/amavisd-new-docs.html#dkim

Does amavisd-new insert DomainKeys signatures also? or just DKIM?

 I'm impressed at how easy it looks to implement and configure for multiple
domains, but we need both DK and DKIM.

-- 
Mike Saldivar
Direct Financial Solutions
Information Systems Manager
Desk: 435-774-8252
Cell: 435-881-3778

Re: Relay + selective dual authenticity check

[Kārlis Repsons]

On Tuesday 24 November 2009 18:39:34 Victor Duchovni wrote:
> > 3) server only sends relayed mail to not-on-server address if its from 
> > authenticated client (with the expected certificate);
> 
> mynetworks = 127.0.0.1
> relay_domains =
> smtpd_recipient_restrictions =
> permit_mynetworks,
> permit_sasl_authenticated,
> reject_unauth_destination
> ... UCE checks ...

Thanks Viktor!
No TLS authentication can do that? I was reading about SASL, but still had no 
clear idea why/where its necessary? Perhaps you know some how-to or search 
keywords for this case (point 3), as there appear to be more to ask?

> > 6) before accepting message, server checks clients authenticity in
> > similar  way, if user U is the source.
> 
> You are trying to impose an end-to-end security model (end-user
>  entitlements to send email, ...) onto a hop-by-hop infrastructure
>  (Internet email).

Simply put, I just wouldn't like anyone ever to send out mail as myself and 
get archived automatically on server as if it was actually me, who sends - put 
on such a barrier was my intention. Well, maybe a bit silly. But doesn't it 
allow end-to-end authentication as a special case? Anyway, this is the part 
"too much", right?

> Generally, you can't impose a naive user authentication policy onto a
> hop-by-hop store-and-forward infrastructure, because the party forwarding
> a message is often not the original user who injected into the mail system.
> This is not a "Postfix" limitation, is it a fundamental part of Internet
> email architecure.
> 
> If your MTA is in fact an "MSA" and only accepts mail (typically on
> port 587), directly from an MUA operated by the end-user, with no
> local submission by authorized users via the command-line on authorized
> null client systems that forward to your server, or other indirect
> submission mechanisms, ... Then and only then, can you impose strong
> user authentication, unless you want to force S/MIME onto all the MUAs,
> and check end-to-end message signatures, ...
> 
> Postfix does support obtaining client certificates, but has no support
> for directly associating these with a particular sender. We don't have
> an analogue of reject_sender_login_mismatch (sender <-> SASL identity
> mapping) for TLS client certs. Such a mapping can be implemented in a
> "policy service" or milter.
> 
> -- 
> Viktor.


signature.asc
Description: This is a digitally signed message part.

Re: Don't filter the users\

[LuKreme]

On 24-Nov-2009, at 10:39, Jordi Espasa Clofent wrote:

>> That is easy.
>> Have your users connect to the submission port
> 
> Yes Wietse, I've considered this simple and clean option,  but we're a 
> hosting company and the costumers are to lazy to understand and accept an 
> approach like this.

Force them by making 587 the ONLY way to send mail. Tell them it's for security 
reasons and make sure you enforce it.

-- 
What if there were no hypothetical questions?

Re: Don't filter the users\

[Sahil Tandon]

On Nov 24, 2009, at 3:07 PM, LuKreme  wrote:



On 24-Nov-2009, at 10:39, Jordi Espasa Clofent wrote:


That is easy.
Have your users connect to the submission port


Yes Wietse, I've considered this simple and clean option,  but  
we're a hosting company and the costumers are to lazy to understand  
and accept an approach like this.


Force them by making 587 the ONLY way to send mail. Tell them it's  
for security reasons and make sure you enforce it.


That's all fine and well for small sites, but hardly a solution for  
larger environments where such draconian measures are impractical.  A  
more reasonable solution is for the OP to push users toward submission  
via 587, and in the (very long) meantime, find other ways to bifurcate  
SASL vs. non-SASL traffic on port 25.

RE: About SMTP Auth with Mysql

[Vahriç Muhtaryan]

Any postfix guy have a knowledge about this issue
Really I would like to solve this and debug
Actually smtp -v do not show the problem also verbose mode to for sasl
Any idea ?

-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Vahriç Muhtaryan
Sent: Sunday, November 22, 2009 11:21 PM
To: 'Patrick Ben Koetter'; postfix-users@postfix.org
Subject: RE: About SMTP Auth with Mysql

I hope that until find the right mailbox and pass it should query each
setted mysql server but not !
For to be sure I'm sending different mailbox name and password and wait
postfix make query step by step but not.
I told you before with different syntax postfix do differnt actions
I don't know this is really postfix problem our cyrus problem but I couldn'T
find any solution
When you check cyrus docs my sytax is ok but its not working
İts drive me crazy 

Regards
Vahric

-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Patrick Ben Koetter
Sent: Sunday, November 22, 2009 4:44 PM
To: postfix-users@postfix.org
Subject: Re: About SMTP Auth with Mysql

* Vahriç Muhtaryan :
> Hi,
> 
> (212.58.4.184,212.58.4.247) not worked
> (212.58.4.184:3306,212.58.4.247:3306)query arrive to 4.247 but not to 184
> 212.58.4.184:3306,212.58.4.247:3306 query arrive to 4.184 but not to 247
> 212.58.4.184:3306 212.58.4.247:3306 query arrive to 4.184 but not to 247
> sql_hostnames: 212.58.4.184 212.58.4.247 query arrive to 4.184 but not to
> 247

How did you test?

Just in case you think it should query both servers at the same time: No,
it's
not supposed to do that.

If the 1st server in the list is inaccessible, it should try the second.

Have you tested that?

p...@rick

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

saslfinger (debugging SMTP AUTH):

Re: Don't filter the users\

[Michael Saldivar]

On Tue, Nov 24, 2009 at 1:25 PM, Sahil Tandon  wrote:

> On Nov 24, 2009, at 3:07 PM, LuKreme  wrote:
>
>
>> On 24-Nov-2009, at 10:39, Jordi Espasa Clofent wrote:
>>
>>  That is easy.
 Have your users connect to the submission port

>>>
>>> Yes Wietse, I've considered this simple and clean option,  but we're a
>>> hosting company and the costumers are to lazy to understand and accept an
>>> approach like this.
>>>
>>
>> Force them by making 587 the ONLY way to send mail. Tell them it's for
>> security reasons and make sure you enforce it.
>>
>
> That's all fine and well for small sites, but hardly a solution for larger
> environments where such draconian measures are impractical.  A more
> reasonable solution is for the OP to push users toward submission via 587,
> and in the (very long) meantime, find other ways to bifurcate SASL vs.
> non-SASL traffic on port 25.
>

Small sites like Google, where they force their customers to use specific
ports for e-mail submission?

http://mail.google.com/support/bin/answer.py?answer=77689

What's good for the Google is good for the Gander, eh?  You could even copy
Google's help docs when writing your own.

-Mike

Re: Don't filter the users

[Wietse Venema]

Jordi Espasa Clofent:
> > That is easy.
> > 
> > Have your users connect to the submission port, and let everyone
> > else connnect to the smtp port. Then, specify "=o content_filter=whatever"
> > for the smtp port and not for the submission port.
> 
> Yes Wietse, I've considered this simple and clean option,  but we're a 
> hosting company and the costumers are to lazy to understand and accept 
> an approach like this.

You can tell the users that the "submission" port gets a better
level of service than port 25, because they share that port with
spammers.

As you pointed out in your original email, they would be subject
to less filtering, and therefore there would be less delay, less
false positives, and so on.

Wietse

Re: Don't filter the users\

[Sahil Tandon]

On Nov 24, 2009, at 3:48 PM, Michael Saldivar > wrote:


On Tue, Nov 24, 2009 at 1:25 PM, Sahil Tandon   
wrote:

On Nov 24, 2009, at 3:07 PM, LuKreme  wrote:


On 24-Nov-2009, at 10:39, Jordi Espasa Clofent wrote:

That is easy.
Have your users connect to the submission port

Yes Wietse, I've considered this simple and clean option,  but we're  
a hosting company and the costumers are to lazy to understand and  
accept an approach like this.


Force them by making 587 the ONLY way to send mail. Tell them it's  
for security reasons and make sure you enforce it.


That's all fine and well for small sites, but hardly a solution for  
larger environments where such draconian measures are impractical.   
A more reasonable solution is for the OP to push users toward  
submission via 587, and in the (very long) meantime, find other ways  
to bifurcate SASL vs. non-SASL traffic on port 25.


Small sites like Google, where they force their customers to use  
specific ports for e-mail submission?


Small sites like Google?  Sarcasm is adorable but rarely helps make  
your point.



http://mail.google.com/support/bin/answer.py?answer=77689

What's good for the Google is good for the Gander, eh?


If only it were so.  Think company that decides caters to thousands  
(insert a larger number of your liking here to avoid another sarcastic  
response that misses the point) of users on port 25 and can't one day  
just STOP accepting all mail on that port, no matter how useful and  
nicely worded the REJECT is that directs them to 587.


The OP has already stated he understands the merits of using the  
submission port but needs another solution given his REAL WORLD  
constraints.


Let me be clear: I'm totally on board with using a separate submission  
port for trusted users, but that is not always immediately feasible  
and the OP asked  for alternatives on a technical mailing list.   
Hopefully he can convince users to eventually migrate, but the point  
is that he needs an interim solution to avoid filtering authenticated  
clients on port 25.

Re: About SMTP Auth with Mysql

[Patrick Ben Koetter]

* Vahriç Muhtaryan :
> Any postfix guy have a knowledge about this issue
> Really I would like to solve this and debug
> Actually smtp -v do not show the problem also verbose mode to for sasl
> Any idea ?

It is the Postfix smtpd-daemon and not the smtp-client. If you debug add "-v"
to smtpd, not smtp.

Download saslfinger and run it:

saslfinger (debugging SMTP AUTH):


Send debug output to the list.

> -Original Message-
> From: owner-postfix-us...@postfix.org
> [mailto:owner-postfix-us...@postfix.org] On Behalf Of Vahriç Muhtaryan
> Sent: Sunday, November 22, 2009 11:21 PM
> To: 'Patrick Ben Koetter'; postfix-users@postfix.org
> Subject: RE: About SMTP Auth with Mysql
> 
> I hope that until find the right mailbox and pass it should query each
> setted mysql server but not !
> For to be sure I'm sending different mailbox name and password and wait
> postfix make query step by step but not.
> I told you before with different syntax postfix do differnt actions
> I don't know this is really postfix problem our cyrus problem but I couldn'T
> find any solution
> When you check cyrus docs my sytax is ok but its not working
> İts drive me crazy 

Sorry, but I don't understand what you write.

p...@rick





> 
> Regards
> Vahric
> 
> -Original Message-
> From: owner-postfix-us...@postfix.org
> [mailto:owner-postfix-us...@postfix.org] On Behalf Of Patrick Ben Koetter
> Sent: Sunday, November 22, 2009 4:44 PM
> To: postfix-users@postfix.org
> Subject: Re: About SMTP Auth with Mysql
> 
> * Vahriç Muhtaryan :
> > Hi,
> > 
> > (212.58.4.184,212.58.4.247) not worked
> > (212.58.4.184:3306,212.58.4.247:3306)query arrive to 4.247 but not to 184
> > 212.58.4.184:3306,212.58.4.247:3306 query arrive to 4.184 but not to 247
> > 212.58.4.184:3306 212.58.4.247:3306 query arrive to 4.184 but not to 247
> > sql_hostnames: 212.58.4.184 212.58.4.247 query arrive to 4.184 but not to
> > 247
> 
> How did you test?
> 
> Just in case you think it should query both servers at the same time: No,
> it's
> not supposed to do that.
> 
> If the 1st server in the list is inaccessible, it should try the second.
> 
> Have you tested that?
> 
> p...@rick
> 
> -- 
> All technical questions asked privately will be automatically answered on
> the
> list and archived for public access unless privacy is explicitely required
> and
> justified.
> 
> saslfinger (debugging SMTP AUTH):
> 
> 

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

saslfinger (debugging SMTP AUTH):

Re: Don't filter the users\

[Noel Jones]

On 11/24/2009 3:06 PM, Sahil Tandon wrote:


If only it were so. Think company that decides caters to thousands
(insert a larger number of your liking here to avoid another sarcastic
response that misses the point) of users on port 25 and can't one day
just STOP accepting all mail on that port, no matter how useful and
nicely worded the REJECT is that directs them to 587.

The OP has already stated he understands the merits of using the
submission port but needs another solution given his REAL WORLD constraints.

Let me be clear: I'm totally on board with using a separate submission
port for trusted users, but that is not always immediately feasible and
the OP asked for alternatives on a technical mailing list. Hopefully he
can convince users to eventually migrate, but the point is that he needs
an interim solution to avoid filtering authenticated clients on port 25.




OP can probably exploit the fact that end-user mail clients 
send to an A record, MTAs send to an MX.


Set smtp.example.com's A record to some IP that only accepts 
authenticated mail, and point the MX to a different IP.


... and then plan a 6 month migration to using port 587.

  -- Noel Jones

Re: Relay + selective dual authenticity check

[Stan Hoeppner]

Ka-rlis Repsons put forth on 11/24/2009 2:00 PM:

> Simply put, I just wouldn't like anyone ever to send out mail as myself and 
> get archived automatically on server as if it was actually me, who sends - 
> put 
> on such a barrier was my intention. Well, maybe a bit silly. But doesn't it 
> allow end-to-end authentication as a special case? Anyway, this is the part 
> "too much", right?

If this is the case, simply sign your messages with PGP in your MUA.
There is no need for end to end authentication in this case.  Signing
messages is about as close as one can get to certifying an email
actually came from an individual.

--
Stan

Re: Relay + selective dual authenticity check

[Kārlis Repsons]

On Tuesday 24 November 2009 20:00:38 you wrote:
> > > 6) before accepting message, server checks clients authenticity in
> > > similar  way, if user U is the source.
> >
> > You are trying to impose an end-to-end security model (end-user
> >  entitlements to send email, ...) onto a hop-by-hop infrastructure
> >  (Internet email).
> 
> Simply put, I just wouldn't like anyone ever to send out mail as myself and
> get archived automatically on server as if it was actually me, who sends -
>  put on such a barrier was my intention. Well, maybe a bit silly. But
>  doesn't it allow end-to-end authentication as a special case? Anyway, this
>  is the part "too much", right?
I cross off question #6 completely; answer not needed if #3 is done. 


signature.asc
Description: This is a digitally signed message part.

Re: Don't filter the users\

[Stan Hoeppner]

Noel Jones put forth on 11/24/2009 3:37 PM:

> OP can probably exploit the fact that end-user mail clients send to an A
> record, MTAs send to an MX.
> 
> Set smtp.example.com's A record to some IP that only accepts
> authenticated mail, and point the MX to a different IP.
> 
> ... and then plan a 6 month migration to using port 587.

Why bother?  This is an ISP scenario, correct?  The 587 command set is
standard SMTP right?  Just iptables (verb) TCP 25 to TCP 587 for any IP
ranges within the ISP's MUA customer range.  This is assuming said
customers already have to submit auth over TCP 25 to relay mail.  Simple
solution.  Done.

Or, have I missed something?

--
Stan

Re: Don't filter the users\

[Jerry]

On Tue, 24 Nov 2009 13:48:02 -0700
Michael Saldivar  replied:

>On Tue, Nov 24, 2009 at 1:25 PM, Sahil Tandon  wrote:
>
>> On Nov 24, 2009, at 3:07 PM, LuKreme  wrote:
>>
>>
>>> On 24-Nov-2009, at 10:39, Jordi Espasa Clofent wrote:
>>>
>>>  That is easy.
> Have your users connect to the submission port
>

 Yes Wietse, I've considered this simple and clean option,  but
 we're a hosting company and the costumers are to lazy to
 understand and accept an approach like this.

>>>
>>> Force them by making 587 the ONLY way to send mail. Tell them it's
>>> for security reasons and make sure you enforce it.
>>>
>>
>> That's all fine and well for small sites, but hardly a solution for
>> larger environments where such draconian measures are impractical.
>> A more reasonable solution is for the OP to push users toward
>> submission via 587, and in the (very long) meantime, find other ways
>> to bifurcate SASL vs. non-SASL traffic on port 25.
>>
>
>Small sites like Google, where they force their customers to use
>specific ports for e-mail submission?
>
>http://mail.google.com/support/bin/answer.py?answer=77689
>
>What's good for the Google is good for the Gander, eh?  You could even
>copy Google's help docs when writing your own.
>
>-Mike

Google's documentation, as usual, is in error. You can connect to SMTP
via port 25; however, you will need to use TLS if sending from your own
account.


--  
Jerry
postfix.u...@yahoo.com

TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

For some reason, this fortune reminds everyone of Marvin Zelkowitz.

Re: Don't filter the users\

[Jerry]

On Tue, 24 Nov 2009 16:06:44 -0500
Sahil Tandon  replied:

>On Nov 24, 2009, at 3:48 PM, Michael Saldivar
> > wrote:
>
>> On Tue, Nov 24, 2009 at 1:25 PM, Sahil Tandon   
>> wrote:
>> On Nov 24, 2009, at 3:07 PM, LuKreme  wrote:
>>
>>
>> On 24-Nov-2009, at 10:39, Jordi Espasa Clofent wrote:
>>
>> That is easy.
>> Have your users connect to the submission port
>>
>> Yes Wietse, I've considered this simple and clean option,  but
>> we're a hosting company and the costumers are to lazy to understand
>> and accept an approach like this.
>>
>> Force them by making 587 the ONLY way to send mail. Tell them it's  
>> for security reasons and make sure you enforce it.
>>
>> That's all fine and well for small sites, but hardly a solution for  
>> larger environments where such draconian measures are impractical.   
>> A more reasonable solution is for the OP to push users toward  
>> submission via 587, and in the (very long) meantime, find other
>> ways to bifurcate SASL vs. non-SASL traffic on port 25.
>>
>> Small sites like Google, where they force their customers to use  
>> specific ports for e-mail submission?
>
>Small sites like Google?  Sarcasm is adorable but rarely helps make  
>your point.
>
>> http://mail.google.com/support/bin/answer.py?answer=77689
>>
>> What's good for the Google is good for the Gander, eh?
>
>If only it were so.  Think company that decides caters to thousands  
>(insert a larger number of your liking here to avoid another
>sarcastic response that misses the point) of users on port 25 and
>can't one day just STOP accepting all mail on that port, no matter how
>useful and nicely worded the REJECT is that directs them to 587.

Excuse me, but does the name 'Comcast' ring a familiar note. They only
rescinded that decision when their support lines were over taxed by
calls. Personally, IMHO, they should have weathered it out. Their
customers would have smartened up eventually. In the long run, forcing
users to employ SMTP authentication, etc. does decrease the amount of
SPAM.

>The OP has already stated he understands the merits of using the  
>submission port but needs another solution given his REAL WORLD  
>constraints.

The real problem is that he is enabling a user base to control his
actions. He has to determine who is in charge. If he is, then he makes
the final decisions. If not, then 'quite bitchin'.

>Let me be clear: I'm totally on board with using a separate
>submission port for trusted users, but that is not always immediately
>feasible and the OP asked  for alternatives on a technical mailing
>list. Hopefully he can convince users to eventually migrate, but the
>point is that he needs an interim solution to avoid filtering
>authenticated clients on port 25.
>
>




--  
Jerry
postfix.u...@yahoo.com

TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

Klingon phaser attack from front!
100% Damage to life support

Re: Don't filter the users\

[Sahil Tandon]

On Tue, 24 Nov 2009, Jerry wrote:

> Sahil Tandon  replied:
> >If only it were so.  Think company that decides caters to thousands  
> >(insert a larger number of your liking here to avoid another
> >sarcastic response that misses the point) of users on port 25 and
> >can't one day just STOP accepting all mail on that port, no matter how
> >useful and nicely worded the REJECT is that directs them to 587.
> 
> Excuse me, but does the name 'Comcast' ring a familiar note. They only
> rescinded that decision when their support lines were over taxed by
> calls. Personally, IMHO, they should have weathered it out. Their
> customers would have smartened up eventually. In the long run, forcing
> users to employ SMTP authentication, etc. does decrease the amount of
> SPAM.

Thanks for the interesting anecdote, but it is rather non-sequitur and
probably more appropriate for spam-l than postfix-users.  I share your
anti-spam zeal, but that is not under discussion here.

> >The OP has already stated he understands the merits of using the  
> >submission port but needs another solution given his REAL WORLD  
> >constraints.
> 
> The real problem is that he is enabling a user base to control his
> actions. He has to determine who is in charge. If he is, then he makes
> the final decisions. If not, then 'quite bitchin'.

Wrong.  The real problem is that you are making baseless assumptions
about the OP's operating environment and customer base.  The "who is in
charge" mentality makes for fun macho narrative, but often does not
apply when paying customers and bureaucratic management types run the
show.  In those scenarios, the people running the mail servers take
orders and implement decisions from higher up.  No one is bitching in
this thread, so your note appears to have been mis-directed.  The point
remains that the OP is in an un-ideal situation and is seeking a
TECHNICAL workaround given a set of unfortunate constraints.  It is
perfectly reasonable to inform him about the virtues of 587 submission
(this was done early in the thread), but repeatedly swinging the same
cluebat in spite of context does not seem useful.  Speaking of which,
this thread has veered way off topic, so this is my last post on the
subject. :-)

-- 
Sahil Tandon 

Re: Postfix DKIM

[Sahil Tandon]

On Tue, 24 Nov 2009, Michael Saldivar wrote:

> I couldn't tell from the docs:
> http://www.ijs.si/software/amavisd/amavisd-new-docs.html#dkim
> 
> Does amavisd-new insert DomainKeys signatures also? or just DKIM?

This is the POSTFIX mailing list.  Please direct your question to the
AMAVISD-NEW mailing list.

-- 
Sahil Tandon 

Re: Bounce a particular recipient address with specified reject message

[Sahil Tandon]

On Tue, 24 Nov 2009, techlist06 wrote:

> I would like to setup postfix so it has a more friendly reject for
> mail sent to (via replys to my messages) "maill...@mydomain.com" with
> a particular reject message that instructs the user on what
> address(es) to use to better contact me.  Something similar to :
> 
> 550 reject The email address maill...@mydomain.com does not accept inbound
> mail.  Please use one of these addresses for contacting us: maillist
> unsubsubscribe: rem...@mydomain.com, support issues: supp...@mydomain.com,
> other i...@mydomain.com, etc.
> 
> Can someone help and tell me where is the best place to set this up?

Use an access(5) or transport(5) map:

 http://www.postfix.org/access.5.html
 http://www.postfix.org/transport.5.html

-- 
Sahil Tandon 

valid checkers for POSTFIX/DKIM/DOMAINKEYS

[Israel Garcia]

Hi

I'm really sorry if it's OT but I'm having problems verifying my setup
of postfix/dkim/domainkeys. I've found some dkim/domainkeys online
checkers, one told me dkim/domainkeys valid others checkers  not. When
sending the same test email to Google say it has domainkeys/dkim
valid, but yahoo doesn't.

Which dkim/domain cheker is telling me the truth?
is there any official dkim/domainkeys checker?

Also, Where can I find some good, new, tested guide to setup
postfix/dkim/domainkeys?

NOTE: I don't use amavisd or any other mailscanner. My setup now  is
simple, postfix, dkim-filter and dk-filter running on debian.

thanks much!

-- 
Regards;
Israel Garcia