The first domain uses its own mailserver: aaaaa.nl:xx.xx.13.68:25 and the domains bbbbb.nl and ccccc.nl use our (default) mailserver. These last two emailaddresses are on our mailserver but SF tried to post to the server of aaaaa.nl. We use v.2.6.3.473.

I don't know if it is a new bug, but we have not seen this happening the last three years and we are happy to use SF.

Can you please check the domains listed in your LocalDomains, and see
if you have any duplicate entries? SpamFilter tries to double-check the
file to eliminate duplicates if possible, but we found a bug in the
latest build where this "housekeeping" procedure will sometimes not
detect duplicate domains.

There are no duplicates in the list and these domains are there for a long time without any changes.

I found a change after updating to this version in rejecting non-existing emailaddresses. In the past the email was rejected if one address in the cc-list was not valid and now only the bad addresses are rejected and the rest is going thru. Has this anything to do with it?

SpamFilter delievers the email "as
is" to the destination SMTP server. In this case, the email has one
recipient to the aaaaaa.nl
domain, and the other two
to bbbbbb.nl and ccccc.nl. As SpamFilter cannot "split" the email and deliver a
copy to each of the servers responsible for each of the domains, all it can do
it to take the first destination SMTP server, (the one for aaaaaa.nl), and
forward the email to it.

Unfortunately there is currently no
workaround for this behavior. We may alter the way email is forwarded in the
future to address this issue, but we don't have any estimates on when this will
be available.

The RFC states that if an email cannot be delivered then the sender MUST be notified of the non delivery.

In the above example, one address is accepted by the destination SMTP
server, the other two are rejected. SpamFilter will thus deliver the
email to the accepted recipient, and does indeed send a non-delivery
notice to the sender informing them that their email did not get to the
other two recipients (and lists the addresses that were underliverable).

The destination SMTP server is behaving per RFC by rejecting the
recipients it does not support. SpamFilter is also behaving per RFC by
informing the sender of the delivery problems with the two recipients.

The RFC that we apply in this case is RFC 2821
(http://www.rfc-editor.org/rfc/rfc2821.txt). The section you'll want to
refer to is 3.7 on page 24:

If an SMTP server has accepted the task of relaying the mail and later finds that the destination is incorrect or that the mail cannot be delivered for some other reason, then it MUST construct an "undeliverable mail" notification message and send it to the originator of the undeliverable mail (as indicated by the reverse- path). Formats specified for non-delivery reports by other standards (see, for example, [24, 25]) SHOULD be used if possible.

I must have misunderstood the original post. It sounded to me that SpamFilter did not route the different recipients properly causing NDR's. It sounded like there should not have been NDR's because the default Destination Server was not used per your original design.

I thought SpamFilter was to route recipients based on the Local Domains whitelist table first and then route everything else to the default Destination Server. The last two emails should have been forwarded to the default Destination Server as is specified by your docs not the whitelisted domain.

Is my understanding incorrect or did you understand the user's post to say different?

The original user's post is accurate, he does describe a behavior in SpamFilter which could be indeed improved. He states that:

1. An email arrives with multiple recipients for multiple domains he owns
2. Some of the domains for the above recipients have different destination SMTP servers
3. The different destination SMTP servers will reject recipients for domains they do not handle

If the above conditions are true, some recipients will received NDRs. My second reply applies:

As SpamFilter cannot "split" the email and deliver a
copy to each of the servers responsible for each of the domains, all it can do
it to take the first destination SMTP server, (the one for aaaaaa.nl), and
forward the email to it.Unfortunately there is currently no
workaround for this behavior. We may alter the way email is forwarded in the
future to address this issue, but we don't have any estimates on when this will
be available.

SpamFilter currently requires that recipient servers for approved domains relay email for domains homed on a server that differs from the default recipient domain?

The solution, then, for agavv is to ensure that his/her servers will relay email from his/her SpamFilter server to other servers. That way the approved domain server can complete the job and relay the copies of the email to the recipients that are not local.

So, the future improvement would make SpamFilter operate in a more standard fashion when handling SMTP Client transmissions for approved domains. Once SpamFilter has accepted an email from a sending client, it should then assumes a client role in delivering to recipients in approved domains. That means SpamFilter will send a copy of the email to each accepted recipient per the rules and configurations of SpamFilter and in accordance with the this paragraph on page 23 of Section 3.7 SMTP RFC:

A relay SMTP server is usually the target of a DNS MX record thatdesignates it, rather than the final delivery system. The relayserver may accept or reject the task of relaying the mail in the same way it accepts or rejects mail for a local user. If it accepts the task, it then becomes an SMTP client, establishes a transmission channel to the next SMTP server specified in the DNS (according to the rules in section 5), and sends it the mail.

This is very bad news! The three customers I mentioned are competitors. Two use POP3-boxes on our server and one runs it's own mailserver. They received a very important message from a distributor and the one with his own mailserver, saw his server rejecting the e-mails for the two competitors on our mailserver.... I have to explain this!!

All three have ONE MX-record pointing to SF. Our mailserver can only forward to domains with a valid MX-record and we let SF forward the mail to a A-record.

Maybe you can make a workaround by sending the email with different destinations to the default server. Our mailserver forwards the email for delivering to SF (again) and SF sends it to the correct destination.

We have a mix of customers with POP3-boxes on our mailserver and customers who have their own mailserver. We cannot ask the rest of the world to stop with cc's and we can also not ask our customers to install a POP3-connector on their Exchange servers.

I tested this on our many domains. Using latest build it appears that your problems are solved if you merely define the smtp server for each inbound approved domain. SpamFilter send copies to multiple local domains in my tests per RFC specs above. It looks like the only issue is when you are relying on the default server.

So, in your case if you specify the inbound domains in the Local Domains whitelist for example:

(where mail. is the mail host for the given domain) you will not have problems. So it appears you are only having problems because either you have not included all local domains in your Local Domains whitelist or have not specified the mail server:port for each Local Domain entry.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot delete your posts in this forumYou cannot edit your posts in this forumYou cannot create polls in this forumYou cannot vote in polls in this forum