Citadel
25 Replies
Is there more things to set besides that stuff? I'm using ubuntu 9.04.
@underthesun:
Did you guys just follow the instructions on the wiki on how to get it running? I did, and citadel runs, but I can't seem to get any mail outside.. it just doesn't arrive.
Is there more things to set besides that stuff? I'm using ubuntu 9.04.
You can't send mail, or can't receive it?
4.7.0 [67.18.XXX.XXX] Our system has detected an unusual amount of
Any ideas?
anyone had this problem before?
Do you have your DNS PTR record (the "Reverse DNS" section on the network tab in Linode Manager) set up to properly translate the IP address of your Linode to its forward (A) record hostname. If that doesn't match, it might be taken as a strong indicator of spam.
Also, if you don't have it already, adding an SPF record to DNS for the domain sending the message may improve your odds - it can provide a stronger indication that your Linode is authorized to send mail for that domain.
-- David
Do I have to set up a second linode, or should I just get an extra IP for my current linode? I wonder if Citadel supports something like this..
SPF is another matter I have to attend to I guess, but yeah.
@underthesun:
anyone had this problem before?
Yes:
I would check the most obvious explanation - have you been sending an unusual amount of unsolicited email to gmail users? You can check your logs, or if it is a new IP for you then you can check it against spam databases and see if it has a bad history.
Ideally, your rDNS should match up with an A record and also match the HELO name of your email server. Not everyone checks for all these to agree though, so YMMV.
You do NOT need a separate IP address for every domain you want to send mail from. The sending domain need not match the hostname of the server. In other words, you could send mail from
@underthesun:
Can't send mail.. and I get this ni the outbound smtp queue view:
XXXXXX@gmail.com 4.7.0 [67.18.XXX.XXX] Our system has detected an unusual amount of
Any ideas?
I use debian 5.0 and Citadel configured per the linode library instructions and a PTR record for my IP that reflects the domain Citadel is sending mail from. Gmail accepts messages from my server every time, but would not until I configured reverse DNS.
@underthesun:
So the reverse DNS have to match the domain? Right now, the IP is already being used for another .com.. and I'm trying to send mails using a second .com.
"have to" is a bit strong, but yes, if they don't match you have significantly increased the odds your mail may be identified as spam, depending on the destination provider. From the receiving server's perspective, your current configuration appears identical to a random Internet host trying to originate mail on behalf of some other server/domain (which is, after all, what you are doing, albeit legitimately).
> Do I have to set up a second linode, or should I just get an extra IP for my current linode? I wonder if Citadel supports something like this..
SPF is another matter I have to attend to I guess, but yeah.
A second IP could certainly work, if you aligned its A and PTR records for the domain in question, but certainly doesn't scale very well.
An SPF entry should help alleviate the issue with the PTR record, since it's designed to say "host www" is permitted to send mail on behalf of domain "xxx.yyy". So if your forward A lookup matches your PTR for your mail host (whatever the domain), and you have an SPF indicating that mail host can send mail for the other domain in question, you're more likely to be trusted.
– David
What do you mean with:
"A second IP could certainly work, if you aligned its A and PTR records for the domain in question, but certainly doesn't scale very well. " ?
I have a lot of .coms and I want to do something like providing an email forwarding service eventually…
The thing is, since I only have one server (and that means one hostname), this means that all those systems trying to match the domain's .com to my hostname won't work would it? (namely, reverse DNS, and my hostname set under linux)
I'm setting my SPF record like this (based on godaddy's wizard):
v=spf1 mx mx:67.18.XXX.XXX -all
(where the above is my linode IP).
Is that enough?
@underthesun:
Awesome, thanks for the answers. I still feel a bit confused though..
What do you mean with:
"A second IP could certainly work, if you aligned its A and PTR records for the domain in question, but certainly doesn't scale very well. " ?
Just that each individual IP address can have it's own reverse lookup (PTR), so if you have two addresses, each could be dedicated to a different domain. But you'd need a different address per domain (you can only have one PTR for an address), so it doesn't scale to something like:
> I have a lot of .coms and I want to do something like providing an email forwarding service eventually…
This case
> The thing is, since I only have one server (and that means one hostname), this means that all those systems trying to match the domain's .com to my hostname won't work would it? (namely, reverse DNS, and my hostname set under linux)
I'm setting my SPF record like this (based on godaddy's wizard):
v=spf1 mx mx:67.18.XXX.XXX -all
(where the above is my linode IP).
Is that enough?
I'm pretty sure that the "mx:" prefix is for domain names (it approves all MX servers for those domains) and not IP addresses. For that I think you want an "a:" prefix. Of course, if your Linode's 67.18.XXX.XXX address is in fact the MX for the domain in question, your earlier "mx" takes care of it already.
You might also want to start with ~all, which is a soft failure, progressing to -all (hard failure) if things are good. There's some debate about using -all (in lieu of ?all), since there's a small risk that an SPF check occurs somewhere other than at the external boundary where it's supposed to be applied (e.g., right after your server hands it off) and may incorrectly get bounced, but nowadays I think you should be fine.
You might want to take a peek at
Also, with respect to GMail, if you view full headers you can find the SPF check header GMail adds, along with the determination it made.
– David
It really does take a while huh.. waiting for the changes to propagate.
Another question.. is this enough or should I get DKIM and sender ID working as well?
It really does take a while huh.. waiting for the changes to propagate.
Another question.. is this enough or should I get DKIM and sender ID working as well?
– David
@underthesun:
Well, I don't know. I'm sure I got the SPF records right, but any new mail account always gets into gmail's spambox. At least it even gets there now.. it didn't even make it to the spambox last time.
Does the GMail Received-SPF header on the messages show that it passed?
If so, then I'm not sure, unless the format of the messages is very spam-like (mostly images, MIME with only an HTML variant, etc…), in which case maybe it's just going to take some training or whitelisting.
-- David
(Received-SPF: pass ) after checking the original message.
Could it be because citadel mails using html? I mean, even with empty messages, it still appends a etc on the message..
@Xan:
SPF is harmful; it shouldn't be used.
wait.. what?
@underthesun:
@Xan:SPF is harmful; it shouldn't be used.
wait.. what?
Ignore him, he feels the need to make that unsupported statement in every thread than mentions SPF. Like it or not, SPF is being used by some receivers.
If you don't like it, then publish something like this (from here
"v=spf1 +all"
The domain owner thinks that SPF is useless and/or doesn't care.
That record basically tells the receiver not to check SPF, but it gets you through the hoop that you have an SPF record.
@underthesun:
Hmm, I see.. I just checked and gmail seems to be OK with the SPF
(Received-SPF: pass ) after checking the original message.
Could it be because citadel mails using html? I mean, even with empty messages, it still appends a etc on the message..
Well, it can't be solely because of that, since clearly a whole lot of email nowadays contains an HTML section, but yeah, the only thing I can think of is that something about the formatting/contents of your test messages are causing them to be considered highly likely to be spam.
I'm assuming that the core formatting of the messages is correct, and that, for example the MIME headers properly identify your HTML section as being HTML.
For test purposes, generating a plain text email (even if you do it manually) would be a useful test. You may also find that your test messages are so short that the ratio of contents to the HTML overhead is affecting the spam classification.
If you're testing with empty messages, that in and of itself might be a flag to GMail (e.g., no contents), so I'd try testing with a more realistic message.
Beyond that though, not sure what to say.
– David
Here
SPF breaks pre-delivery forwarding.
SPF hijacks existing DNS mechanisms.
SPF gives ISPs a "lock-in" weapon against their customers.
SPF is useless for several entire classes of people.
SPF relies upon DNS for security, but DNS isn't a security service.
SPF is vulnerable to race conditions during database changes.
SPF creates new categories of third class citizenship.
SPF doesn't actually address unsolicited bulk mail at all.
SPF hands Verisign its next unwelcome "innovation" on a platter.