Re: forwarding already sent mails back to server results in: 553 5.7.1 Sender address rejected: not logged in

[Wietse Venema]

oliver sandmann:
> Hi
> 
> I have the following setup:
> 
> new postfixserver: sandmann.biz
> legacy email system: kosmann.net (I am not root here.)
> 
> one email each: oli...@sandmann.biz
> oli...@kosmann.net
> 
> normally every mail going to the old oli...@kosmann.net is
> copy-forwarded to the new mail oli...@sandmann.biz. I keep a copy of
> every mail locally at oli...@kosmann.net, just to be sure and not to
> loose a single mail.
> 
> Everything works fine!
> 
> Except:
> When I send mail from oli...@sandmann.biz to my old address
> oli...@kosmann.net, it should be delivered there locally and this mail
> should be forwarded to oli...@sandmann.biz and should then be delivered
> locally here, too.
> 
> Partial success:
> The first local delivery takes place at oli...@kosmann.net
> 
> But:
> While trying to forward the mail to oli...@sandmann.biz it gets rejected
> with the following error:
>   oli...@sandmann.biz
> SMTP error from remote mail server after RCPT TO::
> host mail.sandmann.biz [80.77.29.210]: 553 5.7.1 :
> Sender address rejected: not logged in
> 
> 
> I think I understand the underlying problem. Such mails try to do
> desired and valid roundtrip starting at oli...@sandmann.biz and ending
> at oli...@sandmann.biz, too. It seems that the From-line stating
> oli...@sandmann.biz as the original sender while the mail returns to
> oli...@sandmann.biz triggers an authentication check but as this mail is
> in the forwarding process from kosmann.net to sandmann.biz no user
> authentication can take place.
> 
> Does anybody have a clue, how to fix this problem?
> 
TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail

TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

Thank you for using Postfix.

Adding single-domain address verification

[Michael Orlitzky]

Our MX currently relays to one of two boxes (mail1, mail2) based on a 
list of domains in transport_maps. Both mail1 and mail2 are ours, and we 
have a full list of domains and recipients in relay_domains and 
relay_recipient maps respectively.


Now, I would like to add a third, external, relay destination for one 
domain. I can add the domain to relay_domains, but would prefer to use 
address verification for the recipients (in that domain only).


My current restrictions:

smtpd_recipient_restrictions =
 reject_unauth_destination,
 reject_unlisted_recipient,
 check_recipient_access hash:/etc/postfix/maps/rfc_addresses,
 reject_non_fqdn_helo_hostname,
 reject_invalid_helo_hostname,
 reject_non_fqdn_sender,
 check_client_access pcre:/etc/postfix/maps/reverse_dns.pcre,
 reject_unknown_sender_domain,
 check_client_access pcre:/etc/postfix/maps/generic_rbl_clients.pcre,
 check_sender_access hash:/etc/postfix/maps/backscatter_senders,
 reject_rhsbl_client dbl.spamhaus.org,
 reject_rhsbl_helo   dbl.spamhaus.org,
 reject_rhsbl_sender dbl.spamhaus.org,
 check_policy_service unix:private/policyd-spf,
 check_policy_service unix:private/postgrey,
 permit

My first question is, what effect does reject_unverified_recipient 
actually have? For example, if the recipient is verified, do the 
restrictions continue to be evaluated, or is it the equivalent of an OK? 
If the other restrictions are evaluated, wouldn't the address still be 
rejected by either reject_unlisted_recipient or the default 
smtpd_reject_unlisted_recipient=yes?


Regardless of the answer to that question, where is the smartest place 
to stick that restriction in my current list? I would prefer to add 
something like,


  check_recipient_access hash:/.../recipient_verify_domains

containing,

  example.com   reject_unverified_recipient

so that only that domain's addresses are verified. However, this depends 
on whether or not the reject_unlisted_recipient is skipped. If it isn't, 
should I move the reject_unlisted/unverified restrictions to the end? Or 
create a separate (almost-identical) restrictions class for the domain 
in question?

forwarding already sent mails back to server results in: 553 5.7.1 Sender address rejected: not logged in

[oliver sandmann]

Hi

I have the following setup:

new postfixserver: sandmann.biz
legacy email system: kosmann.net (I am not root here.)

one email each: oli...@sandmann.biz
oli...@kosmann.net

normally every mail going to the old oli...@kosmann.net is
copy-forwarded to the new mail oli...@sandmann.biz. I keep a copy of
every mail locally at oli...@kosmann.net, just to be sure and not to
loose a single mail.

Everything works fine!

Except:
When I send mail from oli...@sandmann.biz to my old address
oli...@kosmann.net, it should be delivered there locally and this mail
should be forwarded to oli...@sandmann.biz and should then be delivered
locally here, too.

Partial success:
The first local delivery takes place at oli...@kosmann.net

But:
While trying to forward the mail to oli...@sandmann.biz it gets rejected
with the following error:
  oli...@sandmann.biz
SMTP error from remote mail server after RCPT TO::
host mail.sandmann.biz [80.77.29.210]: 553 5.7.1 :
Sender address rejected: not logged in


I think I understand the underlying problem. Such mails try to do
desired and valid roundtrip starting at oli...@sandmann.biz and ending
at oli...@sandmann.biz, too. It seems that the From-line stating
oli...@sandmann.biz as the original sender while the mail returns to
oli...@sandmann.biz triggers an authentication check but as this mail is
in the forwarding process from kosmann.net to sandmann.biz no user
authentication can take place.

Does anybody have a clue, how to fix this problem?

Thank you in advance.

Regards
Oliver

-- 
Oliver Sandmann

Re: dealing with Yahoo slowness

[Victor Duchovni]

On Fri, Jun 18, 2010 at 02:05:36PM -0700, Florin Andrei wrote:

> main.cf:
> transport_maps = hash:/etc/postfix/transport
> fragile_destination_concurrency_limit = 2
> fragile_destination_concurrency_failed_cohort_limit = 1
> fragile_destination_rate_delay = 2s

Try:

# Change from 1 above
fragile_destination_concurrency_failed_cohort_limit = 5
# New, more stable feedback controls from 2.5
fragile_destination_concurrency_positive_feedback = 1/3
fragile_destination_concurrency_negative_feedback = 1/8

I think that will significantly reduce the rate at which delivery is
unnecessarily throttled.

-- 
Viktor.

Re: dealing with Yahoo slowness

[Florin Andrei]

On 06/14/2010 11:54 AM, Florin Andrei wrote:


Well, that does it. I got RPM packages with 2.7 from two different
sources. Time for testing, then upgrade, and I'll keep y'all posted with
the results.


And here it is, the status update.

I got the 2.7.0 src.rpm packages made by Simon J Mudd 
http://ftp.wl0.org/official/ and rebuilt them on my devel instance. 
Installed them on the gateways and migrated the old custom settings.


Just this upgrade, alone, from 2.3.3 (the default version that comes 
with Red Hat 5) to 2.7.0 increased our delivery success to Yahoo by, I 
guess, 50%. Now a lot more messages get delivered before we have to 
purge the queue because it's too late. Still not perfect, but better.


Related and relevant non-default settings:

master.cf:
fragile   unix  -   -   n   -   5   smtp
   -o smtp_helo_timeout=5 -o smtp_connect_timeout=5

main.cf:
transport_maps = hash:/etc/postfix/transport
fragile_destination_concurrency_limit = 2
fragile_destination_concurrency_failed_cohort_limit = 1
fragile_destination_rate_delay = 2s

transport:
yahoo.com  fragile:
# bunch of other Yahoo domains here
hotmail.com  fragile:
comcast.net  fragile:

Before the upgrade, delivery to Yahoo would get interrupted for two 
reasons: Yahoo getting annoyed by our delivery rate and stopped 
accepting messages, and users clicking the Spam button (unjustified, 
IMO, but that's another story).
After the upgrade, it appears that the only reason why Yahoo stops 
accepting messages (it still does, even now) is users clicking Spam.


Things I'm planning to try from now on:

1. Use slightly more aggressive *_destination_* settings, as indicated 
by Mike Hutchinson earlier in this thread.


2. Separate the various finicky destinations into their own pathways in 
master.cf, instead of lumping them together under "fragile". Perhaps 
even dump some of them back into general delivery, since only Yahoo 
seems to really cause trouble.


3. Use two outbound email gateways instead of one. This might double the 
delivery rate "for free".


4. Upgrade to 2.7.1, try to customize other parameters, etc.

Suggestions are welcome.

I'll keep you posted if I find anything new and notable.

--
Florin Andrei
http://florin.myip.org/

Re: Force bounce from queue

[Victor Duchovni]

On Fri, Jun 18, 2010 at 08:50:00PM +0100, Guy wrote:

> Hi,
> 
> I've got a number of messages sitting in the deferred queue because the
> user's maildir is overquota. Maildrop allows double the user's paid for
> quota so if they've used up that much space I'm happy to immediately bounce
> messages to the overquota account at that point. I could do this by
> installing the VDA patch and doing some funky sql queries to use virtual
> (which can bounce on overquota with the patch) when the user has used up the
> full maildrop quota and use maildrop when the account is under quota.
> 
> That said, I'd like to avoid using the patch as I've been quite happy using
> the Ubuntu postfix package up to this point. I was thinking about a script
> that checks the queue every few hours and forces overquota deferred messages
> to bounce immediately, but I'm not sure if that's possible. Postsuper
> doesn't appear to have the capability.
> Does anyone know of a way to force the bounce of a deferred message (based
> on queueid or perhaps some other more elegant way of achieving this?

You can update the transport table with a per-user entry:

u...@example.comerror:5.2.2 Mailbox full

(and then don't forget to delete this when the user goes under quota).

-- 
Viktor.

Re: Force bounce from queue

[Wietse Venema]

Guy:
> Hi,
> 
> I've got a number of messages sitting in the deferred queue because the
> user's maildir is overquota. Maildrop allows double the user's paid for
> quota so if they've used up that much space I'm happy to immediately bounce
> messages to the overquota account at that point. I could do this by
> installing the VDA patch and doing some funky sql queries to use virtual
> (which can bounce on overquota with the patch) when the user has used up the
> full maildrop quota and use maildrop when the account is under quota.
> 
> That said, I'd like to avoid using the patch as I've been quite happy using
> the Ubuntu postfix package up to this point. I was thinking about a script
> that checks the queue every few hours and forces overquota deferred messages
> to bounce immediately, but I'm not sure if that's possible. Postsuper
> doesn't appear to have the capability.
> Does anyone know of a way to force the bounce of a deferred message (based
> on queueid or perhaps some other more elegant way of achieving this?

What about the example AWK script in the postsuper manpage?

Wietse

Force bounce from queue

[Guy]

Hi,

I've got a number of messages sitting in the deferred queue because the
user's maildir is overquota. Maildrop allows double the user's paid for
quota so if they've used up that much space I'm happy to immediately bounce
messages to the overquota account at that point. I could do this by
installing the VDA patch and doing some funky sql queries to use virtual
(which can bounce on overquota with the patch) when the user has used up the
full maildrop quota and use maildrop when the account is under quota.

That said, I'd like to avoid using the patch as I've been quite happy using
the Ubuntu postfix package up to this point. I was thinking about a script
that checks the queue every few hours and forces overquota deferred messages
to bounce immediately, but I'm not sure if that's possible. Postsuper
doesn't appear to have the capability.
Does anyone know of a way to force the bounce of a deferred message (based
on queueid or perhaps some other more elegant way of achieving this?

Thanks
Guy

-- 
Don't just do something...sit there!

Re: SQLite support in Postfix

[Wietse Venema]

Patrick Ben Koetter:
> * Wietse Venema :
> > Victor Duchovni:
> > > On Fri, Jun 18, 2010 at 05:58:02PM +0200, Patrick Ben Koetter wrote:
> > > 
> > > > > Right now this is a read-only implementation (like mysql/pgsql)
> > > > > but it may be worthwhile to add update support. SQLite implements
> > > > > locking internally. That would allow us to avoid the problems with
> > > > > Postfix's external locks on Berkeley DB maps, which are broken
> > > > > after BDB version 2.
> > > > 
> > > > That's great news!
> > > 
> > > Indeed. One still needs tools to insert data into the database.
> > > Does Postfix need to provide a minimal interface for this, or do we
> > > assume that SQLite users will have adequate tools outside Postfix.
> > 
> > A "postmap" option to create an SQLite file would make sense.
> 
> Do you mean creating an SQLite database from a flat file that, for example,
> contains access rules mapping addresses to actions (r...@foo   REJECT)?

Yes.

> What if there were many files that wanted to be stored in a SQLite database?
> Creating a database only for one table would be a waste of ressources, I
> guess.

With sqlite:mapname, the "mapname" configuration file specifies
the name of the database file and the name of the table in that
database.  So you can have it either way:  multiple tables in one
file, or one file per table.

I would recommend to use separate database files for read/write
data and read-mostly data; if you don't write to a file it is less
likely to become corrupted.

Likewise, use separate database files for data that is sensitive
or trusted, and for data that isn't.

But, there is no way to enforce this, since every SQLite map
is configured independently.

Wietse

Re: [SP] Re: [SP] Re: How to force SMTP AUTH to restrict Sender Addresses?

[Jose Ildefonso Camargo Tolosa]

I *never* said it was easy. I only said it should be possible on most
platforms. Also, I never said it was even necessary.

Thanks for the tech discussion, I even feel my neurons getting out of
lethargy!  :)

On Jun 18, 2010 9:47 AM, "Victor Duchovni" <
victor.ducho...@morganstanley.com> wrote:

On Fri, Jun 18, 2010 at 12:17:40AM -0430, Jose Ildefonso Camargo Tolosa
wrote:

> > The plug-ins you...
Most platforms optionally compile-in LDAP support, and link against LDAP
libraries (static or dynamic). Don't confuse run-time dynamic linking
with dynamic loading of new modules.


> I mean, most platform actually support dynamic linking, so, just like it
> is done in Debian (and...
   - libtool is an abomination, I expect and very much hope that Postfix
 will not, any time soon, resort to using libtool.

   - The mechanisms for dynamic loading of modules are not standardized
 across various Unix-like systems. This feature requires a lot of
 abstraction code to to implement portably across AIX, MacOSX,
 Linux, HP-UX, ...


> I have seem similar things on Solaris too (.sl, if memory
> serves me).
Don't confuse HP-UX with Solaris, Solaris has ".so" files, and a sensibly
clean dynamic loading API (emulated by Linux).


> So, I would say that:most platforms support this.
Please donate libtool-free code that works on most platforms supported
by Postfix and:

   - Loads a shared object, with minimal pollution of the global
 symbol table (i.e. symbols of loaded object and dependencies
 are not visible outside the object and its dependency tree).

   - Finds a specific small set of symbols within the loaded object
 and returns a table of pointers to these.

   - Builds shared relocatable objects and constructs shared libraries
 on the various platforms in question.

It is a good idea do not claim that something is easy until you've
done it yourself. The difference between a novice and an expert is
that experts know which problems are not as easy as they may seem.

> Off course,

http://safarisbackpack.spaces.live.com/blog/cns!36664C9801636C53!216.entry

--
   Viktor.

Re: SQLite support in Postfix

[Wietse Venema]

Rob Foehl:
> On Fri, 18 Jun 2010, Victor Duchovni wrote:
> 
> > Indeed. One still needs tools to insert data into the database.
> > Does Postfix need to provide a minimal interface for this, or do we
> > assume that SQLite users will have adequate tools outside Postfix.
> 
> It wouldn't hurt to omit this support for the time being, as that's at 
> least consistent with the approach to other SQL engines.  It might make 
> sense to roll this up into generic update support for any SQL database, 
> which I've been considering for a while...
> 
> > Does Postfix need to do anything to indicate transaction boundaries
> > between its lookups? Or is not starting a transaction in the first place,
> > sufficient to indicate that each query is independent from all the others?
> 
> SQLite v3 implements implicit transactions for writers which don't 
> explicitly request them, the only thing that the readers need to handle is 
> retrying queries after SQLITE_BUSY.  The full locking semantics are 
> described here:
> 
> http://www.sqlite.org/lockingv3.html

I'll add a check for that.

Wietse

Re: SQLite support in Postfix

[Ralf Hildebrandt]

* Patrick Ben Koetter :

> > A "postmap" option to create an SQLite file would make sense.
> 
> Do you mean creating an SQLite database from a flat file that, for example,
> contains access rules mapping addresses to actions (r...@foo   REJECT)?
> 
> What if there were many files that wanted to be stored in a SQLite database?
> Creating a database only for one table would be a waste of ressources, I
> guess.

It would make a great tool for a flat-file -> database migration:

* Use flat files first
* verify that "it works"
* then convert into SQLite
* verify that "it (still) works"
* then convert into "real" Database

It would actually help the user to use the path that has been
recommended by Victor et.al.

-- 
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: SQLite support in Postfix

[Patrick Ben Koetter]

* Wietse Venema :
> Victor Duchovni:
> > On Fri, Jun 18, 2010 at 05:58:02PM +0200, Patrick Ben Koetter wrote:
> > 
> > > > Right now this is a read-only implementation (like mysql/pgsql)
> > > > but it may be worthwhile to add update support. SQLite implements
> > > > locking internally. That would allow us to avoid the problems with
> > > > Postfix's external locks on Berkeley DB maps, which are broken
> > > > after BDB version 2.
> > > 
> > > That's great news!
> > 
> > Indeed. One still needs tools to insert data into the database.
> > Does Postfix need to provide a minimal interface for this, or do we
> > assume that SQLite users will have adequate tools outside Postfix.
> 
> A "postmap" option to create an SQLite file would make sense.

Do you mean creating an SQLite database from a flat file that, for example,
contains access rules mapping addresses to actions (r...@foo   REJECT)?

What if there were many files that wanted to be stored in a SQLite database?
Creating a database only for one table would be a waste of ressources, I
guess.

Would it make sense to have two commands? One to create the database and one
to add flat files as tables to the database or update existing tables?

Or do you mean only creating a database and then use other tools to maintain
the data therein?

The easiest part - assuming the SQLite driver can also write - would probably
be to use it on everything that goes into $data_directory i.e. databases that
keep track of tls session keys or verified senders and so on.

p...@rick

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

saslfinger (debugging SMTP AUTH):

Re: SQLite support in Postfix

[Rob Foehl]

On Fri, 18 Jun 2010, Victor Duchovni wrote:


Indeed. One still needs tools to insert data into the database.
Does Postfix need to provide a minimal interface for this, or do we
assume that SQLite users will have adequate tools outside Postfix.


It wouldn't hurt to omit this support for the time being, as that's at 
least consistent with the approach to other SQL engines.  It might make 
sense to roll this up into generic update support for any SQL database, 
which I've been considering for a while...



Does Postfix need to do anything to indicate transaction boundaries
between its lookups? Or is not starting a transaction in the first place,
sufficient to indicate that each query is independent from all the others?


SQLite v3 implements implicit transactions for writers which don't 
explicitly request them, the only thing that the readers need to handle is 
retrying queries after SQLITE_BUSY.  The full locking semantics are 
described here:


http://www.sqlite.org/lockingv3.html

-Rob

Re: SQLite support in Postfix

[Wietse Venema]

Victor Duchovni:
> On Fri, Jun 18, 2010 at 05:58:02PM +0200, Patrick Ben Koetter wrote:
> 
> > > Right now this is a read-only implementation (like mysql/pgsql)
> > > but it may be worthwhile to add update support. SQLite implements
> > > locking internally. That would allow us to avoid the problems with
> > > Postfix's external locks on Berkeley DB maps, which are broken
> > > after BDB version 2.
> > 
> > That's great news!
> 
> Indeed. One still needs tools to insert data into the database.
> Does Postfix need to provide a minimal interface for this, or do we
> assume that SQLite users will have adequate tools outside Postfix.

A "postmap" option to create an SQLite file would make sense.

> Does Postfix need to do anything to indicate transaction boundaries
> between its lookups? Or is not starting a transaction in the first place,
> sufficient to indicate that each query is independent from all the others?

I'm not familiar with the SQLite API to know how explicit the hints
from the application need to be to make locking work. That would
be future work.

Wietse

Re: SQLite support in Postfix

[Brian Evans - Postfix List]

 On 6/18/2010 12:07 PM, Victor Duchovni wrote:

On Fri, Jun 18, 2010 at 05:58:02PM +0200, Patrick Ben Koetter wrote:


Right now this is a read-only implementation (like mysql/pgsql)
but it may be worthwhile to add update support. SQLite implements
locking internally. That would allow us to avoid the problems with
Postfix's external locks on Berkeley DB maps, which are broken
after BDB version 2.

That's great news!

Indeed. One still needs tools to insert data into the database.
Does Postfix need to provide a minimal interface for this, or do we
assume that SQLite users will have adequate tools outside Postfix.


At the very least, the documentation could link to the SQLite website 
for tools..

http://www.sqlite.org/cvstrac/wiki?p=ManagementTools

Re: SQLite support in Postfix

[Victor Duchovni]

On Fri, Jun 18, 2010 at 05:58:02PM +0200, Patrick Ben Koetter wrote:

> > Right now this is a read-only implementation (like mysql/pgsql)
> > but it may be worthwhile to add update support. SQLite implements
> > locking internally. That would allow us to avoid the problems with
> > Postfix's external locks on Berkeley DB maps, which are broken
> > after BDB version 2.
> 
> That's great news!

Indeed. One still needs tools to insert data into the database.
Does Postfix need to provide a minimal interface for this, or do we
assume that SQLite users will have adequate tools outside Postfix.

Does Postfix need to do anything to indicate transaction boundaries
between its lookups? Or is not starting a transaction in the first place,
sufficient to indicate that each query is independent from all the others?

-- 
Viktor.

Re: Failed check "loops back to myself"

[Wietse Venema]

Victor Duchovni:
> On Fri, Jun 18, 2010 at 11:41:46AM -0400, Wietse Venema wrote:
> 
> > > This is robust and easy to document. The work-arounds I posted
> > > also work, but are less elegant and should be avoided. If the
> > > OP wants to use them, fine, he is fully informed...
> > 
> > I recommend a different myhostname per "port 25" instance.  The
> > Postfix SMTP client verifies the HELO response and will declare a
> > loop when the best MX host replies to HELO with the client's own
> > myhostname.
> 
> Sure, but when the destination IP address is listed in inet_interfaces,
> the connection is not even made and a loop is detected. Hostname tweaks
> don't help in this case, the idea is to not forward to your own port
> 25, where "your own" means an IP address that is listed in instance's
> "inet_interfaces".

Even if you have different IP addresses, Postfix will declare a
loop when the server responds with myhostname to HELO.

Therefore a different myhostname is NECESSARY but not sufficient.

Wietse

Re: SQLite support in Postfix

[Patrick Ben Koetter]

* Wietse Venema :
> Last weekend I talked with one of the creators of SQLite and was
> impressed by the thoroughness of their code quality process. 
> 
> I brushed up a patch that was circulated two years ago and spent
> a day or so adding error checks and updating documentation.
> 
> Right now this is a read-only implementation (like mysql/pgsql)
> but it may be worthwhile to add update support. SQLite implements
> locking internally. That would allow us to avoid the problems with
> Postfix's external locks on Berkeley DB maps, which are broken
> after BDB version 2.

That's great news!

p...@rick

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

saslfinger (debugging SMTP AUTH):

Re: Failed check "loops back to myself"

[Victor Duchovni]

On Fri, Jun 18, 2010 at 11:41:46AM -0400, Wietse Venema wrote:

> > This is robust and easy to document. The work-arounds I posted
> > also work, but are less elegant and should be avoided. If the
> > OP wants to use them, fine, he is fully informed...
> 
> I recommend a different myhostname per "port 25" instance.  The
> Postfix SMTP client verifies the HELO response and will declare a
> loop when the best MX host replies to HELO with the client's own
> myhostname.

Sure, but when the destination IP address is listed in inet_interfaces,
the connection is not even made and a loop is detected. Hostname tweaks
don't help in this case, the idea is to not forward to your own port
25, where "your own" means an IP address that is listed in instance's
"inet_interfaces".

-- 
Viktor.

Re: Failed check "loops back to myself"

[Wietse Venema]

Victor Duchovni:
> On Fri, Jun 18, 2010 at 10:30:35AM -0400, Phil Howard wrote:
> 
> > > I am fine with the workarounds supplied and can see your point of view,
> > > although I can't agree with a loop detected that is not a loop, I see
> > > that it happens because inet addresses are mixed between instances and I
> > > have my view about wasting more public ip addresses to do this as I told
> > > before. That's all. Thank you all for your answers and comments. :)
> > 
> > The original principle of the loop detection is based on where DNS MX
> > records would point to.  That points to hostnames which point to IP
> > addresses.  Port numbers are not part of it and are assumed to be the
> > SMTP port.  How the detection is actually implemented could vary.
> 
> Not really, for loop detection to be effective, it must detect
> cases in which remote domains specify unexpected MX records (even
> 127.0.0.1) or local transport tables are incomplete. When MX records
> are bogus our transport tables are incomplete, the traffic will go
> to port 25, so all port 25 connections must be tested.
> 
> The supported way to avoid loop detection false-positives on with
> internal forwarding between Postfix instances is to:
> 
>   - Ensure that each Postfix instance uses a separate set of
> IP addresses.
> 
> and/or
> 
>   - Not use port 25 as an internal forwarding destination when
> IP address sharing is unavoidable.
> 
> This is robust and easy to document. The work-arounds I posted
> also work, but are less elegant and should be avoided. If the
> OP wants to use them, fine, he is fully informed...

I recommend a different myhostname per "port 25" instance.  The
Postfix SMTP client verifies the HELO response and will declare a
loop when the best MX host replies to HELO with the client's own
myhostname.

Wietse

Re: Failed check "loops back to myself"

[Victor Duchovni]

On Fri, Jun 18, 2010 at 10:30:35AM -0400, Phil Howard wrote:

> > I am fine with the workarounds supplied and can see your point of view,
> > although I can't agree with a loop detected that is not a loop, I see
> > that it happens because inet addresses are mixed between instances and I
> > have my view about wasting more public ip addresses to do this as I told
> > before. That's all. Thank you all for your answers and comments. :)
> 
> The original principle of the loop detection is based on where DNS MX
> records would point to.  That points to hostnames which point to IP
> addresses.  Port numbers are not part of it and are assumed to be the
> SMTP port.  How the detection is actually implemented could vary.

Not really, for loop detection to be effective, it must detect
cases in which remote domains specify unexpected MX records (even
127.0.0.1) or local transport tables are incomplete. When MX records
are bogus our transport tables are incomplete, the traffic will go
to port 25, so all port 25 connections must be tested.

The supported way to avoid loop detection false-positives on with
internal forwarding between Postfix instances is to:

- Ensure that each Postfix instance uses a separate set of
  IP addresses.

and/or

- Not use port 25 as an internal forwarding destination when
  IP address sharing is unavoidable.

This is robust and easy to document. The work-arounds I posted
also work, but are less elegant and should be avoided. If the
OP wants to use them, fine, he is fully informed...

-- 
Viktor.

Re: Failed check "loops back to myself"

[Phil Howard]

On Fri, Jun 18, 2010 at 09:22, Carlos Velasco  wrote:

> I am NOT complaining at all, just giving my point of view. After all
> this is one of the benefits of open source, to be cooperative and to see
> multiple points of view, it tends to enhance products.
>
> I am fine with the workarounds supplied and can see your point of view,
> although I can't agree with a loop detected that is not a loop, I see
> that it happens because inet addresses are mixed between instances and I
> have my view about wasting more public ip addresses to do this as I told
> before. That's all. Thank you all for your answers and comments. :)

The original principle of the loop detection is based on where DNS MX
records would point to.  That points to hostnames which point to IP
addresses.  Port numbers are not part of it and are assumed to be the
SMTP port.  How the detection is actually implemented could vary.  But
it is traditional that the port is always 25 for mail exchange between
different servers, so assuming it is perfectly valid.  There isn't a
way for you to set up a mail server that others can send mail to in
the normal way without it being on port 25.  Something on another port
is just a hack for some purpose.  If it's a hack, it should have work
arounds.

Re: Suppress "Command died with status 1" in Pipe transport

[Victor Duchovni]

On Fri, Jun 18, 2010 at 05:01:14AM -0500, Adam wrote:

> Good Morning,
> 
> Is there a way to hide the syserr as well as the path returned by a
> pipe transport?  For instance, I have virtual accounts and they are
> handled by a custom transport.  When a message is sent to a
> non-existent user, the mailer-daemon response to the sender is:
> 
> : Command died with status 1:
>"/usr/lib/xmail/postfix/vmtransport". Command output: Unknown user.
>  The user "bob" does not exist at "example.com".

DO NOT exit with status 1. Children of pipe(8) MUST exit with
one of the status codes in 

> Is it possible to only have it send back the command output and not
> the information before it?  So instead it would read:
> 
> :  Unknown user.  The user "bob" does not exist at
> "example.com".

Exit with a correct status code.

-- 
Viktor.

Re: [SP] Re: [SP] Re: How to force SMTP AUTH to restrict Sender Addresses?

[Victor Duchovni]

On Fri, Jun 18, 2010 at 12:17:40AM -0430, Jose Ildefonso Camargo Tolosa wrote:

> > The plug-ins you speak of are a Debian-specific feature, they are not
> > part of the official Postfix release and not available on most platforms.
> 
> So most platforms "statically" link ldap support with postfix?

Most platforms optionally compile-in LDAP support, and link against LDAP
libraries (static or dynamic). Don't confuse run-time dynamic linking
with dynamic loading of new modules.

> I mean, most platform actually support dynamic linking, so, just like it
> is done in Debian (and Ubuntu, and likely on other distros), that it
> just adds the file dict_ldap.so , it should be possible to do
> something similar on most architectures (DLL's on Windows, for
> example).

- libtool is an abomination, I expect and very much hope that Postfix
  will not, any time soon, resort to using libtool.

- The mechanisms for dynamic loading of modules are not standardized
  across various Unix-like systems. This feature requires a lot of
  abstraction code to to implement portably across AIX, MacOSX, 
  Linux, HP-UX, ...

> I have seem similar things on Solaris too (.sl, if memory
> serves me).

Don't confuse HP-UX with Solaris, Solaris has ".so" files, and a sensibly
clean dynamic loading API (emulated by Linux).

> So, I would say that:most platforms support this.

Please donate libtool-free code that works on most platforms supported
by Postfix and:

- Loads a shared object, with minimal pollution of the global
  symbol table (i.e. symbols of loaded object and dependencies
  are not visible outside the object and its dependency tree).

- Finds a specific small set of symbols within the loaded object
  and returns a table of pointers to these.

- Builds shared relocatable objects and constructs shared libraries
  on the various platforms in question.

It is a good idea do not claim that something is easy until you've
done it yourself. The difference between a novice and an expert is
that experts know which problems are not as easy as they may seem.

> Off course,

http://safarisbackpack.spaces.live.com/blog/cns!36664C9801636C53!216.entry

-- 
Viktor.

Re: Spam notification

[Stan Hoeppner]

Mark Goodge put forth on 6/18/2010 4:28 AM:

> 1. Just discard spam.

By this I hope you mean rejecting the message at SMTP time, not accept and
move to /dev/null.

Regarding the OP's original issue, im my experience, nearly all spam that has
a 'from' address matching the local 'to' address is bot spam.  Bot spam is
usually easily killed by using a small handful of good dnsbls, mainly Spamhaus
ZEN as it contains the CBL, and with local rDNS checks against the IP of the
sending host.

If your default/preferred method of fighting spam is accepting everything and
then categorizing it with a content filter...well...I pit you.  This is a
horrible method for fighting/killing spam, and you will forever be plagued
with problems.

ALWAYS reject as much spam as possible at SMTP time using various sane, tried,
and true measures.  For that which still gets though, run it through your
content filters and either pipe it to /dev/null, a quarantine, or tag it for
MUA spam filters.  Again, NEVER accept everything and then filter.

-- 
Stan

SQLite support in Postfix

[Wietse Venema]

Last weekend I talked with one of the creators of SQLite and was
impressed by the thoroughness of their code quality process. 

I brushed up a patch that was circulated two years ago and spent
a day or so adding error checks and updating documentation.

Right now this is a read-only implementation (like mysql/pgsql)
but it may be worthwhile to add update support. SQLite implements
locking internally. That would allow us to avoid the problems with
Postfix's external locks on Berkeley DB maps, which are broken
after BDB version 2.

The documentation is practically identical to that of MySQL:

http://www.porcupine.org/postfix-mirror/sqlite_table.5.html
http://www.porcupine.org/postfix-mirror/SQLITE_README.html

Wietse

Re: Failed check "loops back to myself"

[Carlos Velasco]

> Work WITH the system, or else stop complaining.
> 
>   Wietse

I am NOT complaining at all, just giving my point of view. After all
this is one of the benefits of open source, to be cooperative and to see
multiple points of view, it tends to enhance products.

I am fine with the workarounds supplied and can see your point of view,
although I can't agree with a loop detected that is not a loop, I see
that it happens because inet addresses are mixed between instances and I
have my view about wasting more public ip addresses to do this as I told
before. That's all. Thank you all for your answers and comments. :)

Regards,
Carlos Velasco


*** AVISO LEGAL ***
Este mensaje va dirigido, de manera exclusiva, a su destinatario y
contiene información confidencial y sujeta al secreto profesional,
cuya divulgación no está permitida por la ley. En caso de haber
recibido este mensaje por error, le rogamos que, de forma inmediata,
nos lo comunique mediante correo electrónico remitido a nuestra
atención o a través del teléfono (+34 914531200) y proceda a su
eliminación, así como a la de cualquier documento adjunto al mismo.
Asimismo, le comunicamos que la distribución, copia o utilización de
este mensaje, o de cualquier documento adjunto al mismo, cualquiera
que fuera su finalidad, están prohibidas por la ley. Le informamos,
como destinatario de este mensaje, que el correo electrónico y las
comunicaciones por medio de Internet no permiten asegurar ni
garantizar la confidencialidad de los mensajes transmitidos, así como
tampoco su integridad o su correcta recepción, por lo que el CNIC no
asume responsabilidad alguna por tales circunstancias. Si no
consintiese la utilización del correo electrónico o de las
comunicaciones vía Internet le rogamos nos lo comunique y ponga en
nuestro conocimiento de manera inmediata.

*** LEGAL NOTICE **
This message is intended exclusively for the person to whom it is
addressed and contains privileged and confidential information
protected from disclosure by law. If you are not the addressee
indicated in this message, you should immediately delete it and any
attachments and notify the sender by reply e-mail or by phone
(+34 914531200). In such case, you are hereby notified that any
dissemination, distribution, copying or use of this message or any
attachments, for any purpose, is strictly prohibited by law. We
hereby inform you, as addressee of this message, that e-mail and
Internet do not guarantee the confidentiality, nor the completeness
or proper reception of the messages sent and, thus, CNIC does not
assume any liability for those circumstances. Should you not agree
to the use of e-mail or to communications via Internet, you are
kindly requested to notify us immediately.

Re: Suppress "Command died with status 1" in Pipe transport

[Adam]

Wietse:

Thank you for the reply.  Rest assured this was specifically for SASL
authenticated users.  Non-authenticated users would have had an
unknown recipient rejected by the policy service.

I solved the issue by setting up virtual_mailbox_maps.  My primary
reason for wanting to avoid that was Apple Mail doesn't bother to give
the user the SMTP reject code/error for a message that has one or more
invalid recipients and no valid recipients.

Instead it responds with "Verify that you have addressed this message
correctly.  Check your SMTP server settings in Mail preferences and
verify any advanced settings with your system administrator."

People don't assume they messed up an address, instead they assume
something is wrong on this end.

Anyway, have a great weekend.

Thanks,
Adam

On Fri, Jun 18, 2010 at 5:50 AM, Wietse Venema  wrote:
> Adam:
>> Good Morning,
>>
>> Is there a way to hide the syserr as well as the path returned by a
>> pipe transport?  For instance, I have virtual accounts and they are
>> handled by a custom transport.  When a message is sent to a
>> non-existent user, the mailer-daemon response to the sender is:
>>
>> : Command died with status 1:
>>    "/usr/lib/xmail/postfix/vmtransport". Command output: Unknown user.
>>  The user "bob" does not exist at "example.com".
>
> DO NOT ACCEPT MAIL FOR NON-EXISTENT USERS.
>
> Your system is sending back SPAM to innocent people who did not send it.
>
>        Wietse
>

Re: Failed check "loops back to myself"

[Wietse Venema]

Carlos Velasco:
> > I think this is a mistake, in the sense that it is a crude work-around.
> > The right solution is keep the "inet_interfaces" settings of Postfix
> > instances *disjoint*, and to never forward mail to port 25 *within*
> > an instance. This keeps things clear and predictable.
> > 
> > - Each instance "owns" a separate pool of IPs
> > 
> > - Internal forwarding is never to port 25, that's
> >   where outside mail comes in, and you never loop
> >   it back-in again.
> > 
> > - Loop detection is not disabled.
> > 
> > Don't fight the system, work within the design.
> > 
> 
> Sorry, but I don't see your point here.
> I understand the check as to stop a mail bouncing to itself, but this is
> not the case, mail is going from one instance to another. This is,

Then,

- Give each instance its own IP address (use main.cf:inet_interfaces)

- Give each instance its own name (use main.cf:myhostname)

Work WITH the system, or else stop complaining.

Wietse

Re: Failed check "loops back to myself"

[Carlos Velasco]

> On Thu, Jun 17, 2010 at 06:55:33PM +0200, Carlos Velasco wrote:
> 
>>> Loop detection is on by default when the destination port is 25.
>>> Loop detection matches on either banner hostnames or interfaces
>>> or IP addresses found in inet_interfaces or proxy_addresses.
>>
>> It could be good to have a switch to turn it off for cases like this :)
>>
>>> Alternatively, you can override "inet_interfaces" for just the
>>> smtp(8) delivery agent:
>>>
>>> smtp unix ... smtp
>>> -o inet_interfaces=127.0.0.1
>>
>> I think I will go with this as this one doesn't need smtpd to listen on
>> 127.0.0.1:25.
> 
> I think this is a mistake, in the sense that it is a crude work-around.
> The right solution is keep the "inet_interfaces" settings of Postfix
> instances *disjoint*, and to never forward mail to port 25 *within*
> an instance. This keeps things clear and predictable.
> 
>   - Each instance "owns" a separate pool of IPs
> 
>   - Internal forwarding is never to port 25, that's
> where outside mail comes in, and you never loop
> it back-in again.
> 
>   - Loop detection is not disabled.
> 
> Don't fight the system, work within the design.
> 

Sorry, but I don't see your point here.
I understand the check as to stop a mail bouncing to itself, but this is
not the case, mail is going from one instance to another. This is,
postfix is assuming that it is always listening on port 25 where this is
not the case, this instance is listening on another port (via master.cf)
and the other instance is the one listening on port 25. So the mail is
not bouncing to itself really. I looked into code and can see that the
check only applies to port 25, so I suppose it is rather an assumption
that postfix is always listening on that port. But really it is not the
case here.

As per a pool of ip addresses by instance, well, yes, it makes things
cleaner, although a bit more difficult into networking, but when we are
working with public Internet IP addresses it makes not happy to any NCC
to "waste" scarce public IP addresses for this :)

Regards,
Carlos Velasco


*** AVISO LEGAL ***
Este mensaje va dirigido, de manera exclusiva, a su destinatario y
contiene información confidencial y sujeta al secreto profesional,
cuya divulgación no está permitida por la ley. En caso de haber
recibido este mensaje por error, le rogamos que, de forma inmediata,
nos lo comunique mediante correo electrónico remitido a nuestra
atención o a través del teléfono (+34 914531200) y proceda a su
eliminación, así como a la de cualquier documento adjunto al mismo.
Asimismo, le comunicamos que la distribución, copia o utilización de
este mensaje, o de cualquier documento adjunto al mismo, cualquiera
que fuera su finalidad, están prohibidas por la ley. Le informamos,
como destinatario de este mensaje, que el correo electrónico y las
comunicaciones por medio de Internet no permiten asegurar ni
garantizar la confidencialidad de los mensajes transmitidos, así como
tampoco su integridad o su correcta recepción, por lo que el CNIC no
asume responsabilidad alguna por tales circunstancias. Si no
consintiese la utilización del correo electrónico o de las
comunicaciones vía Internet le rogamos nos lo comunique y ponga en
nuestro conocimiento de manera inmediata.

*** LEGAL NOTICE **
This message is intended exclusively for the person to whom it is
addressed and contains privileged and confidential information
protected from disclosure by law. If you are not the addressee
indicated in this message, you should immediately delete it and any
attachments and notify the sender by reply e-mail or by phone
(+34 914531200). In such case, you are hereby notified that any
dissemination, distribution, copying or use of this message or any
attachments, for any purpose, is strictly prohibited by law. We
hereby inform you, as addressee of this message, that e-mail and
Internet do not guarantee the confidentiality, nor the completeness
or proper reception of the messages sent and, thus, CNIC does not
assume any liability for those circumstances. Should you not agree
to the use of e-mail or to communications via Internet, you are
kindly requested to notify us immediately.

Re: Suppress "Command died with status 1" in Pipe transport

[Wietse Venema]

Adam:
> Good Morning,
> 
> Is there a way to hide the syserr as well as the path returned by a
> pipe transport?  For instance, I have virtual accounts and they are
> handled by a custom transport.  When a message is sent to a
> non-existent user, the mailer-daemon response to the sender is:
> 
> : Command died with status 1:
>"/usr/lib/xmail/postfix/vmtransport". Command output: Unknown user.
>  The user "bob" does not exist at "example.com".

DO NOT ACCEPT MAIL FOR NON-EXISTENT USERS. 

Your system is sending back SPAM to innocent people who did not send it.

Wietse

Re: Spam notification

[Antoine Nguyen]

Le 18/06/2010 11:51, Reko Turja a écrit :
I'm not a great fan of quarantining, although it works fairly well 
for webmail systems where the quarantine can be accessed through the 
same interface as the inbox (eg, Gmail and Hotmail). It's less 
helpful where mail is delivered to a POP3 or IMAP box as users have 
to go to a separate interface to check the quarantine.


With quarantine and IMAP, one approach is using sieve with IMAP server 
and forwarding the border cases automatically via sieve rules to users 
junk/spam folder. That way quarantine can be accessed from the regular 
mail client or web interface and checked by the user him/herself if 
important mail seems to be missing.


At least Cyrus can do this pretty painlessly, and I think Dovecot does 
support sieve these days too.


-Reko
Good idea. But I think this is getting harder if you want to allow users 
to notify server about its errors (false positive, false negative, ...).


Talking about that, I would just let the list knows that I've just 
released a new version of MailNG. This is a web based tool that allows 
the administration and use of a virtual domains hosting platform. It 
provides:

* An admin panel to create domains/mailboxes/aliases and more,
* A simple webmail,
* A quarantine managment tool (Amavisd-new sql quarantine),
* Automatic replies (vacation),
* Graphical statistics.

It works great with postfix. In fact, I've only tested it with postfix ;-)

The project lives here : http://projects.koalabs.org/trac/mailng/

Antoine

Suppress "Command died with status 1" in Pipe transport

[Adam]

Good Morning,

Is there a way to hide the syserr as well as the path returned by a
pipe transport?  For instance, I have virtual accounts and they are
handled by a custom transport.  When a message is sent to a
non-existent user, the mailer-daemon response to the sender is:

: Command died with status 1:
   "/usr/lib/xmail/postfix/vmtransport". Command output: Unknown user.
 The user "bob" does not exist at "example.com".


Is it possible to only have it send back the command output and not
the information before it?  So instead it would read:

:  Unknown user.  The user "bob" does not exist at
"example.com".


I've searched around on Google and read up on the pipe transport,
however I didn't see anything that would suppress that.  The only
reason this is even an issue is because I've had some users that
thought there was a problem because of the "Command died" message.
Any input on this would be greatly appreciated.

Cheers,

Adam

Re: Spam notification

[Reko Turja]

I'm not a great fan of quarantining, although it works fairly well 
for webmail systems where the quarantine can be accessed through the 
same interface as the inbox (eg, Gmail and Hotmail). It's less 
helpful where mail is delivered to a POP3 or IMAP box as users have 
to go to a separate interface to check the quarantine.


With quarantine and IMAP, one approach is using sieve with IMAP server 
and forwarding the border cases automatically via sieve rules to users 
junk/spam folder. That way quarantine can be accessed from the regular 
mail client or web interface and checked by the user him/herself if 
important mail seems to be missing.


At least Cyrus can do this pretty painlessly, and I think Dovecot does 
support sieve these days too.


-Reko 

Re: Spam notification

[Antoine Nguyen]

Le 18/06/2010 11:42, Erik Logtenberg a écrit :

Michael Weissenbacher wrote:
   

Conclusion: the spam is passed! I could stop sending notifications but I
   

think my employer would not like it...
 

Short answer:
You should NEVER notify anyone about detected spam! This will
effectively make yourself a spam source. It's even worse when you attach
the original message.
 

He sends the notification not to the apparent (probably forged) sender,
but to the intended receipient.
This way he won't really be a spam source, but on the other hand, his
solution isn't helping much either ;)

In general, you should definately not send notifications regarding spam
detection.

   
Yes that's what happened. The notification si sent directly to the real 
MX declared server that is behind the relay. I've just realized that my 
$final_spam_destiny was set to D_REJECT and not D_DISCARD. My bad :p


So now, notifications will not be sent to anyone.

Re: Spam notification

[Erik Logtenberg]

Michael Weissenbacher wrote:
>> Conclusion: the spam is passed! I could stop sending notifications but I
>>> think my employer would not like it...
> Short answer:
> You should NEVER notify anyone about detected spam! This will
> effectively make yourself a spam source. It's even worse when you attach
> the original message.

He sends the notification not to the apparent (probably forged) sender,
but to the intended receipient.
This way he won't really be a spam source, but on the other hand, his
solution isn't helping much either ;)

In general, you should definately not send notifications regarding spam
detection.

Re: Spam notification

[Birta Levente]

On 18/06/2010 11:36, Antoine Nguyen wrote:

Hi all,

I'm facing a stupid situation and I'm looking for advises. I'm using a 
postfix relay to filter viruses and spams. All is working well except 
with spam that use the same declared address for both sender and 
recipient. What happened in this particular situation is described as 
follow:

* The spam is detected,
* A notification is sent (with the original message as an attachment),
* The targeted recipient in my domain receives that notification.

Conclusion: the spam is passed! I could stop sending notifications but 
I think my employer would not like it...


I'm sure some of you have already faced and solved this kind of 
situation. I'm looking for your help :-)


Thanks in advance,

Antoine.


In my opinion the best way is to block all mails if sender appear in 
recipient addresses. (I think it's stupid to send mail to yourself, if 
it's about not spam)


Levi

Re: Spam notification

[Antoine Nguyen]

Le 18/06/2010 11:28, Mark Goodge a écrit :

On 18/06/2010 10:17, Antoine Nguyen wrote:

Le 18/06/2010 11:15, Michael Weissenbacher a écrit :
Conclusion: the spam is passed! I could stop sending notifications 
but I

think my employer would not like it...

Short answer:
You should NEVER notify anyone about detected spam! This will
effectively make yourself a spam source. It's even worse when you 
attach

the original message.

hth,
Michael

I agree with that... but what about false positives?


There are three main options:

1. Just discard spam.

2. Quarantine spam, and allow the user to check their quarantine 
folder and release it if necessary.


3. Don't intercept spam, just tag it and leave the actual filtering to 
the recipient's own system.


I'm not a great fan of quarantining, although it works fairly well for 
webmail systems where the quarantine can be accessed through the same 
interface as the inbox (eg, Gmail and Hotmail). It's less helpful 
where mail is delivered to a POP3 or IMAP box as users have to go to a 
separate interface to check the quarantine.


Personally, I prefer to have an approach that's split between 
discarding and tagging - discard anything that's a definite spam, and 
tag the rest. That way, you minimise the worst effects of spam while 
not blocking anything that might generate a false positive.


Mark

.
That's a good approach. I'm already discarding true spams and tagging 
the rest (amavisd-new tag2 and kill levels). I think I'm going to 
deactivate notifications and wait for eventual complaints from my users 
about emails not arriving :-)


Many thanks for those quick answers.

Antoine.

Re: Spam notification

[Mark Goodge]

On 18/06/2010 10:17, Antoine Nguyen wrote:

Le 18/06/2010 11:15, Michael Weissenbacher a écrit :

Conclusion: the spam is passed! I could stop sending notifications but I

think my employer would not like it...

Short answer:
You should NEVER notify anyone about detected spam! This will
effectively make yourself a spam source. It's even worse when you attach
the original message.

hth,
Michael

I agree with that... but what about false positives?


There are three main options:

1. Just discard spam.

2. Quarantine spam, and allow the user to check their quarantine folder 
and release it if necessary.


3. Don't intercept spam, just tag it and leave the actual filtering to 
the recipient's own system.


I'm not a great fan of quarantining, although it works fairly well for 
webmail systems where the quarantine can be accessed through the same 
interface as the inbox (eg, Gmail and Hotmail). It's less helpful where 
mail is delivered to a POP3 or IMAP box as users have to go to a 
separate interface to check the quarantine.


Personally, I prefer to have an approach that's split between discarding 
and tagging - discard anything that's a definite spam, and tag the rest. 
That way, you minimise the worst effects of spam while not blocking 
anything that might generate a false positive.


Mark
--
http://mark.goodge.co.uk

Re: Spam notification

[Antoine Nguyen]

Le 18/06/2010 11:15, Michael Weissenbacher a écrit :

Conclusion: the spam is passed! I could stop sending notifications but I
 

think my employer would not like it...
   

Short answer:
You should NEVER notify anyone about detected spam! This will
effectively make yourself a spam source. It's even worse when you attach
the original message.

hth,
Michael
   

I agree with that... but what about false positives?

Re: Spam notification

[Michael Weissenbacher]

> Conclusion: the spam is passed! I could stop sending notifications but I
> > think my employer would not like it...
Short answer:
You should NEVER notify anyone about detected spam! This will
effectively make yourself a spam source. It's even worse when you attach
the original message.

hth,
Michael

Spam notification

[Antoine Nguyen]

Hi all,

I'm facing a stupid situation and I'm looking for advises. I'm using a 
postfix relay to filter viruses and spams. All is working well except 
with spam that use the same declared address for both sender and 
recipient. What happened in this particular situation is described as 
follow:

* The spam is detected,
* A notification is sent (with the original message as an attachment),
* The targeted recipient in my domain receives that notification.

Conclusion: the spam is passed! I could stop sending notifications but I 
think my employer would not like it...


I'm sure some of you have already faced and solved this kind of 
situation. I'm looking for your help :-)


Thanks in advance,

Antoine.