Richard Clayton wrote:
> >>The idea
> >> being that email from paypal.com will come from paypay servers somewhere
> >> in received.
> >
> >What's so hard about this???
>
> We don't currently have a universally deployed mechanism for indicating
> where email comes from -- so you are stuck a mixture of experimental
> protocols and heuristics
I realize this, however, I should have stated that the heuristic should have
been for whitelisting, not blacklisting.
> Significant complications arise with email forwarding especially when
> you consider that the system that passed you email might be wishing to
> mislead you into the veracity of the information it provides...
True.
> >mx custserv.paypal.com.
> >> custserv.paypal.com does not exist, try again
> >mx accounting.paypal.com.
> >> accounting.paypal.com does not exist, try again
> >mx paypal.com.
> >> paypal.com MX 10 smtp1.sc5.paypal.com
> >> paypal.com MX 10 smtp2.nix.paypal.com
> >> paypal.com MX 10 smtp1.nix.paypal.com
> >mx com.
> >> com MX record currently not present
> >
> >Just strip the subdomain off until you get an MX. How difficult could that
> >be??? You can do this with embedded perl and it would be quite easy to do.
>
> The MX records tells you something about where email is delivered to
> when sent from the Internet. In some cases (mainly smaller sites) it may
> tell you something about where email comes from; but of course it can
> never tell you about private arrangements for outgoing email :(
>
> So it's a heuristic, but rather a flawed one :(
But when it is used to accept mail rather than deny, it's not too flawed.
If I used something like this to bypass say greylisting, it's not too
flawed. Although spammer domains can be this way too so it is possible to
white list spammers. I don't typically see spammers that run their own
domains connecting to my own server. I don't typically get many spam
attempts either (having china/korea blocked is a big help =)
> >If you're wondering about say demon.co.uk:
> >mx demon.co.uk.
> >> demon.co.uk MX 5 lon1-hub-internal.mail.demon.net
> >> demon.co.uk MX 5 anchor-hub-internal.mail.demon.net
> >mx co.uk.
> >> co.uk MX record currently not present
> >mx uk.
> >> uk MX record currently not present
>
> Start by looking up, for example, happyday.demon.co.uk (where this email
> actually came from) to see how confusing this immediately starts to
> become ...
Actually, it came from richard_highwayman.com via
anchor-post-32.mail.demon.net [194.217.242.90]
Which doing MX lookups on both the domain here and the server show totally
different results. I don't see happyday.demon.co.uk nor 80.177.121.10 in
the headers. However the MX for happyday.demon.co.uk is very close to the
server that sent the actual mail to me (which can't really be considered
since it wasn't mentioned in the headers)
If I had implemented these checks, I'd use them not for black listing but
for bypassing certain blacklisting checks.
I don't get bombarded by spam so much so I haven't bothered to tighten my
server in a while.
Anyway, it was a thought and noone else seem to have mentioned it (or I
missed that message)
--
Lab tests show that use of micro$oft causes cancer in lab animals
Got Gas???
