ietf-mxcomp
[Top] [All Lists]

LMAP scenarios. Correction. Paging DeKok, Levine. How to authenticate header From: !?

2004-03-23 22:29:32

Alan DeKok/John Levine: are you still working on draft-irtf-asrg-lmap-discussion? <http://www.taugh.com/draft-irtf-asrg-lmap-discussion-01.txt> <http://www1.ietf.org/mail-archive/working-groups/asrg/current/msg09281.html> went unanswered, I believe.
*********
I'd like to take back something I said earlier, now that I think about it. LMAP can do a lot more than stopping joes, even without matching header From:, if it's used in conjunction with reputation services, such as RHSW&BLs. Matching stuff in the header is a nice-to-have, but I think LMAP can reduce spam (which I see as the goal, not just reducing forgeries) without it. (See mailing list/paypal comments far below.)
**********
I've already read (and contributed to) the LMAP-discussion draft, and it attempts to address all major scenarios of usage, but I thought it would be useful to try another tack as well. I have many valid email addresses. As a thought experiment, let me see how well each of them (munged) would work in a pervasive LMAP world - I bet I cover most common usage scenarios.

1)me(_at_)elvey(_dot_)dom - Different users at elvey.dom use different SMTP servers. The LMAP record will list the mail servers of the perhaps dozen ISPs of users of the domain. All will be peachy. As the mail admin, I'll have to explain to the users/ walk them through setting up SMTP AUTH to their ISP, so that they can send mail when traveling. Or I could set up an smtp.elvey.com mail server. 2)me(_at_)aya(_dot_)yale(_dot_)dom - my alumni account. Either Yale sets up a mail server for alums to use, that LMAP authorizes, or mail sent from @aya.yale.dom will at least be greylisted, if not blacklisted as a frequent envelope FROM of spam. (LMAP contenders allow aya.yale.dom to have different LMAP records from @yale.dom, right? SPF does, at least, IIRC.) Perhaps my mail client/ISP could work together so I could send mail with envelope FROM = something valid for my usual SMTP server, LMAP-wise, and header From: with my address. This would involve changing MUAs - a non-starter. Also, this would perhaps be suspicious to, say SpamAssassin. I never send email from this address, so I probably won't be willing to pay for smarthost access to the aya.yale server, but they probably are willing to provide it free (they already pay a third party to manage the current receive and-relay only system). 3)me(_at_)pacbell(_dot_)dom - PacBell. my ISP, may do something stupid like publish an LMAP record allowing mail only from their mail servers, but not allow people not currently on their network to use those mail servers, even with AUTH. Actually, I think they used to, but no longer do this. If I actually still cared about this addres, and they did something stupid like this, it would be a big problem, but they'd get a ton of support calls and fix it PDQ. If not, I'd set up a server on my DSL line to relay email for me, but non-geeks would be screwed. (I could sell access to the server I'd set up to other pacbell users though!) Peachy. 4)me(_at_)myemployer(_dot_)dom - I'll set up my MUA to send through their server when I want to send as @them, or have them add my usual SMTP server to the server list authorized for their domain in LMAP. Peachy. 5)me(_at_)theclientofmyemployer(_dot_)dom - I'll set up my MUA to send through their server when I want to send as @them. Peachy. 6)me(_at_)myEmailServiceProvider(_dot_)dom - I'll use their SMTP server (mail.messagingengine.com) (it's what I use by default currently, with SSL, to send all my mail).
7)me(_at_)ieee(_dot_)dom - same as 2).
8)me(_at_)hotmail(_dot_)dom - I'll use the web or http interface to send email from this account, as Microsoft is likely to publish restrictive LMAP records. I'll have to stop sending mail from me(_at_)hotmail(_dot_)dom using mail.messagingengine.com, but that's fine; I rarely send mail from this account anyway. M$ will get some add'l revenue from the ads I view (unless I block 'em) while sending mail using the web interface. 9)me(_at_)yahoo(_dot_)dom - I'll use the web interface to send email from this account, as Yahoo is likely to publish restrictive LMAP records. Also, I happen to have free POP/SMTP access (because I have SBC/Yahoo DSL) so I can use that too. Peachy. 10)me(_at_)anOutblaze domain. same as 9) but no free SMTP access. So, in all 10 cases, I can probably still send email. Also, in all the cases, I think envelope FROM will = header From:, at least initially. When I post to a list, it'll be doing VERP/SRS. In each case, my email will be more easily categorizable as not spam, and hence more likely to reach the recipients. Hotmail and Yahoo probably won't do a great job terminating spammers using their services, so their reputations will reflect that, but a @yahoo.com or @hotmail.com will be much less of a spamsign/more respected than it is now. I'll probably use Hotmail and Yahoo a little less than I do now. Only in case #1 so I have to pre-register my MTA to get it into the domain's LMAP entries. There are no mobility issues.

I receive lots of different kinds of email, including mail to mailing lists and the above addresses. Let's see see how each of them would work in a pervasive LMAP world. (Postponed to next email.)

I run a mailing list at freelists.org. I think that the mail software they use may no longer be maintained. But it already sends out mail with @freelists.org in the envelope FROM, so it should be fine. header From: is the original sender, so envelope FROM will != header From: Perhaps domains like verisign.com, paypal.com or bigbank.dom would have LMAP entries specifically saying it was NOT ok for them to be in the header From: where envelope FROM to != header From:. Typical domains would not have LMAP entries like this because it would typically prevent their users from having their mailing list postings accepted by recipients, effectively meaning they couldn't post to mailing lists with their work domains, which their employers would probably view as a good thing anyway. Would there be a point to freelists.org, ietf.org, imc.org and the like having LMAP entries saying that it WAS ok for envelope FROM to != header From: where they were in the envelope? I think not, but perhaps. Perhaps RHSWLs would appear that listed domains that hosted legit mailing lists.


PS I believe it's clear that by header From:, I mean (RFC2822)From: and
envelope FROM = (RFC2821)MAIL FROM, so I use the simpler and shorter, but still clear terms.

How to authenticate header From:  -  Would this work?:
If envelope FROM != header From:, but envelope FROM checks out in LMAP, and reputation services, we *can* probably trust the topmost Received header (prior to any added by the receiving MTA itself), which will in most such cases have an IP that matches the domain in the header From:! Right? Cool!?


<Prev in Thread] Current Thread [Next in Thread>
  • LMAP scenarios. Correction. Paging DeKok, Levine. How to authenticate header From: !?, Matthew Elvey <=