Re: Local delivery not working properly

[Teh Kim Chooi]

ok, i missed out mydestination entry cause the bounce. after i put in the
entry, now i got mail from for xxx.xxx.com loops back to myself.

due to is a null client config, so i put xxx.xxx.com in relay_domains entry
also cannot help, anyone please help.

Jul 10 14:37:35 smtp1 postfix/cleanup[32546]: 691C24888010: message-id=<
20100710063735.691c24888...@xxx.xxx.com>
Jul 10 14:37:35 smtp1 postfix/qmgr[32513]: 691C24888010: from=<>, size=4092,
nrcpt=1 (queue active)
Jul 10 14:37:35 smtp1 postfix/bounce[32551]: 5B94E488800F: sender
non-delivery notification: 691C24888010
Jul 10 14:37:35 smtp1 postfix/qmgr[32513]: 5B94E488800F: removed
Jul 10 14:37:35 smtp1 postfix/smtp[32550]: 691C24888010: to=<
r...@xxx.xxx.com>, relay=none, delay=0, delays=0/0/0/0, dsn=5.4.6,
status=bounced (mail for xxx.xxx loops back to myself)
Jul 10 14:37:35 smtp1 postfix/qmgr[32513]: 691C24888010: removed



On Fri, Jul 9, 2010 at 10:58 AM, Teh Kim Chooi  wrote:

> Yes, i know i disable the local delivery agent, but i still wish to have
> root local delivery to be enable. I follow the document instruction never
> mention need to add virtual_mailbox_maps. I just try the
> virtual_mailbox_maps with r...@localhost, but i still get (local mail
> delivery is disabled), please help.
>
>
> On Fri, Jul 9, 2010 at 6:25 AM, Jeroen Geilman  wrote:
>
>>  On 07/08/2010 05:42 PM, Teh Kim Chooi wrote:
>>
>> Hi,
>>
>> i have disable local delivery follow the document instruction, then i
>> enable 2 user in the virtual file but not able to send to these users.
>>
>> Jul  8 22:57:07 smtp2 postfix/error[9618]: 3E7C82BE8004: to=<
>> postmas...@xxx.xxx.com>, orig_to=, relay=none, delay=0.01,
>> delays=0/0/0/0, dsn=5.0.0, status=bounced (local mail delivery is disabled)
>> Jul  8 22:57:07 smtp2 postfix/bounce[9619]: warning: 3E7C82BE8004:
>> undeliverable postmaster notification discarded
>> Jul  8 22:57:07 smtp2 postfix/qmgr[9611]: 3E7C82BE8004: removed
>> Jul  8 22:57:07 smtp2 postfix/cleanup[9617]: 3FC532BE8002: message-id=<
>> 20100708145707.3fc532be8...@smtp2.ytlcomms.com>
>> Jul  8 22:57:07 smtp2 postfix/qmgr[9611]: 3FC532BE8002: from=<
>> double-bou...@xxx.xxx.com>, size=5541, nrcpt=1 (queue active)
>> Jul  8 22:57:07 smtp2 postfix/bounce[9620]: 3E1DA2BE8003: postmaster
>> non-delivery notification: 3FC532BE8002
>> Jul  8 22:57:07 smtp2 postfix/qmgr[9611]: 3E1DA2BE8003: removed
>> Jul  8 22:57:07 smtp2 postfix/error[9618]: 3FC532BE8002: to=<
>> postmas...@xxx.xxx.com>, orig_to=, relay=none, delay=0,
>> delays=0/0/0/0, dsn=5.0.0, status=bounced (local mail delivery is disabled)
>> Jul  8 22:57:07 smtp2 postfix/bounce[9620]: warning: 3FC532BE8002:
>> undeliverable postmaster notification discarded
>> Jul  8 22:57:07 smtp2 postfix/qmgr[9611]: 3FC532BE8002: removed
>>
>> [r...@smtp2 postfix]# postconf -n
>> alias_database = hash:/etc/aliases
>> alias_maps = hash:/etc/aliases
>> command_directory = /usr/sbin
>> config_directory = /etc/postfix
>> daemon_directory = /usr/libexec/postfix
>> debug_peer_level = 2
>> home_mailbox = Maildir/
>> html_directory = no
>> inet_interfaces = all
>> mydestination =
>> local_recipient_maps =
>> local_transport = error:local mail delivery is disabled
>> mail_owner = postfix
>> mailq_path = /usr/bin/mailq.postfix
>> manpage_directory = /usr/share/man
>> mydomain = xxx.com
>> myhostname = xxx.xxx.com
>> mynetworks = 0.0.0.0/0
>> myorigin = xxx.com
>> newaliases_path = /usr/bin/newaliases.postfix
>> notify_classes = bounce, delay, resource, software
>> queue_directory = /var/spool/postfix
>> readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES
>> relay_domains = xxx.net, abc.my
>> sample_directory = /usr/share/doc/postfix-2.3.3/samples
>> sendmail_path = /usr/sbin/sendmail.postfix
>> setgid_group = postdrop
>> smtp_bind_address = 192.168.1.141
>> smtpd_client_restrictions = permit_mynetworks, check_client_access
>> hash:/etc/postfix/access, reject_unauth_destination
>> smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/access,
>> reject
>> transport_maps = hash:/etc/postfix/transport
>> unknown_local_recipient_reject_code = 550
>> virtual_alias_maps = hash:/etc/postfix/virtual
>>
>> [r...@smtp2 postfix]# tail virtual
>> #
>> # AUTHOR(S)
>> #Wietse Venema
>> #IBM T.J. Watson Research
>> #P.O. Box 704
>> #Yorktown Heights, NY 10598, USA
>> #
>> #
>> VIRTUAL(5)
>> rootr...@localhost
>> postmaster  postmas...@xxx.xxx.com
>>
>> i do comment out local in the master.cf file.
>>
>> From the document, i should be able to send email to root or postmaster,
>> but i cant, do i miss out something ?
>>
>> Regards,
>> Teh
>>
>>
>> Yes.
>> You have disabled all local delivery, which means that r...@localhost is
>> not a valid address.
>> And you have no virtual_mailbox_maps, so nothing (NOTHING) can be
>> delivered locally, on this machine. nothing. at all.
>>
>> J.
>>
>>
>

Re: Problem with tcp_table server

[Philipp Leusmann]

Am 09.07.2010 um 22:37 schrieb Wietse Venema:

> Victor Duchovni:
>> On Fri, Jul 09, 2010 at 04:04:59PM -0400, Wietse Venema wrote:
>> 
 Either your Postfix source is modified, miscompiled, the binaries are
 corrupted, or CPU is mal-functioning.
>>> 
>>> Or he is running a Postfix version before 2.6.
>>> 
>>> Citing the access(5) manpage:
>>> 
>>>   DEFER optional text...
>>>  Reject the address etc. that matches  the  pattern.  Reply  
>>> with
>>>  "$access_map_defer_code optional text..." when the optional 
>>> text
>>>  is specified, otherwise reply with a generic error response 
>>> mes-
>>>  sage.
>>> 
>>>  This feature is available in Postfix 2.6 and later.
>> 
>> Oops, I thought this was older. He reported running 2.5.5, so that
>> would explain the whole mess. In 2.5 "DEFER" is not an access(5) action
>> and so falls through to generic_checks, with the reported symptoms.
> 
> For the record:
> 
> Postfix has always supported
> 
>smtpd_mumble_restrictions = ... defer other_restrictions...
> 
> And access map lookup results of
> 
>... defer other_restrictions...
> 
> But only Postfix 2.6 and later support acces map lookup results of
> 
>defer optional-text-for-sender

Ok, then this Problem should be solved for me.

Thanks for all your help, guys.

Philipp

Re: Something Lighter Than Forward Address Verification?

[Wietse Venema]

Sabahattin Gucukoglu:
> Hi,
> 
> I am thinking about trying to replicate a feature I custom-built for my Se
>-ndmail installation, in Postfix.  What this does is, whenever a host I am ba
>-ckup for is mentioned in the SMTP RCPT command, I check to see if the host i
>-s up, and *refuse* the command (450) if it is.  The consequence of that is t
>-hat spammers, who normally buzz off when told, can be tested by a primary ho
>-st using all of the techniques at the primary's disposal - DNSBL, greylist, 
>-etc.  Any SMTP-time refusal is done by the primary, where it makes the most 
>-sense, even after the DATA command where verification has no arbitration.  F
>-inally, dictionary attacks have less effect since the probe is limited to st
>-arting up a connection and reading a banner once for the duration of the cac
>-he time.
> 
> Unfortunately, this doesn't seem to be within the realm of Postfix's recip
>-ient address verification.  Have I missed anything?

The purpose of sender or recipient verification is to reject bogus
addresses. To increase the realism of these tests, Postfix uses
the same mechanisms as regular mail i.e.  it doesn't care if the
reply comes from a primary MX host or from a backup. 

Moreover, Postfix assumes that a "positive" reply (the recipient
is "valid") can be cached for a significant amount of time.

You are trying to determine if the preferred MX host is up.  I see
zero opportunity for code reuse here.

>  Even if I were to set t
>-he temporary fail during verification code to 250, I'd potentially accept re
>-sponsibility for mail I shouldn't regardless of whether the host was really 
>-up, if I could not queue verify probes.  How can I get the desired effect, o
>-r will I need a policy server to do this?

Yes. There is nothing wrong with using one of the Postfix extension
interfaces to add a feature that isn't built-in.

Wietse

Re: additional parameters to the SMTP MAIL and RCPT commands

[Sabahattin Gucukoglu]

On 10 Jul 2010, at 00:10, Sufian Hameed wrote:
> can you please elaborate? what is wrong?
> 
> RCPT TO: [ SP  ]  is the syntax 
> mentioned in RFC 2821. 
> 
1.  "SP" is part of the ABNF grammar in the formal specification of the syntax 
of the command.  It means a space character.  There is no literal "SP" in the 
command.  For example:
RCPT To: notify=success,failure,delay

2.  The SMTP server is not obliged to understand parameters it does not 
implement.  If the EHLO response doesn't include a feature you need, you (as a 
client) cannot use it.

3.  RFC 5321 is the current draft standard, and it's under revision (in the YAM 
working group of the IETF) to full standard.

Cheers,
Sabahattin



smime.p7s
Description: S/MIME cryptographic signature

Re: additional parameters to the SMTP MAIL and RCPT commands

[Sufian Hameed]

Hi,

can you please elaborate? what is wrong?

RCPT TO: [ SP  ]  is the syntax
mentioned in RFC 2821.

regards

On Sat, Jul 10, 2010 at 1:01 AM, Rod Dorman  wrote:

> On Friday, July 9, 2010, 18:57:10, Rod Dorman wrote:
> > On Friday, July 9, 2010, 17:42:37, Sufian Hameed wrote:
> >> does Postfix Supports  additional parameters to the SMTP MAIL and RCPT
> >> commands as mentioned in RFC 2821 and others?
> >>
> >>  RCPT TO: [ SP  ] 
> >>
> >> i have tried to use something like as follows in the sender Postfix
> Server
> >> RCPT TO: SP 
> >> but it is not accepted by the recipient postfix server and gives an
> error
> >> 555 5.5.4 Unsupported option: SP (in reply to the RCPT TO command)
> >> any idea whats wrong ?
> >
> > You are aware that SP is one of the core AFNF rules and represents a
>
> sigh... lets pretend I typed ABNF as in Augmented BNF
>
> --
> r...@polylogics.com "The avalanche has already started, it is too
> Rod Dorman  late for the pebbles to vote." - Ambassador Kosh
>
>
>

Re: additional parameters to the SMTP MAIL and RCPT commands

[Rod Dorman]

On Friday, July 9, 2010, 18:57:10, Rod Dorman wrote:
> On Friday, July 9, 2010, 17:42:37, Sufian Hameed wrote:
>> does Postfix Supports  additional parameters to the SMTP MAIL and RCPT
>> commands as mentioned in RFC 2821 and others?
>>
>>  RCPT TO: [ SP  ] 
>>
>> i have tried to use something like as follows in the sender Postfix Server
>> RCPT TO: SP 
>> but it is not accepted by the recipient postfix server and gives an error
>> 555 5.5.4 Unsupported option: SP (in reply to the RCPT TO command)
>> any idea whats wrong ?
>
> You are aware that SP is one of the core AFNF rules and represents a

sigh... lets pretend I typed ABNF as in Augmented BNF

-- 
r...@polylogics.com "The avalanche has already started, it is too
Rod Dorman  late for the pebbles to vote." - Ambassador Kosh

Something Lighter Than Forward Address Verification?

[Sabahattin Gucukoglu]

Hi,

I am thinking about trying to replicate a feature I custom-built for my 
Sendmail installation, in Postfix.  What this does is, whenever a host I am 
backup for is mentioned in the SMTP RCPT command, I check to see if the host is 
up, and *refuse* the command (450) if it is.  The consequence of that is that 
spammers, who normally buzz off when told, can be tested by a primary host 
using all of the techniques at the primary's disposal - DNSBL, greylist, etc.  
Any SMTP-time refusal is done by the primary, where it makes the most sense, 
even after the DATA command where verification has no arbitration.  Finally, 
dictionary attacks have less effect since the probe is limited to starting up a 
connection and reading a banner once for the duration of the cache time.

Unfortunately, this doesn't seem to be within the realm of Postfix's recipient 
address verification.  Have I missed anything?  Even if I were to set the 
temporary fail during verification code to 250, I'd potentially accept 
responsibility for mail I shouldn't regardless of whether the host was really 
up, if I could not queue verify probes.  How can I get the desired effect, or 
will I need a policy server to do this?

Cheers,
Sabahattin



smime.p7s
Description: S/MIME cryptographic signature

Re: additional parameters to the SMTP MAIL and RCPT commands

[Rod Dorman]

On Friday, July 9, 2010, 17:42:37, Sufian Hameed wrote:
> does Postfix Supports  additional parameters to the SMTP MAIL and RCPT
> commands as mentioned in RFC 2821 and others?
>
>  RCPT TO: [ SP  ] 
>
> i have tried to use something like as follows in the sender Postfix Server
> RCPT TO: SP 
> but it is not accepted by the recipient postfix server and gives an error
> 555 5.5.4 Unsupported option: SP (in reply to the RCPT TO command)
> any idea whats wrong ?

You are aware that SP is one of the core AFNF rules and represents a
single space character.


-- 
r...@polylogics.com "The avalanche has already started, it is too
Rod Dorman  late for the pebbles to vote." - Ambassador Kosh

additional parameters to the SMTP MAIL and RCPT commands

[Sufian Hameed]

Hi all,

does Postfix Supports  additional parameters to the SMTP MAIL and RCPT
commands as mentioned in RFC 2821 and others?

 RCPT TO: [ SP  ] 

i have tried to use something like as follows in the sender Postfix Server


 RCPT TO: SP 

but it is not accepted by the recipient postfix server and gives an error

555 5.5.4 Unsupported option: SP (in reply to the RCPT TO command)

any idea whats wrong ?

regards

sufian

Re: Selective outbound relaying II

[Ville Walveranta]

Resolved!

Another concurrent thread "SASL Authentication per recipient domain"
gave additional clues.

I ended up using a PCRE map for sender_dependent_relayhost_maps
(domain names changed to protect the innocent and to better illustrate
what was done):

main.cf:
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps =
hash:$config_directory/tables/smtp_sasl_password_maps
sender_dependent_relayhost_maps =
pcre:$config_directory/tables/smtp_relayhost_maps.pcre
smtp_tls_policy_maps = hash:$config_directory/tables/smtp_tls_policy_maps

smtp_sasl_password_maps:
[external.relaydomain.com]:2000 relayu...@relaydomain.com:password

smtp_relayhost_maps.pcre:
!/@mylocaldomain\.net$/ [external.relaydomain.com]:2000

smtp_tls_policy_maps:
[external.relaydomain.com]:2000 encrypt


Now all locally accepted domains except for "mylocaldomain.net" are
relayed via external.relaydomain.com listening at port 2000. TLS and
SASL authentication are used for external.relaydomain.com while emails
sent from mylocaldomain.net domain are delivered directly to recipient
smtp servers without SASL authentication or TLS.

In the end the resolution always tends to be rather simple, but for
people who don't live & breathe Postfix the (admittedly very good)
documentation can be a beast to comb through to find the appropriate
parameters and their application.  But I'm not complaining, the more
documentation the better!  Whenever I work with Postfix I still always
marvel its flexibility as compared to the ol' qmail I used to run few
years back.

Ville

Re: SASL Authentication per recipient domain

[Sahil Tandon]

On Fri, 2010-07-09 at 16:12:41 +0200, David Jacobson wrote:

[ .. ]

> It just seems like SASL doesn't support PCRE. 

The statement does not make sense.

> Just for the sake of clarification we've found what we're looking for,
> PCRE was not required. 

PCRE is not *required*, but it would be fine if you followed the
documentation.

> We simply made smtp_sender_dependent_authentication = yes then
> sasl_passwd could accept @domain.com - took us now 2 days to figure
> this one out. 

Why 2 days?  You were linked to the documentation for
smtp_sasl_password_maps, and there, following the first comma: "or
sender address **WHEN** sender-dependent authentication is enabled"

-- 
Sahil Tandon 

Re: Problem with tcp_table server

[Wietse Venema]

Victor Duchovni:
> On Fri, Jul 09, 2010 at 04:04:59PM -0400, Wietse Venema wrote:
> 
> > > Either your Postfix source is modified, miscompiled, the binaries are
> > > corrupted, or CPU is mal-functioning.
> > 
> > Or he is running a Postfix version before 2.6.
> > 
> > Citing the access(5) manpage:
> > 
> >DEFER optional text...
> >   Reject the address etc. that matches  the  pattern.  Reply  
> > with
> >   "$access_map_defer_code optional text..." when the optional 
> > text
> >   is specified, otherwise reply with a generic error response 
> > mes-
> >   sage.
> > 
> >   This feature is available in Postfix 2.6 and later.
> 
> Oops, I thought this was older. He reported running 2.5.5, so that
> would explain the whole mess. In 2.5 "DEFER" is not an access(5) action
> and so falls through to generic_checks, with the reported symptoms.

For the record:

Postfix has always supported

smtpd_mumble_restrictions = ... defer other_restrictions...

And access map lookup results of

... defer other_restrictions...

But only Postfix 2.6 and later support acces map lookup results of

defer optional-text-for-sender

Wietse

Re: Problem with tcp_table server

[Victor Duchovni]

On Fri, Jul 09, 2010 at 04:04:59PM -0400, Wietse Venema wrote:

> > Either your Postfix source is modified, miscompiled, the binaries are
> > corrupted, or CPU is mal-functioning.
> 
> Or he is running a Postfix version before 2.6.
> 
> Citing the access(5) manpage:
> 
>DEFER optional text...
>   Reject the address etc. that matches  the  pattern.  Reply  with
>   "$access_map_defer_code optional text..." when the optional text
>   is specified, otherwise reply with a generic error response mes-
>   sage.
> 
>   This feature is available in Postfix 2.6 and later.

Oops, I thought this was older. He reported running 2.5.5, so that
would explain the whole mess. In 2.5 "DEFER" is not an access(5) action
and so falls through to generic_checks, with the reported symptoms.

-- 
Viktor.

Re: Problem with tcp_table server

[Victor Duchovni]

On Fri, Jul 09, 2010 at 08:56:38PM +0200, Philipp Leusmann wrote:

> It would be nice, if somebody else, also running a Debian Lenny (it's lenny, 
> not etch) system could verify this behavior.
> 
> Anybody here?
> 
> I will also reinstall postfix and try again.

If it is compiled with debugging symbols, you could try to single-step
through check_table_result() to see why the "DEFER" case is not matched.

#define STREQUAL(x,y,l) (strncasecmp((x), (y), (l)) == 0 && (y)[l] == 0)

...

if (STREQUAL(value, "DEFER", cmd_len)) {
dsn_split(&dp, "4.7.1", cmd_text);
return (smtpd_check_reject(state, MAIL_ERROR_POLICY,
   var_map_defer_code,
   smtpd_dsn_fix(DSN_STATUS(dp.dsn),
 reply_class),
   "<%s>: %s rejected: %s",
   reply_name, reply_class,
   *dp.text ? dp.text : "Access denied"));
}

So assuming that strncasecmp() is working correctly, the length cmd_len
computed via strcspn() is correct, and your result starts with
"DEFER" (which logs suggest), there is no way to get past
this block and not return before the generic_checks() call lower in the
function.

-- 
Viktor.

Re: Problem with tcp_table server

[Wietse Venema]

Victor Duchovni:
> On Fri, Jul 09, 2010 at 07:25:45PM +0200, Philipp Leusmann wrote:
> 
> > Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: dict_tcp_lookup: send: get 
> > be...@xxx.de
> > Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: dict_tcp_lookup: recv: 200 
> > DEFER%20User%20over%20quota
> > Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: dict_tcp_lookup: found: 
> > DEFER User over quota
> > Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: check_table_result: 
> > tcp:localhost:1337 DEFER User over quota be...@xxx.de
> 
> So far, so good.
> 
> > Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: >>> START Recipient address 
> > RESTRICTIONS <<<
> 
> It should never get here, the code in check_table_result() handles strings
> starting with "DEFER  ..." directly, without delegating
> to the "generic_checks" code.
> 
> Either your Postfix source is modified, miscompiled, the binaries are
> corrupted, or CPU is mal-functioning.

Or he is running a Postfix version before 2.6.

Citing the access(5) manpage:

   DEFER optional text...
  Reject the address etc. that matches  the  pattern.  Reply  with
  "$access_map_defer_code optional text..." when the optional text
  is specified, otherwise reply with a generic error response mes-
  sage.

  This feature is available in Postfix 2.6 and later.


Wietse

Re: Problem with tcp_table server

[Philipp Leusmann]

Am 09.07.2010 um 19:46 schrieb Victor Duchovni:

> On Fri, Jul 09, 2010 at 07:25:45PM +0200, Philipp Leusmann wrote:
> 
>> Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: dict_tcp_lookup: send: get 
>> be...@xxx.de
>> Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: dict_tcp_lookup: recv: 200 
>> DEFER%20User%20over%20quota
>> Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: dict_tcp_lookup: found: 
>> DEFER User over quota
>> Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: check_table_result: 
>> tcp:localhost:1337 DEFER User over quota be...@xxx.de
> 
> So far, so good.
> 
>> Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: >>> START Recipient address 
>> RESTRICTIONS <<<
> 
> It should never get here, the code in check_table_result() handles strings
> starting with "DEFER  ..." directly, without delegating
> to the "generic_checks" code.
> 
> Either your Postfix source is modified, miscompiled, the binaries are
> corrupted, or CPU is mal-functioning.
> 
>> Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: generic_checks: name=DEFER
>> Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: NOQUEUE: reject: RCPT from 
>> mta-2.ms.rz.RWTH-Aachen.DE[134.130.7.73]: 450 4.3.2 : 
>> Recipient address rejected: Try again later; 
>> from= to= proto=ESMTP 
>> helo=
>> Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: warning: restriction `User' 
>> after `defer' is ignored
>> Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: generic_checks: name=DEFER 
>> status=2
>> Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: generic_checks: 
>> name=check_recipient_access status=2
> 
>> 
>> postconf -n shows this:
>> 
>> smtpd_recipient_restrictions =
>>  permit_mynetworks,
>>  reject_unauth_destination,
>>  reject_unlisted_recipient,
>>  check_recipient_access tcp:localhost:1337
> 
> OK, this is an access(5) check as expected, and goes through
> check_table_result(), which implements "DEFER ". So your system
> is not behaving as the original Postfix would on a working machine
> running correctly compiled code.
> 
>> BTW: I am running Postfix 2.5.5-1.1 on Debian Etch (?. I never can
>> remember. The latest one :) )
> 
> The relevant code has not changed in quite some time.


It would be nice, if somebody else, also running a Debian Lenny (it's lenny, 
not etch) system could verify this behavior.

Anybody here?

I will also reinstall postfix and try again.

Philipp

Re: asking ARP for an internal IP 169.254.140.241

[Noel Jones]

On 7/9/2010 11:35 AM, Phil Howard wrote:

On Fri, Jul 9, 2010 at 12:09, Stéphane MERLE
  wrote:


I would have 2 questions :
- 1 what is the procedure for postfix when it try to send email to a
domain with no MX record ?
like : dig mx elv.enic.fr

- 2 would that be an offense to refuse to send to domain with no MX
record ? (I don't know if there's a lot of them)
-2+ : how can I do that with postfix ?

Thanks for your help ...

Stéphane


It doesn't matter.  It is valid for domains to have or not have an MX
record.  It will need an A record if no MX record.

Based on your tcpdump output in your private reply to me, some other
domain is answering an A query (whether after an MX or not) with
169.254.140.241.  So it's not a Postfix issue, and probably not even
your server issue, unless your own DNS server has that configured.

For the list ... it's a case of some DNS answering with the LL address
... case closed with respect to Postfix.



To bring this back to postfix, you can reject domains with 
bogus IPs like this by using check_sender_mx_access.

http://www.postfix.org/postconf.5.html#check_sender_mx_access
(if there's no MX, the A record will be used)

Something like...
smtpd_recipient_restrictions =
  permit_mynetworks
  reject_unauth_destination
  ... other local stuff ...
  check_sender_mx_access cidr:/etc/postfix/bogus_mx.cidr


# /etc/postfix/bogus_mx.cidr
169.254.0.0/16  REJECT rfc3927 address
... other IPs you consider bogus ...

Note: there is a slight risk of false positives from legit but 
misconfigured domains.



  -- Noel Jones

Re: Greylisting & SMTP auth

[Christopher Sean Hilton]

On Jul 9, 2010, at 4:57 AM, Hendrik Pahl wrote:

> Hi folks,
> 
> we're having some trouble with greylisting (postgrey) and smtp auth.
> 
> smtp_recipient_restrictions looks like:
> 

I'm not sure what the rest of your network looks like but I greylist through 
openbsd's spamd and to sasl authenticated SMTP submission on tcp/465 and 
tcp/587. The details are as follows:


 tcp/25 -- greylisted

 tcp/465, tcp/587 -- not greylisted, TLS required, SMTP Auth required.

Obviously this works for me because I can tell my clients that they should 
submit mail at tcp/587 rather than port 25. (I also submission on tcp/465 
because some older Outlook clients default there.) I had guessed that this was 
the pretty standard these days.

-- Chris

Chris Hilton   tildeChris -- http://myblog.vindaloo.com
email -- chris/at/vindaloo/dot/com
.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.
 "I'm on the outside looking inside, What do I see?
   Much confusion, disillution, all around me."
 -- Ian McDonald / Peter Sinfield

Re: Problem with tcp_table server

[Victor Duchovni]

On Fri, Jul 09, 2010 at 07:25:45PM +0200, Philipp Leusmann wrote:

> Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: dict_tcp_lookup: send: get 
> be...@xxx.de
> Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: dict_tcp_lookup: recv: 200 
> DEFER%20User%20over%20quota
> Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: dict_tcp_lookup: found: DEFER 
> User over quota
> Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: check_table_result: 
> tcp:localhost:1337 DEFER User over quota be...@xxx.de

So far, so good.

> Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: >>> START Recipient address 
> RESTRICTIONS <<<

It should never get here, the code in check_table_result() handles strings
starting with "DEFER  ..." directly, without delegating
to the "generic_checks" code.

Either your Postfix source is modified, miscompiled, the binaries are
corrupted, or CPU is mal-functioning.

> Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: generic_checks: name=DEFER
> Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: NOQUEUE: reject: RCPT from 
> mta-2.ms.rz.RWTH-Aachen.DE[134.130.7.73]: 450 4.3.2 : Recipient 
> address rejected: Try again later; from= 
> to= proto=ESMTP helo=
> Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: warning: restriction `User' 
> after `defer' is ignored
> Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: generic_checks: name=DEFER 
> status=2
> Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: generic_checks: 
> name=check_recipient_access status=2

> 
> postconf -n shows this:
> 
> smtpd_recipient_restrictions =
>   permit_mynetworks,
>   reject_unauth_destination,
>   reject_unlisted_recipient,
>   check_recipient_access tcp:localhost:1337

OK, this is an access(5) check as expected, and goes through
check_table_result(), which implements "DEFER ". So your system
is not behaving as the original Postfix would on a working machine
running correctly compiled code.

> BTW: I am running Postfix 2.5.5-1.1 on Debian Etch (?. I never can
> remember. The latest one :) )

The relevant code has not changed in quite some time.

-- 
Viktor.

Re: Problem with tcp_table server

[Philipp Leusmann]

Am 09.07.2010 um 17:39 schrieb Victor Duchovni:

> On Fri, Jul 09, 2010 at 04:13:28PM +0200, Philipp Leusmann wrote:
> 
>> Jul  9 16:07:00 s15277780 postfix/smtpd[18815]: NOQUEUE: reject:
>>  RCPT from c-68-57-126-48.hsd1.va.comcast.net[68.57.126.48]:
>>  450 4.3.2 : Recipient address rejected:
>>  Try again later; from= to=
>>  proto=ESMTP helo=
> 
> This is how "defer" gets processed when it is processed in a restriction
> class definition, rather than access table lookup result.
> 
>> Jul  9 16:07:00 s15277780 postfix/smtpd[18815]: warning: restriction
>>  `User' after `defer' is ignored
> 
> This does not look possible for a result of "DEFER ..." found in a lookup
> table. Can you run the smtpd(8) server with debug_peer_list setting
> that matches a test ip from which you can initiate a test transaction,
> and report log entries just above, matching and just below:
> 
>   smtpd[pid]: check_table_result: ...
> 
> I can only explain your observations if "DEFER" is not the first
> token in the table return value. It would be helpful to see your
> "postconf -n" also, so we can see the context in which the tcp
> table is used.
> 

Hi Victor,

this is from the verbose lofile:

Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: dict_tcp_lookup: send: get 
be...@xxx.de
Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: dict_tcp_lookup: recv: 200 
DEFER%20User%20over%20quota
Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: dict_tcp_lookup: found: DEFER 
User over quota
Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: check_table_result: 
tcp:localhost:1337 DEFER User over quota be...@xxx.de
Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: >>> START Recipient address 
RESTRICTIONS <<<
Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: generic_checks: name=DEFER
Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: NOQUEUE: reject: RCPT from 
mta-2.ms.rz.RWTH-Aachen.DE[134.130.7.73]: 450 4.3.2 : Recipient 
address rejected: Try again later; from= 
to= proto=ESMTP helo=
Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: warning: restriction `User' 
after `defer' is ignored
Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: generic_checks: name=DEFER 
status=2
Jul  9 19:15:25 s15277780 postfix/smtpd[22232]: generic_checks: 
name=check_recipient_access status=2



postconf -n shows this:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
debug_peer_list = 134.130.7.73, 134.130.7.72
fallback_transport = cyrus
inet_interfaces = all
local_recipient_maps = proxy:unix:passwd.byname, $alias_maps, 
mysql:/etc/postfix/my_recipient_maps.cf
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
mailbox_transport = dspam
mydestination = XXX.de, YYY.de, localhost
myhostname = YYY.de
mynetworks = 127.0.0.0/8
myorigin = /etc/mailname
recipient_delimiter = +
relayhost = 
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, 
reject_unlisted_recipient , check_recipient_access tcp:localhost:1337
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = 
smtpd_sasl_path = smtpd
smtpd_sasl_security_options = noanonymous
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:${queue_directory}/smtpd_scache
smtpd_use_tls = yes



Hope that helps.
BTW: I am running Postfix 2.5.5-1.1 on Debian Etch (?. I never can remember. 
The latest one :) ) 

Philipp

Re: Problem with tcp_table server

[Wietse Venema]

Philipp Leusmann:
> > I need to see ONE example of verbose logging that shows 
> > 
> > (
> > 
> > tcp_table returning the string that is giving the above error, 
> > 
> > AND
> > 
> > the Postfix SMTP server processing that result
> > 
> > ).
> 
> Sorry, I still don't get, what you mean.

I need to see VERBOSE LOGGING FROM POSTFIX that shows:

(

tcp_table returning the string that is giving the above error,

AND

the Postfix SMTP server processing that result

).

Re: asking ARP for an internal IP 169.254.140.241

[Phil Howard]

On Fri, Jul 9, 2010 at 12:09, Stéphane MERLE
 wrote:

> I would have 2 questions :
>    - 1 what is the procedure for postfix when it try to send email to a
> domain with no MX record ?
>            like : dig mx elv.enic.fr
>
>    - 2 would that be an offense to refuse to send to domain with no MX
> record ? (I don't know if there's a lot of them)
>            -2+ : how can I do that with postfix ?
>
> Thanks for your help ...
>
> Stéphane

It doesn't matter.  It is valid for domains to have or not have an MX
record.  It will need an A record if no MX record.

Based on your tcpdump output in your private reply to me, some other
domain is answering an A query (whether after an MX or not) with
169.254.140.241.  So it's not a Postfix issue, and probably not even
your server issue, unless your own DNS server has that configured.

For the list ... it's a case of some DNS answering with the LL address
... case closed with respect to Postfix.

-- 
sHiFt HaPpEnS!

Re: SASL Authentication per recipient domain

[Victor Duchovni]

On Fri, Jul 09, 2010 at 04:12:41PM +0200, David Jacobson wrote:

> We tried PCRE matches to no avail. Based on your request we tried to change 
> sasl_passwd lookup from hash to pcre (I'm no postfix guy, so have no idea if 
> this should work or not, but postfix restart didn't complain) 
> 
> smtp_sasl_password_maps = pcre:/opt/zimbra/postfix/conf/sasl_passwd 

This is documented (clearly I might add) to use the nexthop gateway
as the lookup key, unless you have followed the directions in:

http://www.postfix.org/SOHO_README.html#client_sasl_sender

to enable per-sender passwords, in which case the lookup key is the
sender address (and then the nexthop as a default fallback).

> 
> Then in sasl_passwd tried various combinations including: 
> 
> /@domain\.com$/ username:password 

This won't match the nexthop, if you have not enabled per sender
password lookups.

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

-- 
Viktor.

Re: asking ARP for an internal IP 169.254.140.241

[Victor Duchovni]

On Fri, Jul 09, 2010 at 06:09:26PM +0200, St?phane MERLE wrote:

> Hi,
>
> I would have 2 questions :
> - 1 what is the procedure for postfix when it try to send email to a 
> domain with no MX record ?
> like : dig mx elv.enic.fr

Per 20+ year old SMTP standards it sends to the A record. MX records
are optional, and anyone who wants to debate this here (again) will
find themselves no longer on this list... No follow-ups please.

> - 2 would that be an offense to refuse to send to domain with no MX 
> record ? (I don't know if there's a lot of them)

It is wrong to require MX records.

-- 
Viktor.

Re: asking ARP for an internal IP 169.254.140.241

[Stéphane MERLE]

Hi,

I would have 2 questions :
- 1 what is the procedure for postfix when it try to send email to 
a domain with no MX record ?

like : dig mx elv.enic.fr

- 2 would that be an offense to refuse to send to domain with no MX 
record ? (I don't know if there's a lot of them)

-2+ : how can I do that with postfix ?

Thanks for your help ...

Stéphane

Le 09/07/2010 15:48, Stéphane MERLE a écrit :

Hi,

Le 09/07/2010 15:21, Victor Duchovni a écrit :

On Fri, Jul 09, 2010 at 01:47:40PM +0200, St?phane MERLE wrote:

   

Hi,

My ISP (ovh) is complaining about my postfix servers doing wrong ARP
demand, do you have any idea of what can cause this in my postfix
configuration ?

188.165.55.92 : is one of the server ip (ip failover)

Thu Jul 8 02:03:32 2010 : arp who-has 169.254.140.241 tell 188.165.55.92
 

This IP address is a link-local IP address:

 http://tools.ietf.org/html/rfc3927

these support zero-configuration local networking, ...

   

19:43:20.840082 arp reply 169.254.140.241 is-at 00:24:c3:84:04:00
 

Your ISP or router is proxy-arping for this IP, it should not. Link-local
addresses should be exempt (if possible).

   

19:43:20.840087 IP ovh63.bpreducer.com.59549>  169.254.140.241.smtp: S
1213354010:1213354010(0) win 5840
 

Why are are sending email to this IP address? Any Postfix logs that
indicate attempts to connect to this relay?

   

if you need the postfix conf files, I will send it in.
 

Mostly just logs that show the life-cycle of a message (all log entries
for its queue-id) in which deliveries to this IP address were attempted
and failed.

   


Thank you, because of your post, I checked in the postfix logs and 
found : aha...@elv.enic.fr


Jul  9 01:18:33 ovh63 postfix/smtp[30687]: connect to 
elv.enic.fr[169.254.140.241]:25: Connection timed out
Jul  9 01:18:33 ovh63 postfix/smtp[30687]: 138C92011CE6: 
to=, relay=none, delay=45185, delays=45095/0/90/0, 
dsn=4.4.1, status=deferred (connect to 
elv.enic.fr[169.254.140.241]:25: Connection timed out)


I first clean that domain from the database and then check my bot 
cleanner which missed this.


Thank you !!

Stéphane

Re: Problem with tcp_table server

[Victor Duchovni]

On Fri, Jul 09, 2010 at 04:13:28PM +0200, Philipp Leusmann wrote:

> Jul  9 16:07:00 s15277780 postfix/smtpd[18815]: NOQUEUE: reject:
>   RCPT from c-68-57-126-48.hsd1.va.comcast.net[68.57.126.48]:
>   450 4.3.2 : Recipient address rejected:
>   Try again later; from= to=
>   proto=ESMTP helo=

This is how "defer" gets processed when it is processed in a restriction
class definition, rather than access table lookup result.

> Jul  9 16:07:00 s15277780 postfix/smtpd[18815]: warning: restriction
>   `User' after `defer' is ignored

This does not look possible for a result of "DEFER ..." found in a lookup
table. Can you run the smtpd(8) server with debug_peer_list setting
that matches a test ip from which you can initiate a test transaction,
and report log entries just above, matching and just below:

smtpd[pid]: check_table_result: ...

I can only explain your observations if "DEFER" is not the first
token in the table return value. It would be helpful to see your
"postconf -n" also, so we can see the context in which the tcp
table is used.

-- 
Viktor.

Re: Problem with tcp_table server

[Noel Jones]

On 7/9/2010 6:46 AM, Philipp Leusmann wrote:


Am 08.07.2010 um 20:55 schrieb Noel Jones:


On 7/8/2010 12:13 PM, Philipp Leusmann wrote:

thanks for your advice. This really should be pointed out more explicitly in 
the documentation.

As for 500, would it be a good practice to return 500, if the key, which in 
this case is the email-adress is not known at all?

I also use a local_recipients_map, which already decides if a user exists or 
not.
So, which of the both is evaluated first? local_recipient_maps or 
smtpd_recipient_restrictions ?

What would be the best practice for my case?

Regards,
Philipp


I expect returning 500 for users under quota or non-existent users would be 
appropriate.

Alternately, you could return "200 REJECT" for non-existent users, and "200 
DUNNO" for under-quota users.

You probably don't want to use "200 OK" for under-quota users since that will 
bypass any further antispam checks you might want to do.


Noel,

I guess at least one "under quota" should read "over quota", doesn't it?


No, my advice is correct as written above.

Returning "no match" for both under quota and non-existent 
users should be fine.


When you're using tcp_table as an access map, the possible 
results are documented in access(5)


In general it's better to REJECT over-quota recipients rather 
than DEFER.  The exception would be if you expect the 
over-quota users will always clear space in their mailbox 
quickly.  With REJECT the sender gets immediate feedback that 
the recipient didn't receive the message.  With DEFER, that 
non-delivery notification could be delayed for several days.





Also, is there any any reference documentation about the possible response 
string?
For example DUNNO would not be something, which I would try to use naturally.
Also in my logfiles, I notice entries like

warning: restriction `User' after `defer' is ignored

when I return something like

200 DEFER User is over quota

I guess there is some special string expected after DEFER ?

Regards,
  Philipp




That sounds as if the table is not being used as an access 
map, and postfix is expecting a main.cf restriction with no 
text allowed.

Re: email account bombarded with SPAM error bounces - what to do?

[Robert Schetterer]

Am 09.07.2010 16:13, schrieb Administrator Beckspaced.com:
> 
> 
> On 7/9/2010 14:40, Ram wrote:
>> On Fri, 2010-07-09 at 13:35 +0200, Administrator Beckspaced.com wrote:
>>> On 7/9/2010 13:27, Robert Schetterer wrote:
 Am 09.07.2010 12:51, schrieb Administrator Beckspaced.com:
>hello robert,
>
> thanks a lot for your quick reply ...
> actually it is not always the same IP or host sending the error
> bounces ...
> the bounces are sent from hundred of different IP addresses ...
>
> any more idea?
>
>> Usually you can do very little to prevent forging your domain and
>> sending spam.
>> Some months ago one client of ours too had the same issue, but the issue
>> is very temporary.
>> The short term solution , as someone suggested, will be to temporarily
>> defer all NDR's  with a sender check regex file like
>> /<>/450Try Later
>>
>>
>> ( The RFC's say you cant do this .. but sometimes you must be
>> practical :-) )
>>
>>
>>
>>
>> > From my personal experience I found that if , for your regular mailing
>> you use some sender authentication mechanism like SPF then these NDR's
>> significantly reduce. For eg many servers reject forged messages based
>> on SPF checks so you dont get NDR's from them at least.
>>
>> I guess , spammers ( the more intelligent ones ... I mean )  too would
>> be less inclined to forge a domain that uses sender authentication
>> Because that will reduce the deliverability of their spams
>>
>> Thanks
>> Ram
>>
>>
>>
>>
>>
> hello again robert & ram
> 
> thanks again for your ideas ...
> 
> so i had another search in google about that backscatter topic and sort
> of found a nice, simple & also quick solution?
> 
> SAFE MODE with Postfix:
> 
> Edit /etc/postfix/main.cf:
> smtpd_recipient_restrictions =
> ...
> check_sender_access dbm:/etc/postfix/check_backscatterer
> ...
> Create new file:/etc/postfix/check_backscatterer:
> <> reject_rbl_client ips.backscatterer.org
> postmaster reject_rbl_client ips.backscatterer.org
> 
> well ... had to change the postfix dbm lookup to hash and do a postmap
> on the file ...
> but now this seems to work as it already rejected a few emails according
> to the mail log ...
> 
> more info can be found here ->
> 
> http://www.backscatterer.org
> 
> does anyone have any experience with that list?
> is this a good longterm solution?
> 
> best regards
> becki
> 

in your case it may be a short/quick/easy solution
but dont use this rbl on long time
it has nearly every big mailhost in it
you will loose legitime bounces
you may additional only use this rbl for your backscatterered reciept
and not for your whole server

-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

Re: email account bombarded with SPAM error bounces - what to do?

[Stan Hoeppner]

Kammen van, Marco, Springer SBM NL put forth on 7/9/2010 6:00 AM:

> Not sure if its related to your issue.
> But there is a big spam/virus attack going on, where messages look like
> NDR's but they aren't.
> Various big anti spam vendors are having serious issues stopping this.

Some of my trap addresses are being hit with this fake NDR spam but I've not
seen it make it into any inboxen (yet).  My A/S measures are strictly home
grown stuff plus a couple of Spamhaus dnsbl checks.  I guess I'm just lucky so
far. (knocks on wood)

-- 
Stan

Re: email account bombarded with SPAM error bounces - what to do?

[Administrator Beckspaced.com]

On 7/9/2010 14:40, Ram wrote:

On Fri, 2010-07-09 at 13:35 +0200, Administrator Beckspaced.com wrote:

On 7/9/2010 13:27, Robert Schetterer wrote:

Am 09.07.2010 12:51, schrieb Administrator Beckspaced.com:

   hello robert,

thanks a lot for your quick reply ...
actually it is not always the same IP or host sending the error bounces ...
the bounces are sent from hundred of different IP addresses ...

any more idea?


Usually you can do very little to prevent forging your domain and
sending spam.
Some months ago one client of ours too had the same issue, but the issue
is very temporary.
The short term solution , as someone suggested, will be to temporarily
defer all NDR's  with a sender check regex file like
/<>/  450 Try Later


( The RFC's say you cant do this .. but sometimes you must be
practical :-) )




> From my personal experience I found that if , for your regular mailing
you use some sender authentication mechanism like SPF then these NDR's
significantly reduce. For eg many servers reject forged messages based
on SPF checks so you dont get NDR's from them at least.

I guess , spammers ( the more intelligent ones ... I mean )  too would
be less inclined to forge a domain that uses sender authentication
Because that will reduce the deliverability of their spams

Thanks
Ram






hello again robert & ram

thanks again for your ideas ...

so i had another search in google about that backscatter topic and sort 
of found a nice, simple & also quick solution?


SAFE MODE with Postfix:

Edit /etc/postfix/main.cf:
smtpd_recipient_restrictions =
...
check_sender_access dbm:/etc/postfix/check_backscatterer
...
Create new file:/etc/postfix/check_backscatterer:
<> reject_rbl_client ips.backscatterer.org
postmaster reject_rbl_client ips.backscatterer.org

well ... had to change the postfix dbm lookup to hash and do a postmap 
on the file ...
but now this seems to work as it already rejected a few emails according 
to the mail log ...


more info can be found here ->

http://www.backscatterer.org

does anyone have any experience with that list?
is this a good longterm solution?

best regards
becki

--
Beckspaced.com - WebDesign, Hosting&  Solutions

CEO Becki Beckmann

Marienplatz 9
97353 Wiesentheid
Germany
Phone: 09383-425

P.O. Box 15
Thongsala
84280 Koh Phangan
Suratthani / Thailand
Phone: 077-377 733
Mobile: 087-2828826

--
Optimism is only a lack of information!
--

WebDesign&  Hosting - http://beckspaced.com - Are You Beckspaced?
Phangan Independent News - http://kohphangannews.org - The Awful Truth!

Re: Problem with tcp_table server

[Philipp Leusmann]

Am 09.07.2010 um 16:02 schrieb Wietse Venema:

> Philipp Leusmann:
>> warning: restriction `User' after `defer' is ignored
>> 
>> when I return something like
>> 
>> 200 DEFER User is over quota
>> 
>> I guess there is some special string expected after DEFER ? 
> 
> Wietse:
>> No. When the first word is "defer" or "DEFER" etc., then the rest
>> of the text sent to the client.
>> 
>> Can you show verbose logging of tcp_table when it returns this
>> result?
> 
> Philipp Leusmann{
>> what kind auf verbose logging are you talking about? "postmap -vv
>> -q" ? Or a more verbose logging for tcp_table in mail.log ? How
>> could I turn this on?
> 
> I need to see ONE example of verbose logging that shows 
> 
> (
> 
> tcp_table returning the string that is giving the above error, 
> 
> AND
> 
> the Postfix SMTP server processing that result
> 
> ).

Sorry, I still don't get, what you mean.

This is from my tcp_table-server logfile:

16:07:00,622 DEBUG QuotaCheckerServer:139 - Checking quota for user [silvia89]
16:07:00,624 DEBUG QuotaCheckerServer:170 - Quota status of user [silvia89] is 
: 102402KB used, -2KB free
16:07:00,624 DEBUG QuotaCheckerServer:193 - no space available for user 
[silvia89]
16:07:00,624 DEBUG QuotaCheckerServer:265 - Encoded Input String [DEFER User 
over quota] as [DEFER%20User%20over%20quota]
16:07:00,624 DEBUG QuotaCheckerServer:239 - The encoded reply is [200 
DEFER%20User%20over%20quota
]


and this is the corresponding mail.log:

Jul  9 16:07:00 s15277780 postfix/smtpd[18805]: warning: 186.9.10.210: hostname 
client-186-9-10-210.imovil.entelpcs.cl verification failed: Name or service not 
known
Jul  9 16:07:00 s15277780 postfix/smtpd[18805]: connect from 
unknown[186.9.10.210]
Jul  9 16:07:00 s15277780 postfix/smtpd[18815]: NOQUEUE: reject: RCPT from 
c-68-57-126-48.hsd1.va.comcast.net[68.57.126.48]: 450 4.3.2 : 
Recipient address rejected: Try again later; from= 
to= proto=ESMTP helo=
Jul  9 16:07:00 s15277780 postfix/smtpd[18815]: warning: restriction `User' 
after `defer' is ignored
Jul  9 16:07:00 s15277780 postfix/smtpd[18815]: disconnect from 
c-68-57-126-48.hsd1.va.comcast.net[68.57.126.48]


When I use postmap -vv -q "silvia89" tcp:localhost:1337 I get the following:

[...]
postmap: dict_open: calling tcp open routine
postmap: dict_open: tcp:localhost:1337
postmap: dict_tcp_lookup: key silvia89
postmap: trying... [127.0.0.1]
postmap: dict_tcp_lookup: send: get silvia89
postmap: dict_tcp_lookup: recv: 200 DEFER%20User%20over%20quota
postmap: dict_tcp_lookup: found: DEFER User over quota
DEFER User over quota


Hope this helps.

Philipp

Re: SASL Authentication per recipient domain

[David Jacobson]

From: "David Jacobson"
To:
postfix-users@postfix.orgSent: Friday, July 9, 2010 3:54:16
PMSubject: Re: SASL Authentication per recipient
domainFrom: "Sahil Tandon"
To:
postfix-users@postfix.orgSent: Friday, July 9, 2010 2:03:23
PMSubject: Re: SASL Authentication per recipient
domainOn Fri, 2010-07-09 at 12:20:12 +0200, David Jacobson
wrote:> I appreciate your response, however if you read my
original message> you will notice that we have had a look at all
support> smtp_sasl_password_maps options and it only allows for the
following> scenario according to the docs: > > 1) use
SMTP auth for _destination_ mail server > 2) use SMTP auth PER
_email address_ to destination mail server > > It does not
allow for SMTP auth per _sending domain_ > > Option 2 will
give desired results but is a nightmare to manage> individual email
addresses in the file, we just want to say> *...@sendingdomain.com
uses
auth. Have you explored PCRE to match *...@example.org on the LHS
ofsmtp_sasl_password_maps?-- Sahil Tandon
Hi Sahil,We tried PCRE matches to
no avail.  Based on your request we tried to change sasl_passwd
lookup
from hash to pcre (I'm no postfix guy, so have no idea if this should work
or not, but postfix restart didn't
complain)smtp_sasl_password_maps =
pcre:/opt/zimbra/postfix/conf/sasl_passwdThen in sasl_passwd tried
various combinations
including:/@domain\.com$/ 
username:passwordAnd it did not work, please advise what you
mean?  It just seems like SASL doesn't support
PCRE.Thanks!Hi There,Just for the sake of
clarification we've found what we're looking for, PCRE was not
required.We simply made smtp_sender_dependent_authentication = yes
then sasl_passwd could accept @domain.com - took us now 2 days to figure
this one out.Thanks for everyones assistance
anyway.



       


David Jacobson


Technical Director


Tel:
011 262 3632


Fax:
086 637 8868


Cell:
083 235 0760


Email:
dav...@synaq.com


Web:
www.synaq.com


Sandhaven Office Park, Pongola CrescentEastgate
Ext 17 Sandton



 



       


David Jacobson


Technical Director


Tel:
011 262 3632


Fax:
086 637 8868


Cell:
083 235 0760


Email:
dav...@synaq.com


Web:
www.synaq.com


Sandhaven Office Park, Pongola CrescentEastgate Ext 17 Sandton

Re: Error between two postfix "Command not recognized", RCPT is cut in two words

[Victor Duchovni]

On Fri, Jul 09, 2010 at 03:58:12PM +0200, poindessous...@foncia.fr wrote:

> ... a special filter which protects "smtp server". 
> 
> Do you think I should ask to disable it ?

Yes, always. The SMTP inspection feature notoriously does more harm than good.

-- 
Viktor.

Re: Error between two postfix "Command not recognized", RCPT is cut in two words

[Ralf Hildebrandt]

* poindessous...@foncia.fr :
> Yes, I think this is a cisco asa 5550, with a special filter which protects 
> "smtp server". 
> 
> Do you think I should ask to disable it ?

Yes. It causes nothing but grief :)

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: Problem with tcp_table server

[Wietse Venema]

Philipp Leusmann:
> warning: restriction `User' after `defer' is ignored
> 
> when I return something like
> 
> 200 DEFER User is over quota
> 
> I guess there is some special string expected after DEFER ? 

Wietse:
> No. When the first word is "defer" or "DEFER" etc., then the rest
> of the text sent to the client.
> 
> Can you show verbose logging of tcp_table when it returns this
> result?

Philipp Leusmann{
> what kind auf verbose logging are you talking about? "postmap -vv
> -q" ? Or a more verbose logging for tcp_table in mail.log ? How
> could I turn this on?

I need to see ONE example of verbose logging that shows 

(

tcp_table returning the string that is giving the above error, 

AND

the Postfix SMTP server processing that result

).

Wietse

Re: Error between two postfix "Command not recognized", RCPT is cut in two words

[poindessous537]

Yes, I think this is a cisco asa 5550, with a special filter which protects 
"smtp server". 

Do you think I should ask to disable it ?

Thanks. 

Le 9 juil. 2010 à 15:46, Ralf Hildebrandt  a écrit 
:

> * Thomas POINDESSOUS :
>> 
>> Hi, 
>> 
>> 
>> I have a problem between one of my postfix and a zimbra server (postfix 
>> server). 
>> 
>> 
>> sometime (one mail every three days), I got this error : 
>> 502 5.5.2 Error: command not recognized (in reply to RCPT TO command) 
>> 
>> 
>> I did a tcpdump to understand why I got this error and I found that one of 
>> the "RCPT TO:" command is cut in two packets. 
>> First packet finished by "RC" and second packet began by "PT TO:". And the 
>> server doesn't understand this command. 
> 
> Is there a firewall between the two?
> 
> -- 
> Ralf Hildebrandt
>  Gesch��ftsbereich IT | Abteilung Netzwerk
>  Charit�� - Universit��tsmedizin Berlin
>  Campus Benjamin Franklin
>  Hindenburgdamm 30 | D-12203 Berlin
>  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
>  ralf.hildebra...@charite.de | http://www.charite.de
>

Re: Error between two postfix "Command not recognized", RCPT is cut in two words

[Wietse Venema]

Thomas POINDESSOUS:
> 
> Hi, 
> 
> I have a problem between one of my postfix and a zimbra server (postfix 
> server). 
> 
> sometime (one mail every three days), I got this error : 
> 502 5.5.2 Error: command not recognized (in reply to RCPT TO command) 
> 
> I did a tcpdump to understand why I got this error and I found
> that one of the "RCPT TO:" command is cut in two packets.

This often happens with "firewall" products that inspect the TCP
stream. In particular, CISCO has a reputation of breaking SMTP by
mis-handling commands, including commands that sit on a packet
boundary.

If there is a CISCO firewall in the path, issue the proper commands
to disable SMTP inspection (whatever they call it today).

You can also selectively disable ESMTP command pipelining. See:

http://www.postfix.org/postconf.5.html#smtp_discard_ehlo_keywords
http://www.postfix.org/postconf.5.html#smtp_discard_ehlo_keyword_address_maps

The keyword in question is "pipelining".

Using this will reduce mail delivery performance, so you may not want to
turn it on for all mail.

Wietse

Re: SASL Authentication per recipient domain

[David Jacobson]

From: "Sahil Tandon"
To:
postfix-users@postfix.orgSent: Friday, July 9, 2010 2:03:23
PMSubject: Re: SASL Authentication per recipient
domainOn Fri, 2010-07-09 at 12:20:12 +0200, David Jacobson
wrote:> I appreciate your response, however if you read my
original message> you will notice that we have had a look at all
support> smtp_sasl_password_maps options and it only allows for the
following> scenario according to the docs: > > 1) use
SMTP auth for _destination_ mail server > 2) use SMTP auth PER
_email address_ to destination mail server > > It does not
allow for SMTP auth per _sending domain_ > > Option 2 will
give desired results but is a nightmare to manage> individual email
addresses in the file, we just want to say> *...@sendingdomain.com uses
auth. Have you explored PCRE to match *...@example.org on the LHS
ofsmtp_sasl_password_maps?-- Sahil Tandon
Hi Sahil,We tried PCRE matches to
no avail.  Based on your request we tried to change sasl_passwd lookup
from hash to pcre (I'm no postfix guy, so have no idea if this should work
or not, but postfix restart didn't
complain)smtp_sasl_password_maps =
pcre:/opt/zimbra/postfix/conf/sasl_passwdThen in sasl_passwd tried
various combinations
including:/@domain\.com$/ 
username:passwordAnd it did not work, please advise what you
mean?  It just seems like SASL doesn't support
PCRE.Thanks! 



       


David Jacobson


Technical Director


Tel:
011 262 3632


Fax:
086 637 8868


Cell:
083 235 0760


Email:
dav...@synaq.com


Web:
www.synaq.com


Sandhaven Office Park, Pongola CrescentEastgate Ext 17 Sandton

Re: Problem with tcp_table server

[Philipp Leusmann]

Hi Wietse,

what kind auf verbose logging are you talking about? "postmap -vv -q" ? Or a 
more verbose logging for tcp_table in mail.log ? How could I turn this on?

Philipp
Am 09.07.2010 um 15:45 schrieb Wietse Venema:

> Philipp Leusmann:
>> warning: restriction `User' after `defer' is ignored
>> 
>> when I return something like
>> 
>> 200 DEFER User is over quota
>> 
>> I guess there is some special string expected after DEFER ? 
> 
> No. When the first word is "defer" or "DEFER" etc., then the rest
> of the text sent to the client.
> 
> Can you show verbose logging of tcp_table when it returns this
> result?
> 
>   Wietse

Re: asking ARP for an internal IP 169.254.140.241

[Stéphane MERLE]

Hi,

Le 09/07/2010 15:21, Victor Duchovni a écrit :

On Fri, Jul 09, 2010 at 01:47:40PM +0200, St?phane MERLE wrote:

   

Hi,

My ISP (ovh) is complaining about my postfix servers doing wrong ARP
demand, do you have any idea of what can cause this in my postfix
configuration ?

188.165.55.92 : is one of the server ip (ip failover)

Thu Jul 8 02:03:32 2010 : arp who-has 169.254.140.241 tell 188.165.55.92
 

This IP address is a link-local IP address:

 http://tools.ietf.org/html/rfc3927

these support zero-configuration local networking, ...

   

19:43:20.840082 arp reply 169.254.140.241 is-at 00:24:c3:84:04:00
 

Your ISP or router is proxy-arping for this IP, it should not. Link-local
addresses should be exempt (if possible).

   

19:43:20.840087 IP ovh63.bpreducer.com.59549>  169.254.140.241.smtp: S
1213354010:1213354010(0) win 5840
 

Why are are sending email to this IP address? Any Postfix logs that
indicate attempts to connect to this relay?

   

if you need the postfix conf files, I will send it in.
 

Mostly just logs that show the life-cycle of a message (all log entries
for its queue-id) in which deliveries to this IP address were attempted
and failed.

   


Thank you, because of your post, I checked in the postfix logs and found 
: aha...@elv.enic.fr


Jul  9 01:18:33 ovh63 postfix/smtp[30687]: connect to 
elv.enic.fr[169.254.140.241]:25: Connection timed out
Jul  9 01:18:33 ovh63 postfix/smtp[30687]: 138C92011CE6: 
to=, relay=none, delay=45185, delays=45095/0/90/0, 
dsn=4.4.1, status=deferred (connect to elv.enic.fr[169.254.140.241]:25: 
Connection timed out)


I first clean that domain from the database and then check my bot 
cleanner which missed this.


Thank you !!

Stéphane

Re: Error between two postfix "Command not recognized", RCPT is cut in two words

[Ralf Hildebrandt]

* Thomas POINDESSOUS :
> 
> Hi, 
> 
> 
> I have a problem between one of my postfix and a zimbra server (postfix 
> server). 
> 
> 
> sometime (one mail every three days), I got this error : 
> 502 5.5.2 Error: command not recognized (in reply to RCPT TO command) 
> 
> 
> I did a tcpdump to understand why I got this error and I found that one of 
> the "RCPT TO:" command is cut in two packets. 
> First packet finished by "RC" and second packet began by "PT TO:". And the 
> server doesn't understand this command. 

Is there a firewall between the two?

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: Problem with tcp_table server

[Wietse Venema]

Philipp Leusmann:
> warning: restriction `User' after `defer' is ignored
> 
> when I return something like
> 
> 200 DEFER User is over quota
> 
> I guess there is some special string expected after DEFER ? 

No. When the first word is "defer" or "DEFER" etc., then the rest
of the text sent to the client.

Can you show verbose logging of tcp_table when it returns this
result?

Wietse

Error between two postfix "Command not recognized", RCPT is cut in two words

[Thomas POINDESSOUS]

Hi, 


I have a problem between one of my postfix and a zimbra server (postfix 
server). 


sometime (one mail every three days), I got this error : 
502 5.5.2 Error: command not recognized (in reply to RCPT TO command) 


I did a tcpdump to understand why I got this error and I found that one of the 
"RCPT TO:" command is cut in two packets. 
First packet finished by "RC" and second packet began by "PT TO:". And the 
server doesn't understand this command. 


Here is a part of the tcpdump (ascii is obfuscated but hexdump is not) : 



0x0aa0: 6961 2e66 720d 0a52 4350 5420 544f 3a3c ia.fr..RCPT.TO:< 
0x0ab0: 6e61 7335 3135 4066 6f6e 6369 612e 7072 nas...@.pr 
0x0ac0: 6f3e 204f 5243 5054 3d72 6663 3832 323b o>.ORCPT=rfc822; 
0x0ad0: 6e61 7335 3135 4066 6f6e 6369 612e 6672 nas...@.fr 
0x0ae0: 0d0a 5243 ..RC 
09:51:39.813192 IP xx.39555 > xx.smtp: P 2756:3667(911) ack 220 win 54 
 
0x: 4500 03c3 43cc 4000 4006 6241 ac10 3706 e.@.@.bA..7. 
0x0010: ac10 0201 9a83 0019 7b0e 14cf e256 415b {VA[ 
0x0020: 8018 0036 8ff0  0101 080a 2006 49ce ...6..I. 
0x0030: 81ac 95e4 5054 2054 4f3a 3c6e 6f65 6c6c PT.TO:.ORCPT=rfc82 


How can I solve this problem ? 


Thanks in advance. 



-- 
Thomas Poindessous 

Re: asking ARP for an internal IP 169.254.140.241

[Victor Duchovni]

On Fri, Jul 09, 2010 at 01:47:40PM +0200, St?phane MERLE wrote:

> Hi,
>
> My ISP (ovh) is complaining about my postfix servers doing wrong ARP 
> demand, do you have any idea of what can cause this in my postfix 
> configuration ?
>
> 188.165.55.92 : is one of the server ip (ip failover)
>
> Thu Jul 8 02:03:32 2010 : arp who-has 169.254.140.241 tell 188.165.55.92

This IP address is a link-local IP address:

http://tools.ietf.org/html/rfc3927

these support zero-configuration local networking, ...

> 19:43:20.840082 arp reply 169.254.140.241 is-at 00:24:c3:84:04:00

Your ISP or router is proxy-arping for this IP, it should not. Link-local
addresses should be exempt (if possible).

> 19:43:20.840087 IP ovh63.bpreducer.com.59549 > 169.254.140.241.smtp: S 
> 1213354010:1213354010(0) win 5840  0,nop,wscale 6>

Why are are sending email to this IP address? Any Postfix logs that
indicate attempts to connect to this relay?

> if you need the postfix conf files, I will send it in.

Mostly just logs that show the life-cycle of a message (all log entries
for its queue-id) in which deliveries to this IP address were attempted
and failed.

-- 
Viktor.

Re: asking ARP for an internal IP 169.254.140.241

[Wietse Venema]

St?phane MERLE:
> My ISP (ovh) is complaining about my postfix servers doing wrong ARP 
> demand, do you have any idea of what can cause this in my postfix 
> configuration ?

Postfix does not send ARP requests.  Instead, look at your kernel's
network configuration.

Wietse

Re: email account bombarded with SPAM error bounces - what to do?

[Ram]

On Fri, 2010-07-09 at 13:35 +0200, Administrator Beckspaced.com wrote:
> 
> On 7/9/2010 13:27, Robert Schetterer wrote:
> > Am 09.07.2010 12:51, schrieb Administrator Beckspaced.com:
> >>   hello robert,
> >>
> >> thanks a lot for your quick reply ...
> >> actually it is not always the same IP or host sending the error bounces ...
> >> the bounces are sent from hundred of different IP addresses ...
> >>
> >> any more idea?
> >>

Usually you can do very little to prevent forging your domain and
sending spam. 
Some months ago one client of ours too had the same issue, but the issue
is very temporary. 
The short term solution , as someone suggested, will be to temporarily
defer all NDR's  with a sender check regex file like
/<>/450 Try Later


( The RFC's say you cant do this .. but sometimes you must be
practical :-) ) 




>From my personal experience I found that if , for your regular mailing
you use some sender authentication mechanism like SPF then these NDR's
significantly reduce. For eg many servers reject forged messages based
on SPF checks so you dont get NDR's from them at least. 

I guess , spammers ( the more intelligent ones ... I mean )  too would
be less inclined to forge a domain that uses sender authentication 
Because that will reduce the deliverability of their spams

Thanks
Ram

Re: SASL Authentication per recipient domain

[Sahil Tandon]

On Fri, 2010-07-09 at 12:20:12 +0200, David Jacobson wrote:

> I appreciate your response, however if you read my original message
> you will notice that we have had a look at all support
> smtp_sasl_password_maps options and it only allows for the following
> scenario according to the docs: 
> 
> 1) use SMTP auth for _destination_ mail server 
> 2) use SMTP auth PER _email address_ to destination mail server 
> 
> It does not allow for SMTP auth per _sending domain_ 
> 
> Option 2 will give desired results but is a nightmare to manage
> individual email addresses in the file, we just want to say
> *...@sendingdomain.com uses auth. 

Have you explored PCRE to match *...@example.org on the LHS of
smtp_sasl_password_maps?

-- 
Sahil Tandon 

Re: email account bombarded with SPAM error bounces - what to do?

[Robert Schetterer]

Am 09.07.2010 13:35, schrieb Administrator Beckspaced.com:
> 
> 
> On 7/9/2010 13:27, Robert Schetterer wrote:
>> Am 09.07.2010 12:51, schrieb Administrator Beckspaced.com:
>>>   hello robert,
>>>
>>> thanks a lot for your quick reply ...
>>> actually it is not always the same IP or host sending the error
>>> bounces ...
>>> the bounces are sent from hundred of different IP addresses ...
>>>
>>> any more idea?
>>>
>>> thanks for your help&  fun
>>> becki
>>>
>>>
>>> below some logs you requested ... change the real email account to
>>> spamu...@domain.com  ->
>>>
>>> Jul  8 12:20:27 gehirn postfix/smtpd[19857]: NOQUEUE: reject: RCPT from
>>> crusty.hosts.net.nz[210.48.108.195]: 554 5.7.1:
>>> Recipient address rejected: Access denied; from=<>
>>> to=  proto=SMTP helo=
>>> Jul  8 12:22:08 gehirn postfix/smtpd[19859]: NOQUEUE: reject: RCPT from
>>> mailx.nlabs.de[92.79.50.220]: 554 5.7.1: Recipient
>>> address rejected: Access denied; from=<>  to=
>>> proto=SMTP helo=
>>> Jul  8 12:22:48 gehirn postfix/smtpd[19854]: warning: 222.254.188.229:
>>> address not listed for hostname localhost
>>> Jul  8 12:23:28 gehirn postfix/smtpd[18358]: NOQUEUE: reject: RCPT from
>>> port-87-234-220-121.static.qsc.de[87.234.220.121]: 554 5.7.1
>>> : Recipient address rejected: Access denied;
>>> from=<>  to=  proto=SMTP helo=
>>> Jul  8 12:26:22 gehirn postfix/smtpd[19854]: setting up TLS connection
>>> from mail.aydin.edu.tr[212.174.169.8]
>>> Jul  8 12:26:22 gehirn postfix/smtpd[19854]: TLS connection established
>>> from mail.aydin.edu.tr[212.174.169.8]: TLSv1 with cipher
>>> DHE-RSA-AES256-SHA (256/256 bits)
>>> Jul  8 12:26:22 gehirn postfix/smtpd[19854]: NOQUEUE: reject: RCPT from
>>> mail.aydin.edu.tr[212.174.169.8]: 554 5.7.1:
>>> Recipient address rejected: Access denied; from=<>
>>> to=  proto=ESMTP helo=
>>> Jul  8 12:27:57 gehirn postfix/smtpd[19850]: NOQUEUE: reject: RCPT from
>>> svhqgtw02.ethiopianairlines.com[213.55.83.14]: 554 5.7.1
>>> : Recipient address rejected: Access denied;
>>> from=<>  to=  proto=SMTP
>>> helo=
>>> Jul  8 12:27:58 gehirn postfix/smtpd[18899]: NOQUEUE: reject: RCPT from
>>> svhqgtw02.ethiopianairlines.com[213.55.83.14]: 554 5.7.1
>>> : Recipient address rejected: Access denied;
>>> from=<>  to=  proto=SMTP
>>> helo=
>>> Jul  8 12:28:27 gehirn postfix/smtpd[18358]: A565C150A7D:
>>> client=relay02.is.co.za[196.35.6.70]
>>> Jul  8 12:28:31 gehirn postfix/smtpd[20525]: 78BEC150A7F:
>>> client=localhost[127.0.0.1]
>>> Jul  8 12:28:35 gehirn postfix/smtpd[18899]: NOQUEUE: reject: RCPT from
>>> mx2.lost-oasis.net[80.67.160.52]: 554 5.7.1:
>>> Recipient address rejected: Access denied; from=<>
>>> to=  proto=SMTP helo=
>>> Jul  8 12:29:23 gehirn postfix/smtpd[18899]: NOQUEUE: reject: RCPT from
>>> defer114.ocn.ad.jp[122.28.15.169]: 554 5.7.1:
>>> Recipient address rejected: Access denied; from=<>
>>> to=  proto=ESMTP helo=
>>> Jul  8 12:29:49 gehirn postfix/smtpd[19850]: E4B86150AE9:
>>> client=unknown[184.154.34.69]
>>> Jul  8 12:29:56 gehirn postfix/smtpd[20525]: 8B7F4150AF6:
>>> client=localhost[127.0.0.1]
>>> Jul  8 12:30:43 gehirn postfix/smtpd[19854]: NOQUEUE: reject: RCPT from
>>> post.vrus.de[85.182.133.62]: 554 5.7.1: Recipient
>>> address rejected: Access denied; from=<>
>>>
>>> On 7/9/2010 12:42, Robert Schetterer wrote:
 Am 09.07.2010 12:35, schrieb Administrator Beckspaced.com:
>hello there,
>
> i'm running a postfix 2.4.6 on a opensuse box.
> postfix has amawis-new with spamassasin installed ...
>
> since a few weeks one of my email accounts gets bombarded with
> thousands
> of SPAM mailer daemon error bounces.
> could not deliver message ... bla bla bla ...
>
> it's getting really annoying as there are thousands of error bounces
> coming in every single day.
>
> looks like that the email address ended up on some SPAM mailing lists
> ... adn now the mailbox receives all this error message junk
>
> so ... what's the best strategy to get rid off this problem?
>
> already had a quick look ... and the error bounces come in with an
> empty
> <>   from address ...
> which seems to be standard for this ... and by default postfix doesn't
> block empty from addresses<>
>
> so what's the best thing to do to get rid of those thousand error
> email
> bounces?
>
> thing is that the customer urgently needs this email account as it is
> signed up at many service providers.
>
> could i do a header check for this single email account and reject the
> empty from address<>   for that email account only?
> what are my options? what's the smartest thing to do??
>
> thanks a lot for your help&   service
>
> with best regards
> becki
>
if it always the same host sending backscatter
 simple block the host by access list and/or firewall

 lets see some logs, there are many way to deal with backscatter

>> please dont

Re: asking ARP for an internal IP 169.254.140.241

[Ralf Hildebrandt]

* "Stéphane MERLE" :
> Hi,
> 
> My ISP (ovh) is complaining about my postfix servers doing wrong ARP
> demand, do you have any idea of what can cause this in my postfix
> configuration ?

I'd think that's more because of the OS or failover. Postfix is
several layers above that.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

asking ARP for an internal IP 169.254.140.241

[Stéphane MERLE]

Hi,

My ISP (ovh) is complaining about my postfix servers doing wrong ARP 
demand, do you have any idea of what can cause this in my postfix 
configuration ?


188.165.55.92 : is one of the server ip (ip failover)

Thu Jul 8 02:03:32 2010 : arp who-has 169.254.140.241 tell 188.165.55.92
Thu Jul 8 03:27:22 2010 : arp who-has 169.254.140.241 tell 188.165.55.92
Thu Jul 8 09:34:55 2010 : arp who-has 169.254.140.241 tell 188.165.55.92
Thu Jul 8 10:07:53 2010 : arp who-has 169.254.140.241 tell 188.165.55.92
Thu Jul 8 10:57:22 2010 : arp who-has 169.254.140.241 tell 188.165.55.92
Thu Jul 8 12:20:14 2010 : arp who-has 169.254.140.241 tell 188.165.55.92
Thu Jul 8 13:44:34 2010 : arp who-has 169.254.140.241 tell 188.165.55.92
Thu Jul 8 13:44:34 2010 : arp who-has 169.254.140.241 tell 188.165.55.92
Thu Jul 8 15:07:53 2010 : arp who-has 169.254.140.241 tell 188.165.55.92
Thu Jul 8 16:30:14 2010 : arp who-has 169.254.140.241 tell 188.165.55.92

extract from tcpdump :

19:43:20.837829 IP cdns.ovh.net.domain > ovh63.bpreducer.com.60276: 
49866 3/3/1 A 169.254.140.241,[|domain]

19:43:20.838443 arp who-has 169.254.140.241 tell ovh63.bpreducer.com
19:43:20.840082 arp reply 169.254.140.241 is-at 00:24:c3:84:04:00 (oui 
Unknown)
19:43:20.840087 IP ovh63.bpreducer.com.59549 > 169.254.140.241.smtp: S 
1213354010:1213354010(0) win 5840 0,nop,wscale 6>
19:43:29.834748 IP ovh63.bpreducer.com.59549 > 169.254.140.241.smtp: S 
1213354010:1213354010(0) win 5840 0,nop,wscale 6>
19:43:41.834247 IP ovh63.bpreducer.com.59549 > 169.254.140.241.smtp: S 
1213354010:1213354010(0) win 5840 0,nop,wscale 6>
21:06:28.352789 IP cdns.ovh.net.domain > ovh63.bpreducer.com.36382: 7517 
3/3/1 A 169.254.140.241,[|domain]

21:06:58.386416 arp who-has 169.254.140.241 tell ovh63.bpreducer.com
21:06:58.387888 arp reply 169.254.140.241 is-at 00:24:c3:84:04:00 (oui 
Unknown)
21:06:58.387899 IP ovh63.bpreducer.com.36937 > 169.254.140.241.smtp: S 
2588304519:2588304519(0) win 5840 0,nop,wscale 6>
21:07:01.382251 IP ovh63.bpreducer.com.36937 > 169.254.140.241.smtp: S 
2588304519:2588304519(0) win 5840 0,nop,wscale 6>
21:07:07.382750 IP ovh63.bpreducer.com.36937 > 169.254.140.241.smtp: S 
2588304519:2588304519(0) win 5840 0,nop,wscale 6>
21:07:19.382236 IP ovh63.bpreducer.com.36937 > 169.254.140.241.smtp: S 
2588304519:2588304519(0) win 5840 0,nop,wscale 6>


if you need the postfix conf files, I will send it in.

Thanks for any help 

Stéphane

Re: Problem with tcp_table server

[Philipp Leusmann]

Am 08.07.2010 um 20:55 schrieb Noel Jones:

> On 7/8/2010 12:13 PM, Philipp Leusmann wrote:
>> 
>> Am 08.07.2010 um 19:02 schrieb Philipp Leusmann:
>> 
>>> 
>>> Am 08.07.2010 um 18:23 schrieb Noel Jones:
>>> 
 On 7/8/2010 10:58 AM, Philipp Leusmann wrote:
> Hi all,
> 
> to stop backscattering I wrote a tcp_table server which checks quota 
> availability for incoming messages.
> I read   over and over again, 
> but still I am getting messages like
> 
> Jul  8 17:46:24 s15277780 postfix/smtpd[3325]: warning: read TCP map 
> reply from localhost:1337: unexpected EOF (Success)
> Jul  8 17:46:25 s15277780 postfix/smtpd[3325]: warning: 
> tcp:localhost:1337: table lookup problem
> 
> 
> in the logfile, when the server returns a 400 or 500 reply. For a 
> 200-reply it works ok and the mail is delivered.
> 
> For a 400-reply, my server generates the following (from my logfile):
> 
> The encoded reply is [400 User%20over%20quota
> ]
> 
> 
> The server sends everything between [ and ] . I think that should be ok. 
> Or isn't it?
> 
> 
> When I try a
> 
> postmap -vv -q "benny" tcp:localhost:1337
> 
> (benny is over quota)
> 
> the output ends with:
> 
> postmap: loaded dict_tcp_open = 7f50d057bd20
> postmap: dict_open: calling tcp open routine
> postmap: dict_open: tcp:localhost:1337
> postmap: dict_tcp_lookup: key benny
> postmap: trying... [127.0.0.1]
> postmap: dict_tcp_lookup: send: get benny
> postmap: dict_tcp_lookup: recv: 400 User%20over%20quota
> postmap: dict_tcp_lookup: soft error: 400 User%20over%20quota
> 
> For a user having available space, it looks like:
> 
> postmap: loaded dict_tcp_open = 7f30f5c76d20
> postmap: dict_open: calling tcp open routine
> postmap: dict_open: tcp:localhost:1337
> postmap: dict_tcp_lookup: key laus
> postmap: trying... [127.0.0.1]
> postmap: dict_tcp_lookup: send: get laus
> postmap: dict_tcp_lookup: recv: 200 OK
> postmap: dict_tcp_lookup: found: OK
> OK
> 
> 
> 
> Can anybody tell me, what is wrong?
> 
> And what does postfix return the the delivering client in my current 
> case? a 500 ?
> 
> Regards,
> Philipp
 
 The 200, 400, and 500 codes indicate the status of the lookup itself, and 
 do not indicate the result.
 
 200, the lookup found something, here it is:  (OK, DEFER, REJECT ... other 
 access(5) actions)
 400, the lookup table is broken, try later
 500, the key wasn't found
 
 In the case of an over-quota user, your table should return
 200 REJECT User over quota
 or DEFER if that's the action you want.
 
 This isn't documented explicitly in the README because tcp tables can be 
 used for purposes other than access maps.
 
 -- Noel Jones
>>> 
>>> Noel,
>>> 
>>> thanks for your advice. This really should be pointed out more explicitly 
>>> in the documentation.
>>> 
>>> As for 500, would it be a good practice to return 500, if the key, which in 
>>> this case is the email-adress is not known at all?
>>> 
>>> I also use a local_recipients_map, which already decides if a user exists 
>>> or not.
>>> So, which of the both is evaluated first? local_recipient_maps or 
>>> smtpd_recipient_restrictions ?
>>> 
>>> What would be the best practice for my case?
>>> 
>>> Regards,
>>> Philipp
> 
> I expect returning 500 for users under quota or non-existent users would be 
> appropriate.
> 
> Alternately, you could return "200 REJECT" for non-existent users, and "200 
> DUNNO" for under-quota users.
> 
> You probably don't want to use "200 OK" for under-quota users since that will 
> bypass any further antispam checks you might want to do.

Noel,

I guess at least one "under quota" should read "over quota", doesn't it? 

Also, is there any any reference documentation about the possible response 
string?
For example DUNNO would not be something, which I would try to use naturally. 
Also in my logfiles, I notice entries like 

warning: restriction `User' after `defer' is ignored

when I return something like

200 DEFER User is over quota

I guess there is some special string expected after DEFER ? 

Regards,
 Philipp

RE: email account bombarded with SPAM error bounces - what to do?

[Kammen van, Marco, Springer SBM NL]

>>-Original Message-
>>From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of wolfgang
>>Sent: Friday, July 09, 2010 1:11 PM
>>To: postfix-users@postfix.org
>>Subject: Re: email account bombarded with SPAM error bounces - what to
do?

>>In an older episode (Friday, 9. July 2010), Kammen van, Marco,
Springer 
>>SBM NL wrote:


> But there is a big spam/virus attack going on, where messages look
> like NDR's but they aren't.
> Various big anti spam vendors are having serious issues stopping
> this.

>Could you provide a URL where more details are available?

>Regards,

>wolfgang

Hi Wolfgang,

It's a restricted site for customers only but I can give you this:


July 05, 2010 @ 02:30 am PDT - We have received reports of new variants
of Delivery Notification messages with HTML files that redirects to
malware sites bypassing our filters. We are currently investigating the
issue with Antivirus vendors and will post an update as soon as
information becomes available.

July 03, 2010 @ 11:10 am PDT - We have released an update to resolve
this issue. The info of the update can be found in the Filter Status
Dashboard. We continue monitor the situation and release necessary
filter updates. 

July 03, 2010 @ 09:40 am PDT - We have received reports of new variants
of Delivery Notification messages with an HTML file bypassing our
filters. We are currently investigating the issue with Antivirus vendors
and will post an update as soon as information becomes available.

July 02, 2010 @ 08:31 pm PDT - Updated anti virus signatures are now
detecting the JS/Agent.ME variant. This has effectively resolved the
issue. We apologize for the inconvenience and thank you for your
patience and continued support.

July 02, 2010 @ 07:00pm PDT - We have received reports of Delivery
Notification messages with an HTML file bypassing our filters. We are
currently investigating the issue and will post an update as soon as
information becomes available.

And it seems as of today a new variant is out with a new subject and new
garbage in the body...
Gotta love those spam people! 

Re: email account bombarded with SPAM error bounces - what to do?

[Administrator Beckspaced.com]

On 7/9/2010 13:27, Robert Schetterer wrote:

Am 09.07.2010 12:51, schrieb Administrator Beckspaced.com:

  hello robert,

thanks a lot for your quick reply ...
actually it is not always the same IP or host sending the error bounces ...
the bounces are sent from hundred of different IP addresses ...

any more idea?

thanks for your help&  fun
becki


below some logs you requested ... change the real email account to
spamu...@domain.com  ->

Jul  8 12:20:27 gehirn postfix/smtpd[19857]: NOQUEUE: reject: RCPT from
crusty.hosts.net.nz[210.48.108.195]: 554 5.7.1:
Recipient address rejected: Access denied; from=<>
to=  proto=SMTP helo=
Jul  8 12:22:08 gehirn postfix/smtpd[19859]: NOQUEUE: reject: RCPT from
mailx.nlabs.de[92.79.50.220]: 554 5.7.1: Recipient
address rejected: Access denied; from=<>  to=
proto=SMTP helo=
Jul  8 12:22:48 gehirn postfix/smtpd[19854]: warning: 222.254.188.229:
address not listed for hostname localhost
Jul  8 12:23:28 gehirn postfix/smtpd[18358]: NOQUEUE: reject: RCPT from
port-87-234-220-121.static.qsc.de[87.234.220.121]: 554 5.7.1
: Recipient address rejected: Access denied;
from=<>  to=  proto=SMTP helo=
Jul  8 12:26:22 gehirn postfix/smtpd[19854]: setting up TLS connection
from mail.aydin.edu.tr[212.174.169.8]
Jul  8 12:26:22 gehirn postfix/smtpd[19854]: TLS connection established
from mail.aydin.edu.tr[212.174.169.8]: TLSv1 with cipher
DHE-RSA-AES256-SHA (256/256 bits)
Jul  8 12:26:22 gehirn postfix/smtpd[19854]: NOQUEUE: reject: RCPT from
mail.aydin.edu.tr[212.174.169.8]: 554 5.7.1:
Recipient address rejected: Access denied; from=<>
to=  proto=ESMTP helo=
Jul  8 12:27:57 gehirn postfix/smtpd[19850]: NOQUEUE: reject: RCPT from
svhqgtw02.ethiopianairlines.com[213.55.83.14]: 554 5.7.1
: Recipient address rejected: Access denied;
from=<>  to=  proto=SMTP
helo=
Jul  8 12:27:58 gehirn postfix/smtpd[18899]: NOQUEUE: reject: RCPT from
svhqgtw02.ethiopianairlines.com[213.55.83.14]: 554 5.7.1
: Recipient address rejected: Access denied;
from=<>  to=  proto=SMTP
helo=
Jul  8 12:28:27 gehirn postfix/smtpd[18358]: A565C150A7D:
client=relay02.is.co.za[196.35.6.70]
Jul  8 12:28:31 gehirn postfix/smtpd[20525]: 78BEC150A7F:
client=localhost[127.0.0.1]
Jul  8 12:28:35 gehirn postfix/smtpd[18899]: NOQUEUE: reject: RCPT from
mx2.lost-oasis.net[80.67.160.52]: 554 5.7.1:
Recipient address rejected: Access denied; from=<>
to=  proto=SMTP helo=
Jul  8 12:29:23 gehirn postfix/smtpd[18899]: NOQUEUE: reject: RCPT from
defer114.ocn.ad.jp[122.28.15.169]: 554 5.7.1:
Recipient address rejected: Access denied; from=<>
to=  proto=ESMTP helo=
Jul  8 12:29:49 gehirn postfix/smtpd[19850]: E4B86150AE9:
client=unknown[184.154.34.69]
Jul  8 12:29:56 gehirn postfix/smtpd[20525]: 8B7F4150AF6:
client=localhost[127.0.0.1]
Jul  8 12:30:43 gehirn postfix/smtpd[19854]: NOQUEUE: reject: RCPT from
post.vrus.de[85.182.133.62]: 554 5.7.1: Recipient
address rejected: Access denied; from=<>

On 7/9/2010 12:42, Robert Schetterer wrote:

Am 09.07.2010 12:35, schrieb Administrator Beckspaced.com:

   hello there,

i'm running a postfix 2.4.6 on a opensuse box.
postfix has amawis-new with spamassasin installed ...

since a few weeks one of my email accounts gets bombarded with thousands
of SPAM mailer daemon error bounces.
could not deliver message ... bla bla bla ...

it's getting really annoying as there are thousands of error bounces
coming in every single day.

looks like that the email address ended up on some SPAM mailing lists
... adn now the mailbox receives all this error message junk

so ... what's the best strategy to get rid off this problem?

already had a quick look ... and the error bounces come in with an empty
<>   from address ...
which seems to be standard for this ... and by default postfix doesn't
block empty from addresses<>

so what's the best thing to do to get rid of those thousand error email
bounces?

thing is that the customer urgently needs this email account as it is
signed up at many service providers.

could i do a header check for this single email account and reject the
empty from address<>   for that email account only?
what are my options? what's the smartest thing to do??

thanks a lot for your help&   service

with best regards
becki


   if it always the same host sending backscatter
simple block the host by access list and/or firewall

lets see some logs, there are many way to deal with backscatter


please dont top post,

do they have  always the same body ?
or equal bodies which might can be matched
with some body_checks

something like
  main.cf
body_checks = pcre:/etc/postfix/body_checks

/sunstarcasino\.net/ REJECT backscatter



no ... they don't always have equal message bodies ...
it's not always the same host ... it's thousands of different hosts and 
IP addresses ..


but of course some message body could be the same ... e.g.

i'm sorry to inform you that your message could not get delivered ... 
bla .. bla ... bla ...


still not sure how to fix this ... any more ideas?

best regard

Re: email account bombarded with SPAM error bounces - what to do?

[Robert Schetterer]

Am 09.07.2010 13:00, schrieb Kammen van, Marco, Springer SBM NL:
>> From: owner-postfix-us...@postfix.org
> [mailto:owner-postfix-us...@postfix.org] On Behalf Of Administrator
> Beckspaced.com
>> Sent: Friday, July 09, 2010 12:52 PM
>> To: Robert Schetterer
>> Cc: postfix-users@postfix.org
>> Subject: Re: email account bombarded with SPAM error bounces - what to
> do?
>>
>  > hello robert,
> 
>> thanks a lot for your quick reply ...
>> actually it is not always the same IP or host sending the error bounces
> ...
>> the bounces are sent from hundred of different IP addresses ...
> 
>> any more idea?
> 
>> thanks for your help & fun
>> becki
> 
> Hi Robert,
> 
> Not sure if its related to your issue.
> But there is a big spam/virus attack going on, where messages look like
> NDR's but they aren't.
> Various big anti spam vendors are having serious issues stopping this.
> 
> Marco van Kammen
> Springer Science+Business Media
> System Manager & Postmaster   
> van Godewijckstraat 30 | 3311 GX
> Office Number: 05E21 
> Dordrecht 
> The Netherlands  
> www.springer.com

not my issue
i dont see rising backscatter recent
but i have always high rates

-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

Re: email account bombarded with SPAM error bounces - what to do?

[Robert Schetterer]

Am 09.07.2010 12:51, schrieb Administrator Beckspaced.com:
>  hello robert,
> 
> thanks a lot for your quick reply ...
> actually it is not always the same IP or host sending the error bounces ...
> the bounces are sent from hundred of different IP addresses ...
> 
> any more idea?
> 
> thanks for your help & fun
> becki
> 
> 
> below some logs you requested ... change the real email account to
> spamu...@domain.com  ->
> 
> Jul  8 12:20:27 gehirn postfix/smtpd[19857]: NOQUEUE: reject: RCPT from
> crusty.hosts.net.nz[210.48.108.195]: 554 5.7.1 :
> Recipient address rejected: Access denied; from=<>
> to= proto=SMTP helo=
> Jul  8 12:22:08 gehirn postfix/smtpd[19859]: NOQUEUE: reject: RCPT from
> mailx.nlabs.de[92.79.50.220]: 554 5.7.1 : Recipient
> address rejected: Access denied; from=<> to=
> proto=SMTP helo=
> Jul  8 12:22:48 gehirn postfix/smtpd[19854]: warning: 222.254.188.229:
> address not listed for hostname localhost
> Jul  8 12:23:28 gehirn postfix/smtpd[18358]: NOQUEUE: reject: RCPT from
> port-87-234-220-121.static.qsc.de[87.234.220.121]: 554 5.7.1
> : Recipient address rejected: Access denied;
> from=<> to= proto=SMTP helo=
> Jul  8 12:26:22 gehirn postfix/smtpd[19854]: setting up TLS connection
> from mail.aydin.edu.tr[212.174.169.8]
> Jul  8 12:26:22 gehirn postfix/smtpd[19854]: TLS connection established
> from mail.aydin.edu.tr[212.174.169.8]: TLSv1 with cipher
> DHE-RSA-AES256-SHA (256/256 bits)
> Jul  8 12:26:22 gehirn postfix/smtpd[19854]: NOQUEUE: reject: RCPT from
> mail.aydin.edu.tr[212.174.169.8]: 554 5.7.1 :
> Recipient address rejected: Access denied; from=<>
> to= proto=ESMTP helo=
> Jul  8 12:27:57 gehirn postfix/smtpd[19850]: NOQUEUE: reject: RCPT from
> svhqgtw02.ethiopianairlines.com[213.55.83.14]: 554 5.7.1
> : Recipient address rejected: Access denied;
> from=<> to= proto=SMTP
> helo=
> Jul  8 12:27:58 gehirn postfix/smtpd[18899]: NOQUEUE: reject: RCPT from
> svhqgtw02.ethiopianairlines.com[213.55.83.14]: 554 5.7.1
> : Recipient address rejected: Access denied;
> from=<> to= proto=SMTP
> helo=
> Jul  8 12:28:27 gehirn postfix/smtpd[18358]: A565C150A7D:
> client=relay02.is.co.za[196.35.6.70]
> Jul  8 12:28:31 gehirn postfix/smtpd[20525]: 78BEC150A7F:
> client=localhost[127.0.0.1]
> Jul  8 12:28:35 gehirn postfix/smtpd[18899]: NOQUEUE: reject: RCPT from
> mx2.lost-oasis.net[80.67.160.52]: 554 5.7.1 :
> Recipient address rejected: Access denied; from=<>
> to= proto=SMTP helo=
> Jul  8 12:29:23 gehirn postfix/smtpd[18899]: NOQUEUE: reject: RCPT from
> defer114.ocn.ad.jp[122.28.15.169]: 554 5.7.1 :
> Recipient address rejected: Access denied; from=<>
> to= proto=ESMTP helo=
> Jul  8 12:29:49 gehirn postfix/smtpd[19850]: E4B86150AE9:
> client=unknown[184.154.34.69]
> Jul  8 12:29:56 gehirn postfix/smtpd[20525]: 8B7F4150AF6:
> client=localhost[127.0.0.1]
> Jul  8 12:30:43 gehirn postfix/smtpd[19854]: NOQUEUE: reject: RCPT from
> post.vrus.de[85.182.133.62]: 554 5.7.1 : Recipient
> address rejected: Access denied; from=<>
> 
> On 7/9/2010 12:42, Robert Schetterer wrote:
>> Am 09.07.2010 12:35, schrieb Administrator Beckspaced.com:
>>>   hello there,
>>>
>>> i'm running a postfix 2.4.6 on a opensuse box.
>>> postfix has amawis-new with spamassasin installed ...
>>>
>>> since a few weeks one of my email accounts gets bombarded with thousands
>>> of SPAM mailer daemon error bounces.
>>> could not deliver message ... bla bla bla ...
>>>
>>> it's getting really annoying as there are thousands of error bounces
>>> coming in every single day.
>>>
>>> looks like that the email address ended up on some SPAM mailing lists
>>> ... adn now the mailbox receives all this error message junk
>>>
>>> so ... what's the best strategy to get rid off this problem?
>>>
>>> already had a quick look ... and the error bounces come in with an empty
>>> <>  from address ...
>>> which seems to be standard for this ... and by default postfix doesn't
>>> block empty from addresses<>
>>>
>>> so what's the best thing to do to get rid of those thousand error email
>>> bounces?
>>>
>>> thing is that the customer urgently needs this email account as it is
>>> signed up at many service providers.
>>>
>>> could i do a header check for this single email account and reject the
>>> empty from address<>  for that email account only?
>>> what are my options? what's the smartest thing to do??
>>>
>>> thanks a lot for your help&  service
>>>
>>> with best regards
>>> becki
>>>
>>   if it always the same host sending backscatter
>> simple block the host by access list and/or firewall
>>
>> lets see some logs, there are many way to deal with backscatter
>>
> 

please dont top post,

do they have  always the same body ?
or equal bodies which might can be matched
with some body_checks

something like
 main.cf
body_checks = pcre:/etc/postfix/body_checks

/sunstarcasino\.net/ REJECT backscatter


-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

Re: email account bombarded with SPAM error bounces - what to do?

[wolfgang]

In an older episode (Friday, 9. July 2010), Kammen van, Marco, Springer 
SBM NL wrote:


> But there is a big spam/virus attack going on, where messages look
> like NDR's but they aren't.
> Various big anti spam vendors are having serious issues stopping
> this.

Could you provide a URL where more details are available?

Regards,

wolfgang

RE: email account bombarded with SPAM error bounces - what to do?

[Kammen van, Marco, Springer SBM NL]

>From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Administrator
Beckspaced.com
>Sent: Friday, July 09, 2010 12:52 PM
>To: Robert Schetterer
>Cc: postfix-users@postfix.org
>Subject: Re: email account bombarded with SPAM error bounces - what to
do?
>
 > hello robert,

>thanks a lot for your quick reply ...
>actually it is not always the same IP or host sending the error bounces
...
>the bounces are sent from hundred of different IP addresses ...

>any more idea?

>thanks for your help & fun
>becki

Hi Robert,

Not sure if its related to your issue.
But there is a big spam/virus attack going on, where messages look like
NDR's but they aren't.
Various big anti spam vendors are having serious issues stopping this.

Marco van Kammen
Springer Science+Business Media
System Manager & Postmaster   
van Godewijckstraat 30 | 3311 GX
Office Number: 05E21 
Dordrecht 
The Netherlands  
www.springer.com

Re: email account bombarded with SPAM error bounces - what to do?

[Administrator Beckspaced.com]

 hello robert,

thanks a lot for your quick reply ...
actually it is not always the same IP or host sending the error bounces ...
the bounces are sent from hundred of different IP addresses ...

any more idea?

thanks for your help & fun
becki


below some logs you requested ... change the real email account to 
spamu...@domain.com  ->


Jul  8 12:20:27 gehirn postfix/smtpd[19857]: NOQUEUE: reject: RCPT from 
crusty.hosts.net.nz[210.48.108.195]: 554 5.7.1 : 
Recipient address rejected: Access denied; from=<> 
to= proto=SMTP helo=
Jul  8 12:22:08 gehirn postfix/smtpd[19859]: NOQUEUE: reject: RCPT from 
mailx.nlabs.de[92.79.50.220]: 554 5.7.1 : Recipient 
address rejected: Access denied; from=<> to= 
proto=SMTP helo=
Jul  8 12:22:48 gehirn postfix/smtpd[19854]: warning: 222.254.188.229: 
address not listed for hostname localhost
Jul  8 12:23:28 gehirn postfix/smtpd[18358]: NOQUEUE: reject: RCPT from 
port-87-234-220-121.static.qsc.de[87.234.220.121]: 554 5.7.1 
: Recipient address rejected: Access denied; 
from=<> to= proto=SMTP helo=
Jul  8 12:26:22 gehirn postfix/smtpd[19854]: setting up TLS connection 
from mail.aydin.edu.tr[212.174.169.8]
Jul  8 12:26:22 gehirn postfix/smtpd[19854]: TLS connection established 
from mail.aydin.edu.tr[212.174.169.8]: TLSv1 with cipher 
DHE-RSA-AES256-SHA (256/256 bits)
Jul  8 12:26:22 gehirn postfix/smtpd[19854]: NOQUEUE: reject: RCPT from 
mail.aydin.edu.tr[212.174.169.8]: 554 5.7.1 : 
Recipient address rejected: Access denied; from=<> 
to= proto=ESMTP helo=
Jul  8 12:27:57 gehirn postfix/smtpd[19850]: NOQUEUE: reject: RCPT from 
svhqgtw02.ethiopianairlines.com[213.55.83.14]: 554 5.7.1 
: Recipient address rejected: Access denied; 
from=<> to= proto=SMTP 
helo=
Jul  8 12:27:58 gehirn postfix/smtpd[18899]: NOQUEUE: reject: RCPT from 
svhqgtw02.ethiopianairlines.com[213.55.83.14]: 554 5.7.1 
: Recipient address rejected: Access denied; 
from=<> to= proto=SMTP 
helo=
Jul  8 12:28:27 gehirn postfix/smtpd[18358]: A565C150A7D: 
client=relay02.is.co.za[196.35.6.70]
Jul  8 12:28:31 gehirn postfix/smtpd[20525]: 78BEC150A7F: 
client=localhost[127.0.0.1]
Jul  8 12:28:35 gehirn postfix/smtpd[18899]: NOQUEUE: reject: RCPT from 
mx2.lost-oasis.net[80.67.160.52]: 554 5.7.1 : 
Recipient address rejected: Access denied; from=<> 
to= proto=SMTP helo=
Jul  8 12:29:23 gehirn postfix/smtpd[18899]: NOQUEUE: reject: RCPT from 
defer114.ocn.ad.jp[122.28.15.169]: 554 5.7.1 : 
Recipient address rejected: Access denied; from=<> 
to= proto=ESMTP helo=
Jul  8 12:29:49 gehirn postfix/smtpd[19850]: E4B86150AE9: 
client=unknown[184.154.34.69]
Jul  8 12:29:56 gehirn postfix/smtpd[20525]: 8B7F4150AF6: 
client=localhost[127.0.0.1]
Jul  8 12:30:43 gehirn postfix/smtpd[19854]: NOQUEUE: reject: RCPT from 
post.vrus.de[85.182.133.62]: 554 5.7.1 : Recipient 
address rejected: Access denied; from=<>


On 7/9/2010 12:42, Robert Schetterer wrote:

Am 09.07.2010 12:35, schrieb Administrator Beckspaced.com:

  hello there,

i'm running a postfix 2.4.6 on a opensuse box.
postfix has amawis-new with spamassasin installed ...

since a few weeks one of my email accounts gets bombarded with thousands
of SPAM mailer daemon error bounces.
could not deliver message ... bla bla bla ...

it's getting really annoying as there are thousands of error bounces
coming in every single day.

looks like that the email address ended up on some SPAM mailing lists
... adn now the mailbox receives all this error message junk

so ... what's the best strategy to get rid off this problem?

already had a quick look ... and the error bounces come in with an empty
<>  from address ...
which seems to be standard for this ... and by default postfix doesn't
block empty from addresses<>

so what's the best thing to do to get rid of those thousand error email
bounces?

thing is that the customer urgently needs this email account as it is
signed up at many service providers.

could i do a header check for this single email account and reject the
empty from address<>  for that email account only?
what are my options? what's the smartest thing to do??

thanks a lot for your help&  service

with best regards
becki


  if it always the same host sending backscatter
simple block the host by access list and/or firewall

lets see some logs, there are many way to deal with backscatter

Re: email account bombarded with SPAM error bounces - what to do?

[Robert Schetterer]

Am 09.07.2010 12:35, schrieb Administrator Beckspaced.com:
>  hello there,
> 
> i'm running a postfix 2.4.6 on a opensuse box.
> postfix has amawis-new with spamassasin installed ...
> 
> since a few weeks one of my email accounts gets bombarded with thousands
> of SPAM mailer daemon error bounces.
> could not deliver message ... bla bla bla ...
> 
> it's getting really annoying as there are thousands of error bounces
> coming in every single day.
> 
> looks like that the email address ended up on some SPAM mailing lists
> ... adn now the mailbox receives all this error message junk
> 
> so ... what's the best strategy to get rid off this problem?
> 
> already had a quick look ... and the error bounces come in with an empty
> <> from address ...
> which seems to be standard for this ... and by default postfix doesn't
> block empty from addresses <>
> 
> so what's the best thing to do to get rid of those thousand error email
> bounces?
> 
> thing is that the customer urgently needs this email account as it is
> signed up at many service providers.
> 
> could i do a header check for this single email account and reject the
> empty from address <> for that email account only?
> what are my options? what's the smartest thing to do??
> 
> thanks a lot for your help & service
> 
> with best regards
> becki
> 

 if it always the same host sending backscatter
simple block the host by access list and/or firewall

lets see some logs, there are many way to deal with backscatter

-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

email account bombarded with SPAM error bounces - what to do?

[Administrator Beckspaced.com]

 hello there,

i'm running a postfix 2.4.6 on a opensuse box.
postfix has amawis-new with spamassasin installed ...

since a few weeks one of my email accounts gets bombarded with thousands 
of SPAM mailer daemon error bounces.

could not deliver message ... bla bla bla ...

it's getting really annoying as there are thousands of error bounces 
coming in every single day.


looks like that the email address ended up on some SPAM mailing lists 
... adn now the mailbox receives all this error message junk


so ... what's the best strategy to get rid off this problem?

already had a quick look ... and the error bounces come in with an empty 
<> from address ...
which seems to be standard for this ... and by default postfix doesn't 
block empty from addresses <>


so what's the best thing to do to get rid of those thousand error email 
bounces?


thing is that the customer urgently needs this email account as it is 
signed up at many service providers.


could i do a header check for this single email account and reject the 
empty from address <> for that email account only?

what are my options? what's the smartest thing to do??

thanks a lot for your help & service

with best regards
becki

Re: SASL Authentication per recipient domain

[David Jacobson]

From: "Jerry"
To:
postfix-users@postfix.orgSent: Friday, July 9, 2010
11:40:11 AMSubject: Re: SASL Authentication per recipient
domainOn Fri, 9 Jul 2010 09:36:56 +0200 (SAST)David Jacobson
 articulated:> From: "Noel Jones"
 > To: postfix-users@postfix.org
> Sent: Thursday, July 8, 2010 5:04:07 PM > Subject: Re:
SASL Authentication per recipient domain > > On 7/8/2010
8:24 AM, David Jacobson wrote: > > Hi There, > >
> > First post to postfix mailing list, be nice... ;) >
> > > Postfix 2.6.6.2z > > > > We have a
hosted mail platform with 100's of companies, some > > companies
require our MTA to talk to a smarthost for their > > domain with
authentication. > > > > As per SASL_README >
> > > The above can be achieved with something like this :
> > > > /etc/postfix/sasl_passwd: > > #
destination credentials > > [mail.isp.example] username:password
> > # Alternative form: > > #
[mail.isp.example]:submission username:password > > >
> The problem with the above is it will use the auth details >
> when talking to mail.isp.example for ALL companies which is >
> not what we want, we want to simply state that the recipient >
> domain x.com uses auth and no one else. > > > >
The above method doesn't help us as we can't have anyone who > >
mails mail.isp.example to use that clients auth details. > >
> > As per
http://www.postfix.org/SASL_README.html#client_sasl_sender > >
> > We can do what we want to achieve on a per sender basis
which > > would give the desired results we are looking for,
however > > this becomes a problem for us in terms of managing
users in > > this file when new users are created/removed etc -
we would > > prefer not to write scripts to try and manage this,
it will > > get messy. > > > > So, my
question is with SASL Authentication, can we do SMTP > > AUTH on
a per sender domain basis and not on a per destination > > host
basis nor a per user basis. > > > > I'm not quite sure
why we can't do something simple like > > @domain.com or
*...@domain.com if per sender works fine. > > Now would be a
good time to read >
http://www.postfix.org/postconf.5.html#sender_dependent_relayhost_maps
> > -- Noel Jones > > Hi Noel, >
> Thanks for the response, we are already using
sender_dependent_relayhost_maps the problem is that from what we can see
you cannot specify sender dependant SASL password's, which is our original
problem and exactly what we are after. > > Please let me know
if we are wrong here? Could this be what you are looking
for:http://www.postfix.com/postconf.5.html#smtp_sasl_password_maps--
Jerry ✌postfix-u...@seibercom.netHi Jerry,I
appreciate your response, however if you read my original message you will
notice that we have had a look at all support smtp_sasl_password_maps
options and it only allows for the following scenario according to the
docs:1) use SMTP auth for _destination_ mail server2) use SMTP
auth PER _email address_ to destination mail serverIt does not
allow for SMTP auth per _sending domain_Option 2 will give desired
results but is a nightmare to manage individual email addresses in the
file, we just want to say *...@sendingdomain.com uses auth.We primary
use EXIM and are used to the extreme flexibility of configuration around
Exim, that can easily do the above and are finding it hard to do, what I
believe is basic virtual domain configuration with Postfix.  We would
normally switch to Exim, but for this instance we have to use
Postfix.Best,_TO
REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mailTO
(UN)SUBSCRIBE see http://www.postfix.org/lists.htmlWe are all born
equal... just some of us are more equal than others. 



       


David Jacobson


Technical Director


Tel:
011 262 3632


Fax:
086 637 8868


Cell:
083 235 0760


Email:
dav...@synaq.com


Web:
www.synaq.com


Sandhaven Office Park, Pongola CrescentEastgate Ext 17 Sandton

Re: SASL Authentication per recipient domain

[Jerry]

On Fri, 9 Jul 2010 09:36:56 +0200 (SAST)
David Jacobson  articulated:

> From: "Noel Jones"  
> To: postfix-users@postfix.org 
> Sent: Thursday, July 8, 2010 5:04:07 PM 
> Subject: Re: SASL Authentication per recipient domain 
> 
> On 7/8/2010 8:24 AM, David Jacobson wrote: 
> > Hi There, 
> > 
> > First post to postfix mailing list, be nice... ;) 
> > 
> > Postfix 2.6.6.2z 
> > 
> > We have a hosted mail platform with 100's of companies, some 
> > companies require our MTA to talk to a smarthost for their 
> > domain with authentication. 
> > 
> > As per SASL_README 
> > 
> > The above can be achieved with something like this : 
> > 
> > /etc/postfix/sasl_passwd: 
> > # destination credentials 
> > [mail.isp.example] username:password 
> > # Alternative form: 
> > # [mail.isp.example]:submission username:password 
> > 
> > The problem with the above is it will use the auth details 
> > when talking to mail.isp.example for ALL companies which is 
> > not what we want, we want to simply state that the recipient 
> > domain x.com uses auth and no one else. 
> > 
> > The above method doesn't help us as we can't have anyone who 
> > mails mail.isp.example to use that clients auth details. 
> > 
> > As per http://www.postfix.org/SASL_README.html#client_sasl_sender 
> > 
> > We can do what we want to achieve on a per sender basis which 
> > would give the desired results we are looking for, however 
> > this becomes a problem for us in terms of managing users in 
> > this file when new users are created/removed etc - we would 
> > prefer not to write scripts to try and manage this, it will 
> > get messy. 
> > 
> > So, my question is with SASL Authentication, can we do SMTP 
> > AUTH on a per sender domain basis and not on a per destination 
> > host basis nor a per user basis. 
> > 
> > I'm not quite sure why we can't do something simple like 
> > @domain.com or *...@domain.com if per sender works fine. 
> 
> Now would be a good time to read 
> http://www.postfix.org/postconf.5.html#sender_dependent_relayhost_maps 
> 
> -- Noel Jones 
> 
> Hi Noel, 
> 
> Thanks for the response, we are already using sender_dependent_relayhost_maps 
> the problem is that from what we can see you cannot specify sender dependant 
> SASL password's, which is our original problem and exactly what we are after. 
> 
> Please let me know if we are wrong here? 

Could this be what you are looking for:

http://www.postfix.com/postconf.5.html#smtp_sasl_password_maps

-- 
Jerry ✌
postfix-u...@seibercom.net

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

We are all born equal... just some of us are more equal than others.

Re: Greylisting & SMTP auth

[Ralf Hildebrandt]

* Hendrik Pahl :
> Hi folks,
> 
> we're having some trouble with greylisting (postgrey) and smtp auth.
> 
> smtp_recipient_restrictions looks like:

It's smtpd_recipient_restrictions

> permit_sasl_authenticated, permit_mynetworks,
> reject_unauth_destination, warn_if_reject,
> reject_unknown_sender_domain, warn_if_reject,
> reject_invalid_hostname,
> warn_if_reject, reject_non_fqdn_sender,
> warn_if_reject, reject_non_fqdn_recipient,
> warn_if_reject, reject_rbl_client 
> ix.dnsbl.manitu.net,
> check_policy_service inet:127.0.0.1:10030
> 
> Now, when a client authenticates the mail is greylisted

No, it's not.

permit_sasl_authenticated returns OK in that case, and no other
restriction fires.

Maybe you have more restrictions?

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Greylisting & SMTP auth

[Hendrik Pahl]

Hi folks,

we're having some trouble with greylisting (postgrey) and smtp auth.

smtp_recipient_restrictions looks like:

permit_sasl_authenticated, permit_mynetworks,
reject_unauth_destination, warn_if_reject,
reject_unknown_sender_domain, warn_if_reject,
reject_invalid_hostname,
warn_if_reject, reject_non_fqdn_sender,
warn_if_reject, reject_non_fqdn_recipient,
warn_if_reject, reject_rbl_client  
ix.dnsbl.manitu.net,

check_policy_service inet:127.0.0.1:10030

Now, when a client authenticates the mail is greylisted - since there  
are some users

directly relaying on this server, this is pretty uncool.

is there any chance to avoid mails being greylisted when the  
connection is correctly

authenticated?

thanks in advance,

i.A. Hendrik Pahl
System Engineering

team! datentechnik GmbH & Co.KG
Werner von Siemens Straße 12a
49124 Georgsmarienhuette
Tel.: +49 (0)5401-8226-50
Fax : +49 (0)5401-8226-55

E-Mail: p...@team-datentechnik.de
Internet: www.team-datentechnik.de
HRA 110397, Amtsgericht Osnabrück
Geschäftsführung: Reemt Lükenga

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich
erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie
diese E-Mail. Vielen Dank.

Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht
gestattet.

This e-mail contains confidential and/or privileged information. If  
you are not

the intended recipient (or have received this e-mail in error) please notify
the sender and delete this message.
Thank you.

Any unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.

Re: SASL Authentication per recipient domain

[David Jacobson]

From: "Noel Jones"
To:
postfix-users@postfix.orgSent: Thursday, July 8, 2010
5:04:07 PMSubject: Re: SASL Authentication per recipient
domainOn 7/8/2010 8:24 AM, David Jacobson wrote:> Hi
There,>> First post to postfix mailing list, be nice...
;)>> Postfix 2.6.6.2z>> We have a hosted mail
platform with 100's of companies, some> companies require our MTA
to talk to a smarthost for their> domain with
authentication.>> As per SASL_README>> The
above can be achieved with something like this :>>
/etc/postfix/sasl_passwd:>      # destination  
                credentials>
     [mail.isp.example]          
   username:password>      # Alternative
form:>      # [mail.isp.example]:submission
username:password>> The problem with the above is it will
use the auth details> when talking to mail.isp.example for ALL
companies which is> not what we want, we want to simply state that
the recipient> domain x.com uses auth and no one
else.>> The above method doesn't help us as we can't have
anyone who> mails mail.isp.example to use that clients auth
details.>> As per
http://www.postfix.org/SASL_README.html#client_sasl_sender>>
We can do what we want to achieve on a per sender basis which> would
give the desired results we are looking for, however> this becomes a
problem for us in terms of managing users in> this file when new
users are created/removed etc - we would> prefer not to write
scripts to try and manage this, it will> get messy.>>
So, my question is with SASL Authentication, can we do SMTP> AUTH on
a per sender domain basis and not on a per destination> host basis
nor a per user basis.>> I'm not quite sure why we can't do
something simple like> @domain.com or *...@domain.com if per sender
works fine.Now would be a good time to
readhttp://www.postfix.org/postconf.5.html#sender_dependent_relayhost_maps  
-- Noel JonesHi Noel,Thanks for the response, we are
already using sender_dependent_relayhost_maps the problem is that from
what we can see you cannot specify sender dependant SASL password's, which
is our original problem and exactly what we are after.Please let me
know if we are wrong here?Cheers 



       


David Jacobson


Technical Director


Tel:
011 262 3632


Fax:
086 637 8868


Cell:
083 235 0760


Email:
dav...@synaq.com


Web:
www.synaq.com


Sandhaven Office Park, Pongola CrescentEastgate Ext 17 Sandton