Forwarders, SPF records and SRS

D

dhm

Verified User
Joined
Mar 31, 2014
Messages
8
We have some issues with the e-mailforwarding on our DA servers. We have some clients who use forwarders from [email protected] to [email protected]. The domain @anotherlocation.com uses a spamfilter who marks the e-mail as spam, because the sender is [email protected] and the server is not allowed to send from the DA server.

My Google journey about this issue is always ending at topics about SRS (like this one).

Does someone have a solution for this already? Or is the experimental SRS exim version in custombuild the only one.
 
If your SPF record ends in ~all then email should be allowed from anywhere. If it ends in -all then it should only be allowed from the references in the record. Many recipient servers break the rules, and the problem with -all (without which SPF is relatively useless) has been known from the day SPF was first announced (I was at the meeting and I heard it from the words of the inventor).

I'm surprised that SPF is so heavily depended on, since it neither helps with spam, nor does it work as intended.

That said, either yout attempt to use SRS, or you leave the problem where t belongs, which is the recipient. If they don't want to accept properly forwarded email, then that's not really your problem.

Or is it?

Comments appreciated, but in my opinion the whole thing is broken. We try to convince our users to read their incoming email at our server and not forward it. One good way to do this is with Roundcube as your default webmail client. It;s good, and in my home and office it's totally replaced local email programs.

Jeff
 
nobaloney said:
If your SPF record ends in ~all then email should be allowed from anywhere. If it ends in -all then it should only be allowed from the references in the record. Many recipient servers break the rules, and the problem with -all (without which SPF is relatively useless) has been known from the day SPF was first announced (I was at the meeting and I heard it from the words of the inventor).
Click to expand...

The SPF records from our clients aren't the troublemakers, the senders SPF record is.

For example:

We can manage the SPF record of dhm.com and myclient.com, but we can not manage the SPF from directadmin.com. But the SPF record of directadmin.com is the troublemaker in this case.

Is it? No, I don't think so. The owner of directadmin.com is using his SPF record like it should. But the server of dhm.com is forwarder the message of directadmin.com pretending he is the server of directadmin.com

I hope there is someone who solved this problem on there server and would share his solution. In my opion the best solution would be to update Directadmin with an exim script that is not forwarding the message but rewriting the sender SRS.
 
SPF, when used strictly, with -all has always broken forwarding. Forwarding can be replaced with SRS, which has been discussed n these forums but is not yet quite ready for prime time use.

But I just checked, and directadmin.com uses ~all in their spf record, not -all.
Code: 
$ dig directadmin.com txt +short
"v=spf1 a mx ip4:192.169.82.154 ~all"
$
Jeff
 
nobaloney said:
But I just checked, and directadmin.com uses ~all in their spf record, not -all.
Click to expand...
Haha, thanks. directadmin.com was just an domain I used for example :)

I will try to convince our clients to avoid forwarders untill SRS is integraded.
 
You must log in or register to reply here.
Back
Top